EFM32WG Datasheet, PDF (254/834 Pages) List of Unclassifed Manufacturers – The EFM32WG Wonder Gecko is the ideal choice for demanding 8-, 16-, and 32-bit energy sensitive applications.

...the world's most energy friendly microcontrollers
For high-bandwidth interrupt INs in Slave mode, once the application has received a DATATGLERR
interrupt it must disable the channel and wait for a Channel Halted interrupt. The application must
be able to receive other interrupts (DATATGLERR, NAK, Data, XACTERR, BBLERR) for the same
channel before receiving the halt.
3. When a USB_GINTSTS.DISCONNINT (Disconnect Device) interrupt is received. The application
must check for the USB_HPRT.PRTCONNSTS, because when the device directly connected to the
host is disconnected, USB_HPRT.PRTCONNSTS is reset. The software must issue a soft reset to
ensure that all channels are cleared. When the device is reconnected, the host must issue a USB
Reset.
4. When the application aborts a transfer before normal completion (Slave and DMA modes).
Note
In DMA mode, keep the following guideline in mind:
• Channel disable must not be programmed for periodic channels. At the end of the next
frame (in the worst case), the core generates a channel halted and disables the channel
automatically.
15.4.3.3 Sending a Zero-Length Packet in Slave/DMA Modes
To send a zero-length data packet, the application must initialize an OUT channel as follows.
1. Program the USB_HCx_TSIZ register of the selected channel with a correct PID, XFERSIZE = 0,
and PKTCNT = 1.
2. Program the USB_HCx_CHAR register of the selected channel with CHENA = 1 and the device’s
endpoint characteristics, such as type, speed, and direction.
The application must treat a zero-length data packet as a separate transfer, and cannot combine it with
a non-zero-length transfer.
15.4.3.4 Handling Babble Conditions
The core handles two cases of babble: packet babble and port babble. Packet babble occurs if the device
sends more data than the maximum packet size for the channel. Port babble occurs if the core continues
to receive data from the device at EOF2 (the end of frame 2, which is very close to SOF).
When the core detects a packet babble, it stops writing data into the Rx buffer and waits for the end of
packet (EOP). When it detects an EOP, it flushes already-written data in the Rx buffer and generates
a Babble interrupt to the application.
When detects a port babble, it flushes the RxFIFO and disables the port. The core then generates a Port
Disabled Interrupt (USB_GINTSTS.PRTINT, USB_HPRT.PRTENCHNG). On receiving this interrupt,
the application must determine that this is not due to an overcurrent condition (another cause of the Port
Disabled interrupt) by checking USB_HPRT.PRTOVRCURRACT, then perform a soft reset. The core
does not send any more tokens after it has detected a port babble condition.
15.4.3.5 Handling Disconnects
If the device is disconnected suddenly, a USB_GINTSTS.DISCONNINT interrupt is generated.
When the application receives this interrupt, it must issue a soft reset by programming the
USB_GRSTCTL.CSFTRST bit.
15.4.3.6 Host Programming Operations
Table 15.1 (p. 255) provides links to the programming sequence for the different types of USB
transactions.
2013-05-08 - Wonder Gecko Family - d0233_Rev0.50
254
www.energymicro.com