- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi