Can the error cased re-enumerating threshold be changed?

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

cross mob
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello,

          On Page 5 of the FX3 SDK troubleshooting guide, it says that 

          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 period. This code is not expected to come into play on a functional link, because there will be no 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 or traces. 

          My question is that if this threshold (64 errors) can be modified?   Or can this  re-enumerating be disabled ?   We do not want the USB disconnect.  The error handle on the bulk/control endpoint seems easier to do than re-enumerating. 

 

Best regards,

Qiu

 

  

0 Likes
1 Solution
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Editted

Hello Qiu,

Thank you for the confirmation. But, disabling LPM permanently can make the device to fail the compliance tests.

Can you please try to use CyU3PUsbLPMDisable () just before the data transfers and re-enable them after the data transfers? Please let me know if this suggestion can also solve the issue or not. We suspect that the issue seen here is same as the issue mentioned in the following thread:

https://community.cypress.com/t5/USB-Superspeed-Peripherals/Getting-CY-U3P-USB-EVENT-SETCONF-event-i...

Even though the above thread is on CX3, the same problem can occur on FX3 also.

Best Regards,
Jayakrishna

View solution in original post

0 Likes
14 Replies
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Please find my comments for your questions below:

1. My question is that if this threshold (64 errors) can be modified?   Or can this  re-enumerating be disabled ? 

>> No, it is not recommended to change the existing implementation in SDK. Also, we do not have a way to modify the threshold or re-enumeration feature implemented in the USB driver.

As mentioned in the FX3 SDK Troubleshooting Guide, 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 or traces.

You can try the following recommendations if this issue is seen:

1. Increase the TX swing, please check our API guide on how to use this.
2. It might be because of the bad board design which leads to signal integrity issues. This can be removed by designing the board by carefully following the recommendations in AN70707. The link to AN70707 is given below:

https://www.cypress.com/file/139936/download

Also, as mentioned in the FX3 SDK troubleshooting guide, 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 low power requests.

Best Regards,
Jayakrishna
0 Likes
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello, 

       Thank you for your suggestion. We will check it. We kept on monitoring the error report from the bulk/endpoint transfer state and have no other error appears.   And suddenly it re-enumerating. Normally it needs to wait some hours to happen. And it only appears in a little amount of the computer/board combinations.

 

Best regards,
Qiu

 

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello,

Please try the suggestions mentioned in my previous response. In addition to this, please confirm that you are using FX3 SDK 1.3.4 for building the firmware. Also, please share the USB logs for us to check. You can refer to the SDK example project USBBulkSrcSink to understand how to obtain the USB logs.

Best Regards,
Jayakrishna
0 Likes
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello,

 

We did some tests by modifying the TxSwing and De-Emphasis. Seems it take function in one or two computer. But not take effection in other two computers. So the test results is un-certain to us. 

For USB log. We have added it and it returns 0x98,0x90,0x91 in most of the computers. But in one computer it returns rarely the 0X99.  But when the disconnect happens, it has no other number appears in the log queue.

The disconnect event happens rarely.  In most computers, it does not happen. In one computer it happens for about 48 hours. On another computer, it happens in two hours.  Looks highly depent on the computer. If we exchange the device, the computer which has this issue will still has this issue. 

Seems it is just a disconnect. But it does not do the reset or re-enumerating. (The firmware is not re-downloaded).So it is not a MCU rest.

I have a question that if the USB link rests when error>64 exists in all of the SDK version, like 1.2.3 , or it is newly added in the 1.3 ?

 

Best regards,

Qiu

 

    

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello Qiu,

How did you confirm that the disconnect is caused by the link errors crossing the threshold of 64? Because if the link errors crosses 64, then the device will re-enumerate (the device will disconnect and reconnect). Also, the entry 0x52 will be obtained in the USB logs. As both of these are not seen, I don't think the issue is caused by the link errors crossing the threshold of 64. 

As you mentioned, it could be something related to the host PC itself. Can you please confirm that you are using FX3 SDK 1.3.4 for testing? Also, please disable the LPM by using the API CyU3PUsbLPMDisable() before performing data transfers.

Can you please share Wireshark traces when the failure is seen? This can be used to understand if the device is re-enumerating or not.

Best Regards,
Jayakrishna
0 Likes
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello Jayakrishna,

Thank you very much for your quick answer.  For the reconnect. We can hear the windows USB connect/reconnect sound and also we keep on monitor the windows pnp event with a API and it shows there is the device disconnect/reconnect happening.  But we do not found the 0x52 in USB log. 

Seems the ARM is still keeping on running without anything changed after this reconnect.  All the value that initiated is still keeping the same. 

