FX3 Enumeration Issue "Device descriptor request failed"

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

cross mob
StPo_1480841
Level 1
Level 1

Hi,

We have a custom board using the FX3 chip. We have noticed a very rare issue (seemingly < 1%) where the FX3 does not properly enumerate on the USB. What we can observe is that on windows, we get the following error message on the device manager: "device descriptor request failed" and shows up as "Unknown Device". Nothing shows up in the cypress control center. The firmware I am using on the FX3 is identical to the "slfifosync" example firmware with very minor changes to buffer sizes and descriptor texts. The SDK version is 1.3.3. We have found a way to force the issue by slightly unplugging the cable such that it is on the edge of connecting and then reconnecting it - this seems to force it into this state. It's as if the FX3 has entered a bad state where it cannot recover except for a power cycle. I have read some other similar discussions and I have made sure that in my entire firmware project for the FX3 that no where is LPM enabled and the disable function call is found here in "cyfxslfifosync.c"

    

/* This is the callback function to handle the USB events. */

void

CyFxSlFifoApplnUSBEventCB (

    CyU3PUsbEventType_t evtype,

    uint16_t            evdata

    )

{

    switch (evtype)

    {

        case CY_U3P_USB_EVENT_SETCONF:

            /* Stop the application before re-starting. */

            if (glIsApplnActive)

            {

                CyFxSlFifoApplnStop ();

            }

            CyU3PUsbLPMDisable();

            /* Start the loop back function. */

            CyFxSlFifoApplnStart ();

            break;

        case CY_U3P_USB_EVENT_RESET:

        case CY_U3P_USB_EVENT_DISCONNECT:

            /* Stop the loop back function. */

            if (glIsApplnActive)

            {

                CyFxSlFifoApplnStop ();

            }

            break;

        default:

            break;

    }

}

Does anyone know what might be causing this issue? Or any insight into how to further characterize this failure?

Any thoughts would be greatly appreciated.

Thank you.

0 Likes
1 Solution

Hello Stephen,

Thank you for the updates

Program "arm-elf-gcc" not found in PATH SlaveFifoSync [Discovery Options] page in project properties C/C++ Problem

Program "arm-elf-g++" not found in PATH SlaveFifoSync [Discovery Options] page in project properties C/C++ Problem

Program "make" not found in PATH SlaveFifoSync C/C++ Problem

>>These errors are due to incorrect path for compiler, linker. You can refer to this web link https://embdev.net/topic/223850 .

You need to set correct PATH for Compiler, linker  Project > Properties > C/C++ Build > Settings > Tool Settings and set the path as per FX3 installation path

- Can you try plugging the device on different host machines and let me know the results

- Also, probe the USB lines using wireshark (when improper enumeration) and share the .pcap file

- If possible, share the descriptor.c file for us to check on our end

Regards,

Rashi

Regards,
Rashi

View solution in original post

0 Likes
5 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Stephen,

1) Please let me know whether this happens every time you program the FX3 and plugin the device.

2) Can you program the FX3 with default firmware (slavefifo) and let me know the results.

3) This issue can be due to descriptor size mismatch.

Please share the firmware so that i can check at my end.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hi Rashi,

1) As I mentioned, it happens very rarely. Less than 1% of the time. Our system has the FX3 board plugged into a USB host, the issue happens when this system powers up.

2) I am attempting to load the default firmware but am having difficulties setting up the eclipse environment so will have to get back to you on that, but the project I am using is practically identical.

3) If the issue is due to device descriptor size mismatch, would that cause the issue 100% of the time? Or can that explain the ~1% of the time we observe the issue?

Thanks

0 Likes

Unfortunately, I am unable to share my exact firmware project with you due to export control restrictions.

I have downloaded and installed the latest 1.3.4 SDK and when I follow the SDK guide on running example projects, I successfully import the example slfifosync project into eclipse but get the following three errors when attempting to build:

     -Program "arm-elf-gcc" not found in PATH SlaveFifoSync [Discovery Options] page in project properties C/C++ Problem

     -Program "arm-elf-g++" not found in PATH SlaveFifoSync [Discovery Options] page in project properties C/C++ Problem

     -Program "make" not found in PATH SlaveFifoSync C/C++ Problem

Do you happen to understand why I am getting these errors?

Thanks

0 Likes

An update:

In our FX3 firmware we have the burst length set to 16. Changing this to 1 seemed to drastically affect the behavior we are observing. The issue still exists, but it is able to recover itself after a few seconds have passed. However, 1/4 of the time this error happens it does not recover. This is better than before, but still we would like to be able to guarantee this does not happen. Hopefully that is a clue of some kind.

Thanks

0 Likes

Hello Stephen,

Thank you for the updates

Program "arm-elf-gcc" not found in PATH SlaveFifoSync [Discovery Options] page in project properties C/C++ Problem

Program "arm-elf-g++" not found in PATH SlaveFifoSync [Discovery Options] page in project properties C/C++ Problem

Program "make" not found in PATH SlaveFifoSync C/C++ Problem

>>These errors are due to incorrect path for compiler, linker. You can refer to this web link https://embdev.net/topic/223850 .

You need to set correct PATH for Compiler, linker  Project > Properties > C/C++ Build > Settings > Tool Settings and set the path as per FX3 installation path

- Can you try plugging the device on different host machines and let me know the results

- Also, probe the USB lines using wireshark (when improper enumeration) and share the .pcap file

- If possible, share the descriptor.c file for us to check on our end

Regards,

Rashi

Regards,
Rashi
0 Likes