EFM32WG Datasheet, PDF (307/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
6. If the application sets or clears a STALL for an endpoint due to a SetFeature.Endpoint Halt command
or ClearFeature.Endpoint Halt command, the Stall bit must be set or cleared before the application
sets up the Status stage transfer on the control endpoint.
Special Case: Stalling the Control IN/OUT Endpoint
The core must stall IN/OUT tokens if, during the Data stage of a control transfer, the host sends more
IN/OUT tokens than are specified in the SETUP packet. In this case, the application must to enable
USB_DIEPx_INT.INTKNTXFEMP and USB_DOEPx_INT.OUTTKNEPDIS interrupts during the Data
stage of the control transfer, after the core has transferred the amount of data specified in the SETUP
packet. Then, when the application receives this interrupt, it must set the STALL bit in the corresponding
endpoint control register, and clear this interrupt.
15.4.4.2.3.8 Worst-Case Response Time
When the acts as a device, there is a worst case response time for any tokens that follow an isochronous
OUT. This worst case response time depends on the AHB clock frequency.
The core registers are in the AHB domain, and the core does not accept another token before updating
these register values. The worst case is for any token following an isochronous OUT, because for an
isochronous transaction, there is no handshake and the next token could come sooner. This worst case
value is 7 PHY clocks in FS mode.
If this worst case condition occurs, the core responds to bulk/interrupt tokens with a NAK and drops
isochronous and SETUP tokens. The host interprets this as a timeout condition for SETUP and retries
the SETUP packet. For isochronous transfers, the INCOMPISOIN and INCOMPLP interrupts inform the
application that isochronous IN/OUT packets were dropped.
15.4.4.2.3.9 Choosing the Value of USB_GUSBCFG.USBTRDTIM
The value in USB_GUSBCFG.USBTRDTIM is the time it takes for the MAC, in terms of PHY clocks
after it has received an IN token, to get the FIFO status, and thus the first data from PFC (Packet FIFO
Controller) block. This time involves the synchronization delay between the PHY and AHB clocks. This
delay is 5 clocks.
Once the MAC receives an IN token, this information (token received) is synchronized to the AHB clock
by the PFC (the PFC runs on the AHB clock). The PFC then reads the data from the SPRAM and writes
it into the dual clock source buffer. The MAC then reads the data out of the source buffer (4 deep).
If the AHB is running at a higher frequency than the PHY (in Low-speed mode), the application can use
a smaller value for USB_GUSBCFG.USBTRDTIM. Figure 15.26 (p. 308) explains the 5-clock delay.
This diagram has the following signals:
• tkn_rcvd: Token received information from MAC to PFC
• dynced_tkn_rcvd: Doubled sync tkn_rcvd, from pclk to hclk domain
• spr_read: Read to SPRAM
• spr_addr: Address to SPRAM
• spr_rdata: Read data from SPRAM
• srcbuf_push: Push to the source buffer
• srcbuf_rdata: Read data from the source buffer. Data seen by MAC
The application can use the following formula to calculate the value of USB_GUSBCFG.USBTRDTIM:
4 * AHB Clock + 1 PHY Clock = (2 clock sync + 1 clock memory address + 1 clock memory data from
sync RAM) + (1 PHY Clock (next PHY clock MAC can sample the 2-clock FIFO output)
2013-05-08 - Wonder Gecko Family - d0233_Rev0.50
307
www.energymicro.com