USB connection problems with STM32F7

[os81]

Hello,

In one of our products we've moved from a PIC32 to a STM32F7. The product is self powered and has a USB connection (USB-Device Full-Speed, HID). 

Everything works as expected normally. Sometimes however, when I plug in the USB cable, I get an error on Windows "USB device not recognized" and the connection will not work. When this happened once, the USB will not work anymore even if I reconnect the device again. It does also not help when using another USB port on the PC or even connect the device to another PC. The only thing that helps is resetting our device.

I have added some loggings inside the usbd_core.c file. When unplugging the cable, USBD_LL_Suspend will get called once. When Inserting the USB cable, I see multiple USBD_LL_Resume / USBD_LL_Suspend (about 3 each most of the time). When the device is in the "error mode" I get a ton of USBD_LL_Resume when plugging in the cable until the windows message that the device is not recognized appears.

To reproduce this error easily, I've cut a USB extension cable in half and wired all cables through relays so I can connect/disconnect each cable separately. I've created a simple on/off program that switches all the relays at the same time on/off for some time (0.5 - 2s). I can run this program for hours without any issue, USB on our product will always work and I get exactly one USBD_LL_Resume  and one USBD_LL_Suspend each on/off cycle. I've then changed my test device program to randomly connect/disconnect cables before the on/off cycle very fast. When I do this random connect/disconnect for about 10 seconds before the on/off cycle I'll get the connection error after one cycle most of the times. I did the same test with our old PIC32 device and it works without problems.

To ensure that there is no problem with our hardware/software, I took a NUCLEO-F767ZI board and loaded the demo "Ux_Device_HID" (simulates a mouse). When running my test, the same happens here.

[FBL]

Hello @os81 

Could you explain more explicitly the fail? Otherwise, could you share a minimum project to reproduce the issue?

[os81]

The device isn't recognized via USB anymore when it's in this "error mode". In windows, the error "USB device not recognized" pops up every time I try to connect the device to the PC. To solve the problem I have to reset the MCU.

To reproduce, use a NUCLEO-F767ZI and load the example "Ux_Device_HID" from within the STM32CubeIDE. Then build a test device like mine with relays to connect/disconnect the USB lines (5V/GND/D+/D-) in the connecting cable and control the relays like I've mentioned above. I guess there is no easier way to reproduce the problem.

 

Some more infos:

- In our product, we use the STM32 USB device library and no RTOS

- Ux_Device_HID on the NUCLEO board uses ThreadX and USBX, so a completely different USB stack and still has exactly the same problem

- I've also tried some example projects on a STM32F769I-DISCO board and this fault is not present there. The difference: That board uses USB HS, so there is an external USB PHY chip between the USB cable and the STM32F7. That PHY chip apparently does not have that fault. 

[tjaekel]

A bit experienced with USB on several STM MCU, when I read your issue, my impressions:

• The USB enumeration seems to start: windows sees that a new device is connected, but the enumeration process has an issue (e.g. bit errors, incomplete enumeration descriptors, wrong descriptors)
• it tells me also: it seems to work often, sometimes it fails

The main reason is often for me:

• the USB PHY clock is not stable (jitters too much), or the PLL configuration is not really correct:
  the clock frequency for the USB PHY in MCU is not really the nominal one needed to be set
• It results in bit errors on host side: it cannot get the enumeration error free.
• it can be also the cable - use a better, a shorter one.
  For sure: do not manipulate the USB cables, like de-splicing the wires, putting something else like relay contacts in between etc.
  USB needs a very specific impedance (90 Ohms). Any modification or a not properly designed PCB board can cause exactly the issues you see.
• If it is your own board: check the impedance of the USB traces. If it is a NUCLEO board: use a better (shorter) USB cable.

The USB enumeration is very timing sensitive (on the host side): you cannot use breakpoints during the USB enumeration.

Check, if you plug in the USB again - if your MCU is not "too busy": if you do something else, e.g. I2C, SPI, UART on other pins and the USB stack is blocked - it cannot act immediately and with "higher priority" compared to other stuff running in MCU - the USB enumeration can fail as well.

Check, if you do not slow down the MCU core clock so much. Try also to compile and run without debug, with optimization set to higher level (-O2, -O3). Check, if you have ICache enabled... all what makes the instruction processing faster.

USB Enumeration is very delicate in terms of timing.

I guess, it fails randomly because of the timing for USB enumeration, USBV stuff done by MCU, is different (other stuff blocking/interrupting MCU during USB enumeration (or signal issues on cable, clock issue: not really correct frequency needed for USB configured).

If running RTOS - play with priorities. If using INTs - check their priorities: give USB higher prios (in RTOS and for USB INTs).

[os81]

I guess it's still not clear what the actual problem is: Once the device is in error mode, the device will never ever connect to a PC again, no matter how many times I'll reconnect it. If the enumeration fails one time, no problem, but it should work the next time I plug it in, I don't think there is a timing issue every time when the device is in the error mode.

 

I've now made a video to demonstrate the exact problem again:
My setup:
I have an original ST NUCLEO-F767ZI board with the unmodified ST example program "Ux_Device_HID" loaded on it. This does nothing else but simulate a mouse (moves the cursor when pressing the button on the board). The ST board is powered over the red cable with an Apple wall adapter. The USB HID connection is done with the white cable through my "relay device" to the laptop.

Timestamps:
00:00 - 00:24:
The "relay device" connects/disconnects all USB lines at the same time, 5s on, 5s off. I can run this for hours without any problems. The mouse gets detected every time the relays are "on"  -> Even though this setup is far from ideal, it works flawlessly.

00:24 - 00:46:
I've changed the program on the "relay device". Now I've added the 10s random connect/disconnect (you hear the rattling of the relays) before the normal on/off cycle.

00:46:
Windows does not recognize the mouse anymore (even though all relays are "on") and pops up an error message.

00:46 - 01:12:
Reconnecting the mouse does not help

01:12 - 01:23:
After resetting the STM32F7 (power off / power on), the mouse works without issues again

 

 

Please note:

- Our actual device has exactly the same problem. That device has a different hardware and completely different software (even the USB stack is different)

- Our old product with a PIC32 MCU does not have this problem

- The STM32F769I-DISCO also does not have this problem (it uses an external USB HS PHY)

[mansut]

Hello,

I step into this post because we are experiencing a very similar problem, with STM32F7 MCU with Full-Speed USB, when connected to Windows.

https://community.st.com/t5/stm32-mcus-products/stm32f7-usb-problems-on-windows-smt32cube-fw-f7-v-1-17-2-broken/td-p/768692

We tried to fix the problem by migrating STM32Cube Fw from 1.7.0 to 1.7.2, but it got even worse (Windows doesn't recognized the device at all; on the contrary, on Ubuntu it always works fine).

I hope this piece of information can help a bit, with your issue as well as ours.

Thanks

Alessandro