Architecture
1629
SPRUH82C – April 2013 – Revised September 2016
Copyright © 2013–2016, Texas Instruments Incorporated
Universal Serial Bus 2.0 (USB) Controller
34.2.7.1.4.1.2 Operation
An Isochronous endpoint does not support data retries, so if data underrun is to be avoided, the data to be
sent to the host must be loaded into the FIFO before the IN token is received. The host will send one IN
token per frame (or microframe in High-speed mode), however the timing within the frame (or microframe)
can vary. If an IN token is received near the end of one frame and then at the start of the next frame,
there will be little time to reload the FIFO. For this reason, double buffering of the endpoint is usually
necessary.
An interrupt is generated whenever a packet is sent to the host and the software may use this interrupt to
load the next packet into the FIFO and set the TXPKTRDY bit in the PERI_TXCSR register (bit 0) in the
same way as for a Bulk Tx endpoint. As the interrupt could occur almost any time within a
frame(/microframe), depending on when the host has scheduled the transaction, this may result in
irregular timing of FIFO load requests. If the data source for the endpoint is coming from some external
hardware, it may be more convenient to wait until the end of each frame(/microframe) before loading the
FIFO as this will minimize the requirement for additional buffering. This can be done by using either the
SOF interrupt or the external SOF_PULSE signal from the controller to trigger the loading of the next data
packet. The SOF_PULSE is generated once per frame(/microframe) when a SOF packet is received. (The
controller also maintains an external frame(/microframe) counter so it can still generate a SOF_PULSE
when the SOF packet has been lost.) The interrupts may still be used to set the TXPKTRDY bit in
PERI_TXCSR (bit 0) and to check for data overruns/underruns.
Starting up a double-buffered Isochronous IN pipe can be a source of problems. Double buffering requires
that a data packet is not transmitted until the frame(/microframe) after it is loaded. There is no problem if
the function loads the first data packet at least a frame(/microframe) before the host sets up the pipe (and
therefore starts sending IN tokens). But if the host has already started sending IN tokens by the time the
first packet is loaded, the packet may be transmitted in the same frame(/microframe) as it is loaded,
depending on whether it is loaded before, or after, the IN token is received. This potential problem can be
avoided by setting the ISOUPDATE bit in the POWER register (bit 7). When this bit is set, any data packet
loaded into an Isochronous Tx endpoint FIFO will not be transmitted until after the next SOF packet has
been received, thereby ensuring that the data packet is not sent too early.
34.2.7.1.4.1.3 Error Handling
If the endpoint has no data in its FIFO when an IN token is received, it will send a null data packet to the
host and set the UNDERRUN bit in the PERI_TXCSR register (bit 2). This is an indication that the
software is not supplying data fast enough for the host. It is up to the application to determine how this
error condition is handled.
If the software is loading one packet per frame(/microframe) and it finds that the TXPKTRDY bit in the
PERI_TXCSR register (bit 0) is set when it wants to load the next packet, this indicates that a data packet
has not been sent (perhaps because an IN token from the host was corrupted). It is up to the application
how it handles this condition: it may choose to flush the unsent packet by setting the FLUSHFIFO bit in
the PERI_TXCSR register (bit 3), or it may choose to skip the current packet.