TMS320DM335_2 Datasheet, PDF (23/26 Pages) Texas Instruments – Digital Media System-on-Chip (DMSoC) Silicon Revision 1.1

www.ti.com
Advisory 1.1.12 — USB (Device Mode): Calculated CRC Value Does Not Match Host CRC Value
Advisory 1.1.12
USB (Device Mode): Calculated CRC Value Does Not Match Host CRC Value
Revision(s) Affected:
Details:
Workaround(s):
1.1
The USB Controller can occasionally calculate a bad CRC for a received data packet.
This error is rare and only occurs when ALL of the following conditions are met:
• USB Controller is in Device Mode of Operation and is receiving data
• Received data packet has a good CRC value of 0x7FF2
• A timing violation caused by a synchronization error (race condition)
The timing synchronization error is caused by a race condition between two control
signals in the PHY Clock and System Clock domains. When these two synchronized
control signals are crossing a clock boundary and the received data packet has a good
CRC value of 0x7FF2, a race condition may occur causing one of the control signals to
be latched a few pico-seconds ahead of the other control signal.
The issue has been observed on both Bulk (Non-Isochronous) and Isochronous transfers
and may potentially exist on Control and Interrupt transfers since the data paths for all
these transfers are the same or are very similar.
When the problem occurs in Non-Isochronous transfer types, the data that was "in-flight"
to the USB Controller’s FIFO from the Host is discarded by the USB Controller. Due to
the error condition, the USB Controller also refrains from sending an ACK packet to the
Host, as mandated by the USB transfer protocol. This forces the Host to re-transmit the
data packet, anticipating an error in data transmission. The problem is usually corrected
when the Host re-transmits the data packet.
When this problem occurs in Isochronous transfer mode for either High- or Full-speed,
the USB Controller flags the device application S/W that a CRC error existed but retains
the received data within the FIFO as well as captures the received data packet size
value minus one byte from the actual data size. Since the magnitude of the actual timing
violated due to the synchronization problem is only in pico-seconds, the entire data sent
from the Host is routed into the USB device receive FIFO (i.e., even though the received
data counter is one byte less, the full data packet is available for the USB driver).
Case 1a: Non-Isochronous Transfers (High-Speed): For non-Isochronous transfers
operating in High-Speed mode, the Host and Device H/W perform the necessary
re-transmission; thererfore, the issue should be transparent to the Host driver. The issue
will also be transparent to the USB device driver since the H/W flushes the received data
and forces the Host driver to re-transmit by not sending an ACK packet. For this reason,
no interrupt is generated by the H/W to signify an error condition to the device-side
application S/W.
Although quite rare, when both the Host and Device are operating in High-Speed mode
and all the three consecutive transmissions did not occur without an error, the Host will
use a PING packet at a later time to check if the endpoint is ready for accepting data.
Upon the Host receiving an ACK packet in response to the PING packet, the Host
re-initiates the previously failed transmission again. This process continues until the
transfer takes place without error. For this reason, the Non-Isochronous High-Speed
transfer is immune to this issue except for a throughput reduction for the time it takes for
the re-transmission.
Case 1b: Non-Isochronous Transfers (Full-Speed): For non-Isochronous transfers
operating in Full-Speed mode, it is recommended that the Host driver be constructed in
such a way that it invokes the transfer multiple times prior to forcing a reset to the USB
device. When the transfer is repeated, it is expected for the transfer to complete
"error-free".
If the Host driver is not "set up" to invoke multiple failed transfers then, the Host driver
will reset the USB driver, re-enumerate, and continue from where it left off.
SPRZ287A – July 2008 – Revised October 2008
Submit Documentation Feedback
TMS320DM335 Digital Media System-on-Chip (DMSoC)
23
Silicon Revision 1.1