We have add the  CyU3PUsbLPMDisable() API before it.

If the SDK the compile using is default in the firmware/u3p_firmware ?  I checked the cyfxapi.a in the firmware/u3p_firmware/lib/fx3_debug and fx3_release. From the size , one is 8839kB another is 8788kB it should be the 1.3.4.  

BTW: We changed the CyFxApplnUSBEventCB a little to prevent the CyFxAppInStop. I do not know if there is a reason that there is no 0X52 happen.

 

    case CY_U3P_USB_EVENT_DISCONNECT:
        /* Stop the function. */
     CyU3PDebugPrint (1,"CY_U3P_USB_EVENT_SETCONG RESET----");
        if (glIsApplnActive)
        {
           // CyFxApplnStop ();  
        }
 
        break;

 

       We will try the Wireshark to trace the failure. 

Best regards,

Qiu 

 

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello Qiu,

Please open your project in EZ USB Suite. After this, go to Project Properties -> C/C++ Build -> Build Variables. In this settings, please check if the FX3SDKVERSION string is set to 1_3_4. In addition to this, please let me know where exactly in the code is the API CyU3PUsbLPMDisable () used.

Also, as 0x52 is not present in USB logs, we cant confirm that the issue occurred due to the link error count crossing the threshold of 64.

Best Regards,
Jayakrishna
0 Likes
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello,  

       I checked the build variables but not found the keyword of FX3SDKVERSION. Now add one and re-testing.  

 

Best regards,

Qiu

 

0 Likes
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello,

         We added the the FX3SDKVERSION and set to 1_3_4.  The test result is the same as before.  

For the CyU3PUsbLPMDisable()  , it is in the CyFxApplnInit().   After the CyU3PUsbStart() and CyU3PUsbRegisterSetupCallback and CyU3PUsbRegisterEventCallback. 

 

 We print the USBD status record when the failur happen, it is 

FinishDataXfer return false:

USBD=c0010000
USBD=c80000300

......  (a lot of)

USBD=c80000300

device PNP event detected (device disconnect and then reconnect)

 

All of above error is within one second.

Best regards,

Qiu

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello Qiu,

Please share the project for us to check.

Please check if the CY_U3P_USB_EVENT_RESET was obtained as an evType in the USB event callback function. In addition to this, please let me know if the LPM is enabled at some point using the API CyU3PUsbLPMEnable ().  This is because, in the USB logs, I found that the link was going to U1 power state (0x91).

"All of above error is within one second."

The above statement in your previous response cannot be used to understand that the failure is caused due to the link errors crossing the threshold of 64. You can try using the API CyU3PUsbGetErrorCounts to get the number of link and phy errors detected by FX3. After this, please let me know the error count obtained.

Best Regards,
Jayakrishna
0 Likes
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello,

         We improved the usb log event record and now we capture some data when the issue  happened. , it is 

84 84 84 84 84 81 11 88 89 8A 8B 25 26 17    All the number is HEX. 

 

          And in normal time,  the USB log is always in a cycle of 90,91,98 ...... It shows the LTSSM state is keeping on changing from U0 and U1. 

           And we found one problem in the code. The CyU3PUsbLPMDisable() is before the U3PConnectState(). Now we move it after the U3PConnectState() and add some delay between them. Now there is no the U0/U1 change in the log. 

 

          We will test if this can solve the issue.

 

Best regards,

Qiu

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hello Qiu,

Thank you for sharing the logs with us. Can you please let me know what was the entry before 0x84? This will help us to understand more about the problem.

And yes, please test the project with the modification that was done and let me know the result.

Best Regards,
Jayakrishna
0 Likes
qiu
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello Jayakrishna,

 

We can confirm the problem solved compeletely after put the CyU3PUsbLPMDisable() in the correct location. For the USB log before 84. We need to modify the output code to have a check. In the 90 91 98 cycle it runs very fast so we have filter off these number during the test.

 

Best regards,

Qiu 

0 Likes
JayakrishnaT_76
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Editted

Hello Qiu,

Thank you for the confirmation. But, disabling LPM permanently can make the device to fail the compliance tests.

Can you please try to use CyU3PUsbLPMDisable () just before the data transfers and re-enable them after the data transfers? Please let me know if this suggestion can also solve the issue or not. We suspect that the issue seen here is same as the issue mentioned in the following thread:

https://community.cypress.com/t5/USB-Superspeed-Peripherals/Getting-CY-U3P-USB-EVENT-SETCONF-event-i...

Even though the above thread is on CX3, the same problem can occur on FX3 also.

Best Regards,
Jayakrishna
0 Likes