Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

USB superspeed peripherals Forum Discussions

NoAr_1540581
Level 5
Level 5
250 sign-ins 100 replies posted 100 sign-ins

Hello

Here is my understanding of which errata corresponds to the three  "2.2 Unexpected Connection Failures"  items of  TroubleShooting Guide.
Please tell me if it is correct or not.

>o The USB driver in the FX3 SDK monitors the number of USB link errors that are

>detected by the hardware; and causes a re enumeration when the number of errors

>crosses a threshold value (about 64 errors) within a 1 second p eriod. This code is

>not expected to come into play on a functional link, because there will be not more

>than one or two errors per second happening. If the device is re enumerating, it is

>likely that there is a bad USB link due to bad interconnect cables o r traces.

>
➡ Not equivalent to any errata.

o Another reason for USB 3.0 connection errors is link errors that happen around link

>power state transitions. The best option to avoid such problems is to prevent USB

>3.0 link state transitions, by having the FX3 device systematically reject any l ow

>power requests.

>o It is recommended to disable the low power mode transitions by calling

>CyU3PUsbLPMDisable() API when the data transfers are active because there may

>be cases where the host performs very fast U1 Entry/Exit (Entry to Exit duration < 5

>µs) and the firmware is not capable of responding to such fast low power mode

>transitions.

>The FX3 device can be placed in this mode by making use of the

>CyU3PUsbLPMDisable() API. Please note that using this API can also help

>improve the USB data transfer per formance because of increased link efficiency.

➡ The above two items correspond to errata No. 7.

Best Regards

Arai

0 Likes
1 Solution
HirotakaT_91
Moderator
Moderator
Moderator
50 likes received 25 likes received 10 likes received

From past long experience with FX3, the only case where we have seen a very high frequency of link errors is not recoverable. When FX3 gets into such a situation, any number of recovery attempts do not help and we keep cycling through recovery. The error threshold (64) was brought in as a work-around for such cases.

FX3 uses the LNK_ERROR_COUNT register to track the number of link errors logged by FX3. The register is cleared periodically (every 1 second). If we see that the count is reaching 64 errors (within 1 second), we power cycle the PHY. In many cases, this helps recovery. This reset feature is intentionally implemented for above reason.

Regards,

Cypress

View solution in original post

0 Likes
1 Reply
HirotakaT_91
Moderator
Moderator
Moderator
50 likes received 25 likes received 10 likes received

From past long experience with FX3, the only case where we have seen a very high frequency of link errors is not recoverable. When FX3 gets into such a situation, any number of recovery attempts do not help and we keep cycling through recovery. The error threshold (64) was brought in as a work-around for such cases.

FX3 uses the LNK_ERROR_COUNT register to track the number of link errors logged by FX3. The register is cleared periodically (every 1 second). If we see that the count is reaching 64 errors (within 1 second), we power cycle the PHY. In many cases, this helps recovery. This reset feature is intentionally implemented for above reason.

Regards,

Cypress

0 Likes