STM32F4xx USB device fails after multiple dis-/re-connect cycles

richard239955_stm1_st · ‎2018-04-09

Posted on April 09, 2018 at 11:51

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?

Regards,

Richard

#usb-fs #usb-hid #usb-device

waclawek.jan · ‎2018-04-09

Posted on April 09, 2018 at 13:45

Apply standard debugging procedures - observe OTG_FS registers, the 'driver''s data/structures; breakpoint/step through the ISR after the failure; output/store traces of suspicious items throughout the 'failure' happens, etc.

JW

richard239955_stm1_st · ‎2018-04-09

Posted on April 09, 2018 at 19:34

Hi Jan,

Thanks for the input on this. We've actually done a fair amount of that type of investigation on the issue, but I didn't want to confuse by putting too much detail in my initial email.

After the problem occurs it seems that the PCD is still receiving interrupts, including the receipt of the PC's initial SETUP packets but our current working hypothesis is that the IN (tx from ARM) side FIFOs are completely frozen. Which is consistent with the fact we don't see any such data on the bus if we use an USB analyser to snoop it.

I think I'm at the point of needing more in-depth knowledge of the USB block, FIFOs, buses etc than the datasheet can provide, and certainly getting a lot deeper than I want to as an application engineer. Is there an ST support engineer here who has in-depth USB knowledge?

Best wishes,

Richard

waclawek.jan · ‎2018-04-09

Posted on April 09, 2018 at 20:35

Richard,

Is there an ST support engineer here who has in-depth USB knowledge?

Probably no, or at least I haven't seen here any in the last few years.

and certainly getting a lot deeper than I want to as an application engineer

You may then want to contact ST directly, and/or resort to the commercial offerings of USB stacks on the STM32.

Jan

richard239955_stm1_st · ‎2018-04-10

Posted on April 10, 2018 at 08:54

Thanks Jan,

Those are good suggestions, I'll give them a go...

Richard