We are currently using the G400-D module on a custom board and it connects to another custom board via USB Host.
Our environment can be noisy at times which has led us to receive BAD CRC, Bit-stuff Errors and SOF Frame Count Errors. In some cases this causes the device board to disconnect from the USB host (G400-D board). The strange thing is that the USB device is unable to reconnect to the host and just sits in a disconnected state. Even after physically unplugging and reconnecting the device board it still is unable to communicate.
When the same device board is connected to a windows system as the USB host (running software) we do not see any issues with the device being unable to reconnect. The same errors do occur but there is no reconnect issue.
Our question is regarding the USB host stack. Is their a way that we are able to force this reconnect? Also, from a USB host source code POV, can GHI identify reasons for the host stack to lock up or get into an exception that could cause it to stall?
As a note, we are have tested and debugged the device board and it does not reset or stall but the USB stack simply disconnects and sits waiting to be attached. Regarding the host side board, we have a USB port connected directly to the G400 through a CMC and ferrite bead for filtering.
@ Player6h4 - have you tried to connect the device board to a standard GHI mainboard like the Raptor to determine if it is a general problem or specific to your custom board?
Yes, we have tested the G400 on the breakout board with the same result. We have not tested it on the raptor.
@ Player6h4 - did you use a GHI host module with the G400 breakout board?
We actually just wired up a USB connector to the board due to the simplicity of the connection.
Is anyone aware of locking up issues on the USB host stack?
Thanks for the help.
I do not remember ever hearing about a USB hangup. I am not sure wiring up a USB socket is “simple”. You are going to have to provide a lot more information about your noisey environment if someone is going to be able to recreate the problem. You might also want to engage GHI to assist you in isolating the problem.
Actually wiring up a USB socket is very straightforward and this is verified via the schematic for the USB host module that you inquired about.
I believe that without the other devices our the system causing the noise, it is going to be very difficult for anyone to reproduce the issue we are seeing. Our goal is for GHI to analyze their libraries and attempt to determine where some of the standard USB errors can cause the bus to lockup and become unrecoverable.
We will be contacting GHI directly as well but wanted to see if the community had any ideas.
Again, thanks for the help.
I suspect the point Mike was making is that USB uses differential signaling and things like trace length and impedance matching is important, so “wiring one up” is actually quite challenging, not from a how-to perspective but from a how-to-properly perspective.
@ Brett and Mike,
Agreed and understood. We are on the same page now. LOL
All we need is a complete, yet simple, app that shows the problem so we can run it on our bench, with a debugger and USB analyzer connected.