I would like to get more details on the application to debug the issue
- Please let me know when are these events seen. Is it during the transfers from FX3 to host or while host to FX3?
On failing hosts we can see that phy and link errors increase
>> Please let me know if you have tried connecting FX3 to different host PC and the events are seen only with some of the host PC and work fine with others. If yes, what are PC specification with which the USB link fails?
>> Please let me know more about the hardware setup. Is the device (FX3) is directly connected to the host or is connected via a USB hub?
>> Please share the complete debug prints to check the events logged by CyU3PUsbEventLog API. Also, let me know what happens after these events are seen. Does the Device re enumerate?
What could be the reason for this kind of errors?
>> CYU3P_USB_LOG_USBSS_LNKFAIL error occurs when the number of link errors exceeds the threshold count.
>> CYU3P_USB_LOG_USB_HP_TIMEOUT Header Packet acknowledgment has not been received before the timer expires
Both these events occur due to a bad USB link.
Please confirm if the SDK version you are using is 1.3.4. with the build variable (project settings> c/c++ build>Build variable) of the firmware as 1_3_4.
Also, please try using a different USB cable and let me know if there are some improvements
we already have tried different hosts, USB ports and cables and also connected USB3 hubs in between.
The result always looks different. Some combinations work better while other show link problems.
In the FX3 firmware sources we found one thing helped us to improve the USB link stability. There is a
function CyFx3Usb3LnkRelaxHpTimeout() that is normally called in the firmware when two link errors
have been detected. But we use this function from the beginning and could improve the overall link stability.
Are there more of these "hidden functions" that can help here?
- We use SDK version 1.3.4.
- When the link gets blocked it does not automatically re-enumerate. We added some logic that detects such
a condition based on CyU3PUsbEventLog and trigger the re-enumeration on the device side.
Please replace the attached library at the following location:
FX3 SDK installation path\Cypress\EZ-USB FX3 SDK\1.3\fw_lib\1_3_4
Please put the debug version in the fx3_debug folder and the release version in the fx3_release version and then build the application with the new library. Please let me know if this solves the problem
Note: Please make a copy of the original library before placing the new one.
modified_lib_FX3.rar 856.6 K
thanks for the new version. We will test it.
What are the changes compared to the standard 1.3.4 firmware?
The library attached in the previous post is modified to relax the PENDING_HP_TIMER value to 10us and also has some other fixes.
Please let me if the modified library solves the problem.
My name is Andre. I am a colleague of Sven.
The previously attached library works better for us. It does not solve all our Problems, but we see a clear improvement.
Is it possible to increase the timeout further? Could we get the source code or the source code diff to SDK 1.3.4?
Thanks & Regards,
The latest USB3 specification (table 7.7) relaxes the PENDING_HP_TIMER value to 10us only.
Please let me know if CYU3P_USB_LOG_USB_HP_TIMEOUT and CYU3P_USB_LOG_USBSS_LNKFAIL is still seen and how frequent are these events seen.
In our test we are constantly transferring data. I can see two errors in the log during the test:
- 0xAB (CYU3P_USB_LOG_EPM_RESET)
- 0xAF (CYU3P_USB_LOG_EP_UNDERRUN);
The errors occur after several minutes of data transfer. I've started the test four times. It failed after 3 minutes, 2:30 minutes, 15 minutes and 8 minutes. The CYU3P_USB_LOG_EP_UNDERRUN error appeared just once. Mostly I see CYU3P_USB_LOG_EPM_RESET.
It seems that the timeout error is gone now. Please advice further.
Thanks & Regards,
0xAB (CYU3P_USB_LOG_EPM_RESET) event is registered when CYU3P_USBEP_SS_RESET_EVT is triggered.
Please refer to subsection IV of section 2.3 of the FX3_SDK_Troubleshooting Guide (in the SDK) for the reason of CYU3P_USBEP_SS_RESET_EVT and the workaround.
As per the workaround mentioned in the above document
- Register for the Endpoint event callback
CyU3PUsbRegisterEpEvtCallback (CyFxApplnEpCallback, 0x1B0, 0x04, 0x06);
- Stall the endpoints when CYU3P_USBEP_SS_RESET_EVT
Fom gpiftousb example of the SDK
if (evtype == CYU3P_USBEP_SS_RESET_EVT)
if (epNum == CY_FX_EP_CONSUMER)
CyU3PDebugPrint (2, "Halting USB Streaming EP: %d\r\n", BulkRstCnt++);
CyU3PUsbStall (CY_FX_EP_CONSUMER, CyTrue, CyFalse);
if (epNum == CY_FX_EP_LOOP_IN)
CyU3PDebugPrint (2, "Halting USB Loopback EP: %d\r\n", LoopRstCnt++);
CyU3PUsbStall (CY_FX_EP_LOOP_IN, CyTrue, CyFalse);
- On seeing the STALL on the endpoint, the host is expected to send a CLEAR_FEATURE request.
The recommended recovery from the CYU3P_USBEP_SS_RESET_EVT procedure is to STALL the endpoint, and then stop and restart the DMA data path when the CLEAR_FEATURE request is received from the host.
As the USB3.0 link is bad, you can try calling CyU3PUsbSetTxSwing API to set the Tx amplitude range for the USB 3.0 signals.
This API sets the Tx amplitude used by FX3 on the USB 3.0 interface. The device has only been tested to work properly under the default swing setting of 0.9V (swing value set to 90). This API is expected to be called before calling the CyU3PConnectState() API to enable USB connections. The swing value should be less than 1.28V (128). You can refer FX3APIGuide in the SDK for more details.
Please let me know if this helps.
changing the TxSwing did not show any improvement. Is it possible to do something on the RX side?
Furthermore I've implemented the things you've suggested. I saw the CYU3P_USBEP_SS_RESET_EVT on one of our consumer endpoints and called CyU3PUsbStall(EP, CyTrue, CyFalse).
I can see that the Setup callback is called again with parameters setupdat0 = 0x102 setupdat1 = 0x86. I am doing the things for the failing endpoint in the setup function as in the GpifToUsb example. Here is the code snippet from GpifToUsb example:
if (wIndex == CY_FX_EP_CONSUMER)
CyU3PUsbSetEpNak (CY_FX_EP_CONSUMER, CyTrue);
CyU3PDmaChannelSetXfer (&glDmaChHandle, CY_FX_GPIFTOUSB_DMA_TX_SIZE);
CyU3PUsbStall (wIndex, CyFalse, CyTrue);
CyU3PUsbSetEpNak (CY_FX_EP_CONSUMER, CyFalse);
isHandled = CyTrue;
It seems that I now can detect such errors. But I still don't know how to prevent them or how to recover from them. The USB event log still shows 0xAB (CYU3P_USB_LOG_EPM_RESET). Our data transfer is ended as well.
What are the next steps in your opinion?
Thanks & Regards,
Is it possible to do something on the RX side?
>> Please let me know if the CYU3P_USBEP_SS_RESET_EVT occurs for the Consumer endpoint (IN endpoint) or Producer endpoint (OUT endpoint). The GPIF to USB example registers the events for the IN endpoints only.
It seems that I now can detect such errors. But I still don't know how to prevent them or how to recover from them. The USB event log still shows 0xAB (CYU3P_USB_LOG_EPM_RESET).
>> Using the workaround mentioned in the troubleshooting guide, it is expected to recover from the freeze condition when CYU3P_USB_LOG_EPM_RESET is seen.
>> CYU3P_USBEP_SS_RESET_EVT will be notified by the library to the firmware when there are a lot of retries happening on the USB bus as mentioned in the troubleshooting guide.
>> Is the CYU3P_USB_LOG_EPM_RESET events seen again after the recovery from the CYU3P_USBEP_SS_RESET_EVT is done?
>> How many times is CYU3P_USBEP_SS_RESET_EVT seen after CLEAR FEATURE is sent by host and Endpoint is reset and flushed.
Our data transfer is ended as well.
>> Please let me know the direction of the transfer. Also, are the transfers stopping after CYU3P_USB_LOG_EPM_RESET.
Please confirm if CyU3PUsbResetEndpointMemories API is not directly called from the firmware