Ux_Host-CDC_ACM : Enumeration failure

LMore.2 · ‎2025-03-20

Dear All,

I am testing the demo project for the NUCLEO-C071 to implement the USB HOST CDC_ACM (USBX). Below are some doubts that arose after the initial tests:

After using the wizard to create the demo project 'Ux_Host-CDC_ACM', opening the .ioc file shows an error in the USBX configuration. In the 'Platform Settings' tab, the pin 'Drive VBUS_FS' is not defined. From what I understand, this should be the pin used by the library to enable the 5V power supply on the USB connector when in HOST mode. However, looking at the electrical schematic of the NUCLEO-C071, there is no pin available for this functionality! To supply 5V to the connector, there is the JP1 jumper (pin 7/8). The only way to avoid the error is to assign an unused pin! Isn't there a smarter way to avoid sacrificing a pin?
After resolving the error, without adding anything to the demo project, and having compiled and downloaded the program onto the NUCLEO board, any device I connect always results in the error "USB Device Enumeration failure." One of the device connected to the NUCLEO definitely implements a USB CDC. When connected to a Windows PC, it is correctly recognized, and I can work with it without issues using Teraterm. It is not a power supply problem; the board draws 200mA, and once connected, it seems to work correctly (LED and configuration via switch). However, it is simply not recognized by the NUCLEO.

Any suggestions?

Thanks.

ABasi.2 · ‎2025-05-08

hello LMore.2

i have the exact same proble with a H5 board

did you find a solution?

best reguards

LMore.2 · ‎2025-05-10

Which of the two issues have you encountered as well? I imagine it's point 2.

After several emails with support, I discovered that some devices recognized as serial (COM) ports in Windows do not actually implement a CDC device but rather other types of USB interfaces. It is the dedicated Windows driver that makes it appear as a COM port.

I used two NUCLEO boards implementing both CDC-type HOST and DEVICE, and everything works perfectly. In my case, the device that I can't get STM32 to recognize is because it implements a USB COMPOSITE interface (Audio, CDC, HID).

What I was told is that, in the case of a COMPOSITE interface, the libraries must implement all the corresponding HOST interfaces for it to work. If this is indeed the case, I find it conceptually incorrect. I would expect that if the HOST only implements CDC and I connect a USB COMPOSITE device, the CDC connection would be established while the other interfaces would be ignored.

I haven't pursued this further because I wouldn't know how to implement a COMPOSITE interface.

ABasi.2 · ‎2025-05-11

hello LMore.2 and thank you for your response!

yes the problem is the point 2,

i'm trying to connect a super classic USB to RS232 device, i think its based on the most common chip used to do a USB to UART device.

in windows i see only a new com port when i plug in the device but when connected to my board (with a stm32H5) have the enumeration issue.

Another firmware where i setup a host MSC works perfectly so i don't think is an hardware issue

did yu know if i can check if the device i have is a real device CDC or is a different type of device?

thank you!

LMore.2 · ‎2025-05-12

In the directory "C:\Program Files (x86)\Windows Kits\8.1\Debuggers", you will find the program "usbview.exe". I don't remember exactly, but I think it is installed with the "Windows SDK". In any case, refer to Microsoft's instructions: "https://community.st.com/t5/stm32-mcus-embedded-software/ux-host-cdc-acm-enumeration-failure/m-p/801086"

From what I’ve seen, devices that use chips for TTL/USB conversion (such as the FTDI232) are recognized by Windows as COM devices because the Windows driver handles this.

ABasi.2 · ‎2025-05-12

thank you LMore.2

yes.it is a FTDI

so you are telling me that its ok that my board don't recognize ad FTDI because isn't a CDC device but another type of device and its windows via a specific driver that made the trick?

thank you!

LMore.2 · ‎2025-05-12

Based on what I understand, that's how it is. If you check with "USBVIEW," you'll see that with FTDI, the USB class and subclass are NOT of the CDC type

ABasi.2 · ‎2025-05-12

Hello

i have tryed usbview and i think you are right:


bInterfaceClass: 0xFF -> Interface Class Unknown to USBView
bInterfaceSubClass: 0xFF

i think this 2 parameters shuld be not 0xFF to Be a CDC device

So i have to make a CDC device myself o find a commercial CDC device to test my board

did you think its possible to enumerate and use a FTDI based device? they are so commonly used that it will be very usefull !

thank you for your kind replies!

best reguards!

LMore.2 · ‎2025-05-12

0xFF is 'vendor-specific'. Check out the Wikipedia link "https://en.wikipedia.org/wiki/USB#Device_classes". Actually, it would be useful to have a HOST implementation example for FTDI. Honestly, I haven't checked if someone else has tackled this issue. Try taking a look on GitHub. If you find something, let me know! ;)

ABasi.2 · ‎2025-05-12

Hello

it seems we are not the first two peaple with this question,

but unfortunetly it seems according to this :

https://community.st.com/t5/stm32-mcus-embedded-software/hi-all-is-it-possible-to-communicate-between-a-stm32f429vgt6-in/m-p/243697

that is mandatory to contact FTDI (it's vendor specific like you already said) and implement by ourself all the necessary firmware.

thank you for your kind messages.

best reguards!