/******************************************************************* * Function: bool USER_USB_CALLBACK_EVENT_HANDLER( * USB_EVENT event, void *pdata, uint16_t size) * * PreCondition: None * * Input: USB_EVENT event - the type of event * void *pdata - pointer to the event data * uint16_t size - size of the event data * * Output: None * * Side Effects: None * * Overview: This function is called from the USB stack to * notify a user application that a USB event * occured. This callback is in interrupt context * when the USB_INTERRUPT option is selected. * * Note: None *******************************************************************/ bool USER_USB_CALLBACK_EVENT_HANDLER(USB_EVENT event, void *pdata, uint16_t size) { switch((int)event) { case EVENT_TRANSFER: //Add application specific callback task or callback function here if desired. break; case EVENT_SOF: break; case EVENT_SUSPEND: break; case EVENT_RESUME: break; case EVENT_CONFIGURED: /* When the device is configured, we can (re)initialize the demo * code. */ APP_DeviceMSDInitialize(); APP_DeviceCDCEmulatorInitialize(); break; case EVENT_SET_DESCRIPTOR: break; case EVENT_EP0_REQUEST: /* We have received a non-standard USB request. The MSD driver * needs to check to see if the request was for it. */ USBCheckMSDRequest(); USBCheckCDCRequest(); break; case EVENT_BUS_ERROR: break; case EVENT_TRANSFER_TERMINATED: //Add application specific callback task or callback function here if desired. //The EVENT_TRANSFER_TERMINATED event occurs when the host performs a CLEAR //FEATURE (endpoint halt) request on an application endpoint which was //previously armed (UOWN was = 1). Here would be a good place to: //1. Determine which endpoint the transaction that just got terminated was // on, by checking the handle value in the *pdata. //2. Re-arm the endpoint if desired (typically would be the case for OUT // endpoints). //Check if the host recently did a clear endpoint halt on the MSD OUT endpoint. //In this case, we want to re-arm the MSD OUT endpoint, so we are prepared //to receive the next CBW that the host might want to send. //Note: If however the STALL was due to a CBW not valid condition, //then we are required to have a persistent STALL, where it cannot //be cleared (until MSD reset recovery takes place). See MSD BOT //specs v1.0, section 6.6.1. if(MSDWasLastCBWValid() == false) { //Need to re-stall the endpoints, for persistent STALL behavior. USBStallEndpoint(MSD_DATA_IN_EP, IN_TO_HOST); USBStallEndpoint(MSD_DATA_OUT_EP, OUT_FROM_HOST); } else { //Check if the host cleared halt on the bulk out endpoint. In this //case, we should re-arm the endpoint, so we can receive the next CBW. if((USB_HANDLE)pdata == USBGetNextHandle(MSD_DATA_OUT_EP, OUT_FROM_HOST)) { USBMSDOutHandle = USBRxOnePacket(MSD_DATA_OUT_EP, (uint8_t*)&msd_cbw, MSD_OUT_EP_SIZE); } } break; default: break; } return true; }
/******************************************************************* * Function: void USBCBCheckOtherReq(void) * * Overview: When SETUP packets arrive from the host, some * firmware must process the request and respond * appropriately to fulfill the request. Some of * the SETUP packets will be for standard * USB "chapter 9" (as in, fulfilling chapter 9 of * the official USB specifications) requests, while * others may be specific to the USB device class * that is being implemented. For example, a HID * class device needs to be able to respond to * "GET REPORT" type of requests. This * is not a standard USB chapter 9 request, and * therefore not handled by usb_device.c. Instead * this request should be handled by class specific * firmware, such as that contained in usb_function_hid.c. *******************************************************************/ void USBCBCheckOtherReq(void) { USBCheckMSDRequest(); USBCheckCDCRequest(); }//end
/******************************************************************* * Function: void USBCBCheckOtherReq(void) * * PreCondition: None * * Input: None * * Output: None * * Side Effects: None * * Overview: When SETUP packets arrive from the host, some * firmware must process the request and respond * appropriately to fulfill the request. Some of * the SETUP packets will be for standard * USB "chapter 9" (as in, fulfilling chapter 9 of * the official USB specifications) requests, while * others may be specific to the USB device class * that is being implemented. For example, a HID * class device needs to be able to respond to * "GET REPORT" type of requests. This * is not a standard USB chapter 9 request, and * therefore not handled by usb_device.c. Instead * this request should be handled by class specific * firmware, such as that contained in usb_function_hid.c. * * Note: None *******************************************************************/ void USBCBCheckOtherReq(void) { USBCheckMSDRequest(); }