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:

1.1

Details:

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).

Workaround(s):

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

TMS320DM335 Digital Media System-on-Chip (DMSoC)

23

Silicon Revision 1.1

Submit Documentation Feedback