Any plans for HUB support in the USB HOST library to be implemented?

[RhSilicon]

Hi,

I found two implementation examples of USB HOST HID (for keyboard and for mouse) the examples can be merged, and they seem quite stable.

https://os.mbed.com/users/hudakz/code/STM32F407VET6_USBHostKeyboard/

https://os.mbed.com/users/hudakz/code/STM32F407VET6_USBHostMouse/

As can be seen from the link below, the HUB function has been implemented in code and is functional.

https://os.mbed.com/users/hudakz/code/USBHost-STM32F4//file/458bf947f46f/USBHost-STM32F4/USBHost/USBHostHub.cpp/

I tested it with STM32F407VGT6 using the Seeed Arch Max board model, with the DiyMore board. I needed to set the USB_5V and ID pins to a high state for the USB port to recognize the device, as it is not the original hardware of the Seeed Arch Max board.

But unfortunately I found the information that Keil Studio does not support custom board, which makes any Keil Studio code completely useless.

| Unfortunately, custom targets are not supported in KSC

https://community.arm.com/support-forums/f/keil-forum/53968/custom-board-in-keil-studio

I also found the HUB example code, which was implemented in an old version of CubeMX, but I was unable to implement the HUB function using the current version of CubeMX code (STM32CubeIDE):

https://github.com/mori-br/STM32F4HUB

I would like to use the keyboard with touchpad. But for that it is necessary to have HUB support.

https://www.amazon.com/s?k=usb+wireless+keyboard+touchpad

[waclawek.jan]

Read the errata.

https://community.st.com/s/question/0D50X0000BHydBQSQZ/stm32f429-discovery-as-usb-host-problems-enumerating-lowspeed-device-over-fullspeed-hub

JW

[RhSilicon]

Thanks for the tip, this explains an intermittent operation of the port, which when it occurs I force the port to restart, but I still need the HUB.

[waclawek.jan]

This erratum is very specifically related to low-speed devices behind a hub connected through the on-board full-speed PHY. If you have intermittent operations without hub, then it's a bug in your software, not related to this erratum.

There's absolutely no point in developing firmware to support hub since the erratum prevents it from operating properly. While the erratum is formulated as "may hang", it in fact hangs pretty soon, rarely allowing even to enumerate the device behind the hub - see discussion in the linked thread.

Note, that you still may be able to use a hub with the OTG HS module if using an external HS PHY. Also, there are commercial offerings for USB stacks including hub support out there.

JW

[Pavel A.]

Also, newer STM32s may be free of this erratum. For example, H7. (don't know about F7 or L4).