/*******************************************************************
* 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();
}
