Recently we have been improving the testing of our STM32F405 based systems, including the robustness of the PC<>USB interface. A few of the tests look for issues when the USB connection is suddenly removed or reconnected. This is done by using a commercial USB controllable relay board in the USB lead to simulate the USB plug being pulled out or re-inserted.
We were predominantly looking for issues with our firmware, but we believe we might have found a lower-level issue independent of our software as we can now trigger it using a STM32F407G-DISC1 and minimal STM32Cube app. This uses the USB-FS interface with a Custom HID class driver.
The issue is that after a number of dis/re-connect cycles the USB block does not reconnect properly. On a Windows PC the device is listed in the device manager, but is marked as 'not recognized'.
There are obviously lots of different variables when dealing with USB connections, such as PC hardware, OS, cabling etc. and we certainly see differences between systems, so here are some comments and observations on the testing we've done:
- The number at which the test fails is highly PC dependent, but quite reliable for that PC. On some systems it runs for 10s of thousands of dis/reconnect cycles before failure, on others it is in the thousands and some systems in the low hundreds (and sometimes in the tens).
- We have setup a Microchip PIC to run an equivalent firmware. This kept going for >70k cycles before we stopped it, even on the worst PC.
- The ARM USB block appears quite dead. If the ARM is kept powered and plugged into another PC it does not work in that PC either.
- The only way to get the ARM to reconnect is to fully reset it, we believe resetting the USB block isn't enough.
Does anyone have any thoughts on what might be going wrong?