Regarding errata support in errata in FX3 SDK1.3.4

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

cross mob
NoAr_1540581
Level 5
Level 5
Distributor - Macnica (Japan)
5 solutions authored 250 sign-ins 100 replies posted

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
500 replies posted 250 replies posted 100 replies posted

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
500 replies posted 250 replies posted 100 replies posted

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