Page Comparison

...

If the platform architecture allows parameters to be passed to ISR handlers and the USB device controller has a single interrupt vector for the USB device, the first-level interrupt handler may be defined as:

Prototype

void  USBD_BSP_<controller>_IntHandler (void  *p_arg);

Arguments

p_arg

Pointer to USB device driver structure that must be typecast to a pointer to USBD_DRV.

...

If the platform architecture does not allow parameters to be passed to ISR handlers and the USB device controller has a single interrupt vector for the USB device, the first-level interrupt handler may be defined as:

Prototype

void  USBD_BSP_<controller>_IntHandler (void);

Arguments

None.

Notes / Warnings

...

If the platform architecture allows parameters to be passed to ISR handlers and the USB device controller has multiple interrupt vectors for the USB device (e.g., USB events, DMA transfers), the first-level interrupt handler may need to be split into multiple sub-handlers. Each sub-handler would be responsible for managing the status reported to the different vectors. For example, the first-level interrupt handlers for a USB device controller that redirects USB events to one interrupt vector and the status of DMA transfers to a second interrupt vector may be defined as:

Prototype

void  USBD_BSP_<controller>_EventIntHandler (void  *p_arg);
void  USBD_BSP_<controller>_DMA_IntHandler  (void  *p_arg);

Arguments

p_arg

Pointer to USB device driver structure that must be typecast to a pointer to USBD_DRV.

...

If the platform architecture does not allow parameters to be passed to ISR handlers and the USB device controller has multiple interrupt vectors for the USB device (e.g., USB events, DMA transfers), the first-level interrupt handler may need to be split into multiple sub-handlers. Each sub-handler would be responsible for managing the status reported to the different vectors. For example, the first-level interrupt handlers for a USB device controller that redirects USB events to one interrupt vector and the status of DMA transfers to a second interrupt vector may be defined as:

Prototype

void  USBD_BSP_<controller>_EventIntHandler (void);
void  USBD_BSP_<controller>_DMA_IntHandler  (void);

Arguments

None.

Notes / Warnings

...

The device driver interrupt handler must notify the USB device stack of various status changes. The Table - Status Notification API shows each type of status change and the corresponding notification function.

Each status notification API queues the event type to be processed by the USB stack’s event processing task. Upon reception of a USB event, the interrupt service routine may perform some operations associated to the event before notifying the stack. For example, the USB device controller driver must perform the proper actions for the bus reset when an interrupt request for that event is triggered. Additionally, it must also notify the USB device stack about the bus reset event by invoking the proper status notification API. In general, the device driver interrupt handler must perform the following functions:

1. Determine which type of interrupt event occurred by reading an interrupt status register.
2. If a receive event has occurred, the driver must post the successful completion or the error status to the USB device stack by calling USBD_EP_RxCmpl() for each transfer received.
3. If a transmit complete event has occurred, the driver must post the successful completion or the error status to the USB device stack by calling USBD_EP_TxCmpl() for each transfer transmitted.
4. If a setup packet event has occurred, the driver must post the setup packet data in little-endian format to the USB device stack by calling USBD_EventSetup().
5. All other events must be posted to the USB device stack by a call to their corresponding status notification API from Table - Status Notification API. This allows the USB device stack to broadcast these event notifications to the classes.
6. Clear local interrupt flags.

...