STM32F429 Discovery as USB Host. Problems enumerating Low-Speed Device over Full-Speed HUB.

[NotSoMega]

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:

https://community.st.com/s/question/0D50X00009XkWqHSAV/usb-host-on-usbif-compliance-program?t=1567511633897

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?

[NotSoMega]

I managed to get my Hands on a beagle 12 USB Protocol Analyser. I was able to catch the Error with this very useful tool:

one picture shows the error after the first Pre PID was send. The other pictures shows the error a bit later after a few successful transfers. But everytime the PRE PID is the last information send by the Host before the Host gets shut down completly. There are no SOF or anything else coming from the Host..

[waclawek.jan]

I came to the same conclusion when attempting this a couple of months ago, also observing the traces on an USB-analyzing-enabled LA.

Btw. I haven't had the liuck you had:

> The weird thing is now that the enumeration of Low-Speed devices is only working about 50% of the time.

I never gotten beyond enumeration with a LS device behind a FS hub. I'd say, this might be timing related, either in hub, in the core, in software handling the core, or everywhere and anywhere.

This is obviously bug deeply in the core of the Synopsys IP. Very unlikely anybody can work around it without Synopsys support, and that won't happen until ST steps in hard.

And in the last years I haven't seen ST eagerly supporting the Synopsys OTP here or elsewhere. So, it's safe to assume this is broken beyond repair and work out of that premise.

I am p***d off as much as you are, believe me.

JW

[Pavel A.]

This is a known issue. Can't figure out how to get a direct link to a message in this <****> forum system, search for "Connecting low speed devices thru a Full speed Hub on our FS OTG Peripheral May not work properly".

Posted by "STOne32" July 21, 2018 

"Connecting low speed devices thru a Full speed Hub on our FS OTG Peripheral May not work properly and we are working on it, potentially to release a workaround or Errata once root-cause is identified. But on HS OTG Peripheral with external ULPI Phy works fine."

Yes, exactly this thread. And yes, Segger docum mentions this. They also suggested that STM32H7 does not have this issue (in private chat) ; I haven't tested.

-- pa

[NotSoMega]

Well Jan, don't ask me why it is working sometimes. Looking at the trace of a successful enumeration shows no difference in timing compared to a failed enumeration:

(I'm connecting a low Speed Mouse over 2 HUBs with the STM32)

Because of the fact that I got it working sometimes I thought it might be a simple timing error. But this trace says a different thing to me.

I also managed to get my successrate up in the 90% area after implementing a routine that resets the hostcontroller everytime there is an PortDisabled Interrupt. This is of course neither good enough nor anyting close to a programming practices I would allow in a finished product.

Pavel thank you for your input. I also saw that thread, I even linked it in my original post. I'm now thinking if I should get an external PHY and try it again, Since I already wasted so much of my time changing the original Host Library for the alleged HUB support. If I wanted to do that, does it have to be a ULPI PHY or is a regular low Speed / Full Speed PHY sufficient? Because for my usecase Low Speed and Full Speed is all I need.

If this issue is know, why is it so hard than to publish an official statement somewhere so that developers like me don't waste their time like this? Maybe just a little note in the HostLibrarys "FAQ" section like: "HUBs are not supported because of the limitations of the Stm32 Hardware." Or a note in the reference manual where the PRE PID generation gets mentioned like: "Well you can generate PRE PIDs, but this will mess with your host controller so good luck.".

Can someone recommand a MCU with a working and reliable USB Host to me maybe?

[CGoeb]

​Hi,

Question is, does the STM32F4 supports UTMI+ Level 3 or just Level 2? We were wondering because sometimes the High Speed hub works fine which should not be when the STM32F4 is only supporting UMI+ Level2. When STM32F4 does not Support the UTMI+ Level 3, which MCU could do this?

Please Notify also Jaroslav Becka!

thanks in advance!

[waclawek.jan]

I've just discovered that there's an erratum out there for the 'F42x/'F43x, since 18.Nov 2021, which says:

Host packet transmission may hang when connecting through a hub to a low-speed device

Description:

When the USB on-the-go full-speed peripheral connects to a low-speed device via a hub,

the transmitter internal state machine may hang. This leads, after a timeout expiry, to a port

disconnect interrupt.

Workaround

None. However, increasing the capacitance on the data lines may reduce the occurrence.

This probably definitively confirms our findings.

@Amel NASRI​ , this erratum for the OTG_HS does not specify, if the problem occurs only when using the built-in FS PHY (which is IMO the case) or also with external ULPI HS PHY. Can this please be clarified. And can please this erratum be propagated to errata for all devices which are affected. Thanks.

JW

[Amel NASRI]

Hi @Community member​ ,

I checked with our expert who confirms that the erratum will be updated as following "Host packet transmission may hang when connecting the full-speed interface through a hub to a low-speed device".

We also agree with you that update should be propagated to several other affected products. Required actions will be taken.

-Amel

[waclawek.jan]

Hi Amel,

With all respect to your work.

I don't like the formulation, what is "full-speed interface", is it the internal FS PHY or external ULPI PHY In FS mode?

What's wrong with calling the internal FS PHY... well... internal FS PHY?

Errata should be unambiguous and should use terminology introduced in DS/RM:

 

 

The naming and description of OTG modules and especially this detail (i.e. presence/usage of internal FS PHY), while fairly well described in 'F4 materials, is very badly treated across other STM32 families (I've complained in the past, but honestly have no energy to look it up nor summarize it again). Please don't make it worse in the Errata.

Thanks.,

Jan

@Amel NASRI​ 

[Amel NASRI]

@Community member​ , my assumption is that we opt for this formulation "full-speed interface" in order to be some how generic across the various families.

I understand from your feedback that this is not the good approach. Thanks for sharing another vision that I'll escalate internally on my side.

-Amel