Functional Description
16.3.8.1.4.2.2 Isochronous OUT Operation: Peripheral Mode
An Isochronous endpoint does not support data retries so, if a data overrun is to be avoided, there must
be space in the FIFO to accept a packet when it is received. The host will send one packet per frame (or
microframe in High-speed mode); however, the time within the frame can vary. If a packet is received near
the end of one frame(/microframe) and another arrives at the start of the next frame, there will be little time
to unload the FIFO. For this reason, double buffering of the endpoint is usually necessary.
An interrupt is generated whenever a packet is received from the host and the software may use this
interrupt to unload the packet from the FIFO and clear the RXPKTRDY bit in the PERI_RXCSR register
(bit 0) in the same way as for a Bulk Rx endpoint. As the interrupt could occur almost any time within a
frame(/microframe), depending on when the host has scheduled the transaction, the timing of FIFO unload
requests will probably be irregular. If the data sink for the endpoint is going to some external hardware, it
may be better to minimize the requirement for additional buffering by waiting until the end of each
frame(/microframe) before unloading the FIFO. This can be done by using either the SOF interrupt or the
external SOF_PULSE signal from the controller to trigger the unloading of the 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 clear the RXPKTRDY bit in PERI_RXCSR
and to check for data overruns/underruns.
16.3.8.1.4.2.3 Isochronous OUT Error Handling: Peripheral Mode
If there is no space in the FIFO to store a packet when it is received from the host, the OVERRUN bit in
the PERI_RXCSR register (bit 2) will be set. This is an indication that the software is not unloading data
fast enough for the host. It is up to the application to determine how this error condition is handled
If the controller finds that a received packet has a CRC error, it will still store the packet in the FIFO and
set the RXPKTRDY bit (bit 0 of PERI_RXCSR) and the DATAERROR bit (bit 3 of PERI_RXCSR). It is left
up to the application to determine how this error condition is handled.
The number of USB packets sent in any microframe will depend on the amount of data to be transferred,
and is indicated through the PIDs used for the individual packets. If the indicated number of packets have
not been received by the end of a microframe, the INCOMPRX bit (bit 8) bit in the PERI_RXCSR register
will be set to indicate that the data in the FIFO is incomplete. Equally, if a packet of the wrong data type is
received, then the PID Error bit is the PERI_RXCSR register will be set. In each case, an interrupt will,
however, still be generated to allow the data that has been received to be read from the FIFO.
Note: The circumstances in which a PID Error or INCOMPRX is reported depends on the precise
sequence of packets received.
When the core is operating in peripheral mode, the details are in
.
Table 16-8. Isochronous OUT Error Handling: Peripheral Mode
No. Packet(s) Expected
Data Packet(s) Received
Response
1
DATA0
OK
DATA1
PID Error set
DATA2
PID Error set
MDATA
PID Error set
2
DATA0
OK
DATA1
INCOMPRX Set
DATA2
INCOMPRX Set + PID Error set
MDATA
INCOMPRX Set
MDATA DATA0
PID Error Set
MDATA DATA1
OK
MDATA DATA2
PID Error Set
MDATA MDATA
PID Error Set
3
DATA0
OK
DATA1
INCOMPRX Set
1717
SPRUH73H – October 2011 – Revised April 2013
Universal Serial Bus (USB)
Copyright © 2011–2013, Texas Instruments Incorporated