STM32F7 - USB problems on Windows - SMT32Cube FW_F7 V.1.17.2 broken?

mansut · ‎2025-02-03

Hello,
we are developing a device with STM32F765VIHx.
We are experiencing a big issue with USB (USB-Device Full-Speed), when connected to a Windows PC.
The USB is configured to be a Virtual ComPort.
Windows sometimes recognizes the device, sometimes the process fails (in device descriptor phase).

We tried several ways to fix the issue (like detecting when the devices goes into USBD_STATE_SUSPENDED mode, de-init and re-initing the USB...sometimes this works, most of the times it doesn't).

Note: the problem never occurs when connected to Ubuntu.

Since we were using SMT32Cube FW_F7 V.1.17.0, we tried to move to V.1.17.2, hoping that might solve the problem.

Alas, after updating the firmware, Windows doesn't recognizes the device at all:
- the PC doens't make any sound at all when the device is plugged in
- the Device Manager tree flashes but nothing new is added

Nota again: The same device, if connected to Ubuntu, is correctly recognized as a /dev/ttyACMx port.

What's wrong with V.1.17.2?

Thanks

Alessandro

mansut · ‎2025-02-04

In Linux there is no problem at all.

The devices are all the same, with the correct VID and PID.

Ozone · ‎2025-02-04

Which would point to Windows as such as the culprit ...

As suggested, I think this is a device ID issue.
For test purposes, could you change your firmware to respond with (cloned) IDs of another, known device which properly works on your PC ? It should at least be recognized.
Or attach a USB protocol monitor, and dissect the whole attachment process.

Aren't there usually officially requested (and payed for) IDs / licenses from the responsible body involved, and "signed drivers" on M$ side ?
As mentioned, I have no experience with USB in this regard.

mansut · ‎2025-02-04

Thanks to everybody for your contribution so far.

I'd like to clarify a couple of things, related to two different problems.

# Problem #1 - ST FW 1.17.0

The devices are currently using the ST FW 1.17.0.

Each single device works by itself, i.e. when connected to Windows 10.

The problem arises when connecting multiple devices to an external hub (powered), and then connecting the hub to the PC: in this scenario (which, unluckily, is our production scenario) often some devices are seen by Windows as "Unknown USB Device".

If, on the other hand, we connect the devices one after the other, the problem does not appear.

Following your advices:

- I removed the Virtual Com Port drivers from ST, so now Windows inbox drivers are used, as stated in the ST's driver page (https://www.st.com/en/development-tools/stsw-stm32102.html)
- I added the management of CDC_SET_LINE_CODING/CDC_GET_LINE_CODING in CDC_Control_FS

This didn't solved the issues.

Here's the typical log that I get from usbview.exe for an "Unknown USB Device":

[Port3] FailedEnumeration : Dispositivo USB sconosciuto (richiesta descrittore dispositivo non riuscita)

Is Port User Connectable: yes
Is Port Debug Capable: no
Companion Port Number: 3
Companion Hub Symbolic Link Name: USB#VID_05E3&PID_0612#6&d0ca138&1&1#{f18a0e88-c30c-11d0-8815-00a0c906bed8}
Protocols Supported:
USB 1.1: yes
USB 2.0: yes
USB 3.0: no

---===>Device Information<===---
String Descriptor for index 2 not available while device is in low power state.

ConnectionStatus: FailedEnumeration
Current Config Value: 0x00 -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
Device Address: 0x22
Open Pipes: 0
*!*ERROR: No open pipes!

===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0201
bDeviceClass: 0x02
*!*ERROR: Device enumeration failure

mansut · ‎2025-02-04

# Problem #2 - ST FW v.1.17.2
Given the same project as before, and just migrating the ST Firmware toolchain from 1.17.0 to 1.17.2 (i.e.: selecting "Migrate" from CubeMX and re-generating the code), and doing nothing more than that, each device (althoug connected alone) in not seen, in any way, by Windows (i.e.: it doesn't appear anywhere in the Device Manager tree).
On the other hand, the very same device is seen under Linux.
I tried to debug the code, printing the transition of the states of hUsbDeviceFS.dev_state.

Under Linux:

USBD_STATE_DEFAULT ---> USBD_STATE_SUSPENDED
USBD_STATE_SUSPENDED ---> USBD_STATE_DEFAULT
USBD_STATE_DEFAULT ---> USBD_STATE_ADDRESSED
USBD_STATE_ADDRESSED ---> USBD_STATE_CONFIGURED
It works.

Under Windows:

USBD_STATE_DEFAULT ---> USBD_STATE_SUSPENDED
USBD_STATE_SUSPENDED ---> USBD_STATE_DEFAULT
USBD_STATE_DEFAULT ---> USBD_STATE_ADDRESSED
(about 5/10 seconds ... )
USBD_STATE_ADDRESSED --> USBD_STATE_SUSPENDED

Under Windows, at some point the SuspedCallback is called, I guess due to some time-out, but I have no clue why this is happening and how to investigate the problem.

As stated before, the code is just the same as when using fw. 1.17.0

Thanks for any help or hint.

Pavel A. · ‎2025-02-05

So does your firmware work well (not just recognized) with Linux host?

Try to disable USB power saving on the Windows machine. If this will solve the problem, fix the device suspend & resume functionality in your firmware.

mansut · ‎2025-02-05

Yes, with Linux host it works perfectly.

I disabled USB power saving on Windows; nonetheless, the device is not detected, in any way. :\