K20 USB-FS device behavior when the host does not ACK

[lasseh]

How does the USB-FS module, configured as a USB device, behave in case that host does not anwer ACK device's response to an interrupt endpoint IN token? This happens if data sent by the device got corrupted, or if the host was not ready for it.

-Does the USB-FS automatically continue trying to resend the same data on subsequent IN token receives? (Until receiving ACK, software crash, or power off...)

-Is observing USBx_ERRSTAT register bit BTOERR (bus turnaround timeout error) the mechanism to recognize this situation?

The reference manual does not seem to specify USB-FS behaviour in this situation, but the USB specification suggests something like this.

[lasseh]

Thanks Mark!

That sounds reasonable, checking CRC errors sounds like a good idea!

Can you (or someone else) confirm when this automatic data resending happens? Is it after receiving the next IN token,  like I assume?  (= Not immediately after turnaround timeout error.)

[mjbcswitzerland]

Hi

When a data packet is "lost" the device repeats the data when the host next sends an IN packet (the device can only send data, or repeated data, in response to an IN and not at any other point in time).

How long the next IN packet takes to be received depends on available bandwidth on the bus but it is generally immediate (after the host has recognised that there was an error).

Regards

Mark

[mjbcswitzerland · Accepted solution]

Hi

When there is no ACK from the host the USB controller automatically resends the data.

I have never seen it happen, but I believe that the BTOERR flag is set in this case becasue it will be set whenever there is a 16 bit delay between the IN TOKEN and the ACK.

It is highly unlikely that the problem will be due to the host not being ready since the host is controlling this in its HW controller and will not have sent an IN if not ready. More likely is a corruption due to noise/interference.

When testing USB connection in the presence of noise/interference the first thing that is seen is that the device will receive CRC errors (CRC16 for data or CRC5 for token packets). There are signalled by CRC16 and CRC5EOF in the ERRSTAT register. These can also be detected by enabling their interrupt sources.

Generally it would be advisable to monitoir the CRC errors as higher priority to turnaround errors since they are the ones that will better detect a connection prone to interference since it will be detecting every USB host IN token that failed - the turnaround error is probably a consequence of the poor connection quality and will only occur when the device actually sends data back in response to the IN token (which is usually a small percentage of the IN tokens).

Regards

Mark