2019-09-03 07:52 AM
Hello everyone,
I'm using the STM32F429 Discovery board as a USB Host. Using the ST Host Library I managed to get several different HID devices working (Full Speed and Low Speed).
I changed the Host Library so that it can handle multiple Devices. I also developed a HUB Class driver which is also working fine. My program is now able to work with an USB Hub, as long as I only connect full-speed devices to the HUB.
Since the Host and the HUB is working in Full-Speed I added the PREamble PID for communication with Low Speed devices. The weird thing is now that the enumeration of Low-Speed devices is only working about 50% of the time. Once the Low-Speed device is enumerated I can recieve as many interrupt inputs as I want without any issues. But the other 50% that I connect the Low-Speed device to my HUB the USB core state machine gets Stuck in the enumeration process.
I found similar topics in this forum that are describing the same problems such as:
https://community.st.com/s/question/0D50X00009XkiNNSAZ/stm32f217-usb-fs-host-mode-hub-problem
I also found a thread where an ST employe mentioned something about a hardware issue in the On chip PHY that might be responsible for this error. But I couldn't find any follow up on this:
as far as I know there is also no errata that describes this problem, yet.
I also found in the User Guide for the emUSB Host stack by segger a mention about this:
https://www.segger.com/downloads/emusb-host/UM10001 (19.3.2.2)
My question now is what is this all about? Is this a know issue? If so is there already an errata about this? If not does anyone know how I could try to work around this issue? And is this problem only occuring on the STMF429 or also on other Chips?
2023-06-11 06:04 AM
Hi,
Thanks for the tip, this may explain an intermittent operation of the port, which when it occurs I force the port to be restarted.
I would like to use the HUB class, where can I find sample code with the modified USB Host core?
2023-06-11 06:57 AM
2023-06-12 12:20 PM
I've been wondering about this, since when does ST know about this issue?
Does this explain why HUB support wasn't added from the beginning?
I chose STM32 for my project because I trusted ST, but now I'm thinking I made a mistake, I should have opted for an NXP MCU.
Now I don't see any other solution than using an adapter, another microcontroller that has a USB Host port, perhaps an RP2040, it's embarrassing, but with the custom board ready it must be the solution.
2023-06-18 10:46 AM - edited 2023-06-18 10:47 AM
Q (Me): "do all products that have internal Full-Speed (FS) USB OTG PHY have the same silicon lithography design on the PHY module? Including the H7 line?
I ask this because I was thinking of making a new PCB board using MCU H743, but if the internal FS USB OTG PHY of H743 is the same as that of F407, then I will try to work around some problem locally"
A (STOne-32 - ST Employee) : "F4 and F7 series are build on 90nm Technology, H7 series are build around ST 40nm e-NVM node with a design-in-house Internal PHY - the H745 rev V is the last revision of silicon and you can refer to our Erratasheet for fixed limitations. You can also explore the H730 series they are cost effective if memory usage of embedded flash is not required"
2023-06-18 11:36 AM
You should've asked, whether the bug described in erratum we are talking about here, applies to the FS PHY in 'H7 too.
JW
2023-06-18 03:54 PM
Can you believe that not even the keyboard was recognized with the project generated by STM32CubeIDE for the STM32H743VIT6? D'OH!
2023-06-19 02:06 AM
> Can you believe that not even the keyboard was recognized with the project generated by STM32CubeIDE
No wonder, this is easy to believe and very likely. CubeMX/IDE "generation" for USB and some other components is still not known to work reliably. But this is not related to the low-speed errata.
Some time ago Segger support told me that H7 USB host mode does not have the low-speed errata, at least not in the same form as for F4, and not with their USB library.
2023-06-21 01:41 PM
Hi, would it be possible to configure the STM32 to operate with a clock outside the ideal frequency to force the occurrence of errors in the packets?
In my gamepad test, apparently there was no error control on the packets, so the data was corrupted.
The post has more details: