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

[mansut]

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

 

 

 

 

[AScha.3]

Hi,

>What's wrong with V.1.17.2?

..nothing ?  I would ask : What's wrong with Win ? or the PC /USB port, you running Win ?

Did you try with another Win - Laptop /PC (+ other Win version) to verify the origin of the problem ?

[mansut]

Thanks for your reply.

Yes, we tried with different PCs, both with Windows 10 and 11. Same random problem occurs.

 

[Imen.D]

Hello @mansut ,

Try uninstalling STM32 ST-LINK Utility, then reinstalling it with the device driver.

Maybe you have Windows issues with USB devices that do not occur on other operating systems like Ubuntu.

Check these posts that may help you:

Solved: USB CDC Problems on windows 10 - STMicroelectronics Community

Solved: Possible STM32 USB Virtual Com Port driver bug on ... - STMicroelectronics Community

 

[Ozone]

> Try uninstalling STM32 ST-LINK Utility, then reinstalling it with the device driver.
> Maybe you have Windows issues with USB devices that do not occur on other operating systems like Ubuntu.

As I understand it, the ST-Link is not what the OP talks about, but an USB port driven by his application.
But I suppose he can clarify this point.

And second, he might clarify if we talk about a ST Nucleo board of some kind, or a custom board.

Such information is occasionally crucial.

[Ozone]

> 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

Sounds are generally irrelevent in this context.
Check the complete USB device tree (or better the complete device tree). Often, an "unknown device" shows up, for which Windows cannot assign or install drivers automatically.

Additionally, manually installed drivers are usually assigned to hubs. If a PC/Notebook contains several hubs of different kind (with different kernel drivers), you might need to install the driver a second time.
A good example are USB port on the front and those on the back of a desktop, which are usually connected through different hubs.

And as stated below, please clarify if you talk about a Nucleo board or a custom board here, and if you mean the ST-Link USB or something else (application-driven USB).

[mansut]

Hello, thanks for the reply.

As you already guessed, the USB is driven by our application (running FreeRTOS), and we are using a custom board.

About the Windows device tree, no new element is added after the device with FW 1.17.2 is plugged in. The tree closes and reopens, but I checked every branch and there is no difference at all among the two.

I also checked with usbview.exe, and it doesn't show any difference when i plug in the device.

I also tried FW 1.17.2 adding the lines releated to CDC_SET_LINE_CODING and CDC_GET_LINE_CODING, as suggested by other solutions, but the behaviour does not change.

 

[Ozone]

I'm far from being an expert in USB matters, but it sounds like an ID issue.
Every USB device is supposed to have a proper vendor, product and revicion code number.

> I also checked with usbview.exe, and it doesn't show any difference when i plug in the device.

I'm not sure how that works in Windows...
I prefer Linux, and would use lsusb for that. A command which lists all USB devices found, regardless if they have kernel driver support or not.

[Pavel A.]

Try to connect your device thru a good powered hub.

 

[mansut]

We tried, the problem persists.

[mansut]

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]

# 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.]

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]

Yes, with Linux host it works perfectly.

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