Host process of CDC (Virtual Port Com) does not work.

[JJ4IQV]

I am using STM32G0B1KC to make a CDC class USB Host.

I selected in STM32CubeIDE, Mode=Host_Only (FS) in Connectivity - USB_DRD_FS and Communication Host Class (Virtual Port Com) in Middleware - USB_HOST.

Before creating the user program, I checked the operation with the debugger and found the problem below.

(I did not create a user program, so all code was created by STM32CubeIDE)

1. When the STM32L0 series is connected as a USB device as CDC class, USBH_UserProcess() is notified of the HOST_USER_CLASS_ACTIVE event, but when other CDC devices (e.g. FTDI FT232) are connected, the HOST _USER_CLASS_ACTIVE will not be notified.

 Both CTM32L0 and FT232 will be notified of the HOST_USER_CONNECTION event.

 USB connection is complete on the device (STM32L0) side.

2. After connecting STM32L0 and receiving HOST_USER_CLASS_ACTIVE event, if I disconnect STM32L0 and reconnect it, I cannot receive HOST_USER_CLASS_ACTIVE event.

Do I have to create some user program?

[shorai]

Hi,

Did you get ANY response fron=m ST on this?

Did you find any resolution?

I have tried CP2102 devices as well as a variety of STM nucleo boards and none of them enumerate correctly.

Seems trhey come in as 'Vendor specific' ratehr tahn CDC (class 02) devices

[JJ4IQV]

thank you for your reply.

No one has answered this question yet.

Only one, I got information the USB middleware issue below on Twitter.

Middlewares\ST\STM32_USB_Host_Library\Core\Inc\usbh_def.h

Incorrect: #define USBH_MAX_EP_PACKET_SIZE 0x400U

Correct: #define USBH_MAX_EP_PACKET_SIZE 0x40U

I fixied that bug, but my USB host still doesn't work.

I gave up.

[shorai]

Thanks for coming back to me.

I found a thread on community.st.com going back to 2015 or so. Clive1 replied (thats how far back).

The ST Host drivers are designed to ONLY have one device attached at a time, and definitely are very badly written.

One of the comments was that up to 12 files had to be modified for relatively simple changes.

Even a USB stick cellular modem presents challenges (it comes in as 2 serial ports and a control port) .

The consensus then was "Use embedded Linux on something that can handle it" So I guess PI, ATOM etc are the order of the day for quick fixes. There is an embedded Linux for the F7xx series which I may look at later.

For simpler projects I might get a chance to look at the FTDI and CP2102 driver requirements - they come in as Class = 0xFF (typical Chinese, skip the standard, do something cheaper / simpler ourselves and tie everyone to install our driver) . You then have to look at VID and PID to figure out what device it is and how to operate it.

So much for plug and play. Thats what happens when you write complex specs for simple devices and charge license fees. I couldn't find a single USB-> serial that comes in as that class of device. Even the ST Nucleos do not connect to the ST USB Host in cube.

[AScha.3]

so CDC host from STM is similar to AUDIO host : not useful working.

did someone try the "Azure" host ? seems there are many host types...

https://github.com/azure-rtos/usbx

[shorai]

Hmmm, was getting there, but that looks like the perfect solutoin!

Thank you very much!

[AScha.3]

+ can add in cubeIDE :

[shorai]

Thanks again for rthe pointer to Azure,

The H7xx seem to be the most complete

I'm running 746 and 769 discovery boards, and so need to learn a bit more and can probably adapt the ACM driver with not too much effort.

I think most of the config can be done via the config panels in cube ;-) and a 'class' for each manufacturer of USB to Serial bridge to get round the enumeration step for 'vendor specific' where class does not come in as 2.

Seems insane that the VCP on stlink, CP210x and FTDI all need special handling, even though they all present a single pair of data streams to the app (maybe two pairs if we keep config channel separate). I thought USB was supposed to simplify connection to stream devices?

It says a lot about a protocol when the firmware personalisation offers VID, PID and serial number (? really?!). End of the day I am connecting a device via one or more streams (USBx?) I should not have to hard code VID and PID and read thousands of pages of documentation for a simple stream device such as a USB->UART interface.

Overcomplicated and the base reason for USB being so poorly supported in the embedded device market.

USB has been out for over 30 years and yet still, the first responses I got were "Don't use USB, use UART".