Why OTG_HS USB/USBX Host on STM32U5Axx just does not work? (2)

[TDJ]

I encountered a problem while desperately trying to make USB OTG_HS Host configured on a new Nucleo-U5A5ZJ-Q using CubeMX and ThreadX+USBX. I know that this board is not designed to provide USB power, but this can be overcome with undocumented SB8-10 jumpers and UCPD is not an issue here. I am also aware that at the beginning of the HAL_HCD_MspInit() function __HAL_RCC_SYSCFG_CLK_ENABLE(); line needs to be added.

After several evenings of research (see here) I think I nailed down the problem to USB_HostInit() function.
At the end of this function, host mode events are enabled using GINTMSK register (RM0456, section 73.14.8 OTG interrupt mask register [alternate] (OTG_GINTMSK), offset 0x18).

USBx->GINTMSK |= (USB_OTG_GINTMSK_PRTIM            | USB_OTG_GINTMSK_HCIM | \
                  USB_OTG_GINTMSK_SOFM             | USB_OTG_GINTSTS_DISCINT | \
                  USB_OTG_GINTMSK_PXFRM_IISOOXFRM  | USB_OTG_GINTMSK_WUIM);

The problem I found and cannot explain is that after when this line is executed, GINTMSK register value is still zero. Other OTG_HS registers get correctly set so probably the problem is NOT caused by misconfigured or not enabled RCC AHB2 peripheral clock (RM0456, 11.8.30 RCC AHB2 peripheral clock enable register 1, bits 14 & 15 - OTGEN & OTGHSPHYEN flags).

Please advise, I start to suspect some hardware bug or incorrect GINTMSK register offset.

Probably a separate issue is that GAHBCFG.GINTMSK register flag is not set (Global interrupt mask, RM0456, 73.14.3).

The second screenshot presents OTG_HS-related registers' state after when MX_USB_OTG_HS_HCD_Init() function was finished and HAL_HCD_Start() function was called.

[waclawek.jan]

What is the content of relevant RCC registers for the working vs. non-working case?

JW

[TDJ]

Hi @waclawek.jan, The problem is solved. It appears to be strictly related to IP clock source and has been confirmed by another engineer here. Since more engineers seem to be struggling with USB-C on U5, I posted my complete, working and documented solution on GitHub (Nucleo-U5A5ZJ-USBX).

[FBL]

Hello @TDJ 

IP clock source selected is not compliant with 400ppm. Since, the source for PLL1P clocked with MSIS.

According to the datasheet, MSI output characteristics are stated as follows.

According to the reference manual, section 11.4.19 OTG_HS clock, MSI is not suitable for this USB OTG HS use case.

I hope this helps!

[TDJ]

@FBL,
1. The problem I reported here is this:
"The problem I found and cannot explain is that after when this line [see here] is executed, GINTMSK register value is still zero. Other OTG_HS registers get correctly set so probably the problem is NOT caused by misconfigured or not enabled RCC AHB2 peripheral clock [..]."
Do you believe that the described problem may be caused by insufficient IP clock source accuracy?

2. Is the accuracy of MSIS clock CRS SYNC-ed with LSE using 20ppm crystal sufficient to be used as OTG_HS USB IP clock source?

[FBL]

1. There is an issue linked to description of register interface in SVD file related to stm32u5a9xx.h USB_OTG mess · Issue #31 · STMicroelectronics/STM32CubeU5 (github.com)An internal ticket 170738 is submitted for an update.

2. In USB standards, input clk of USB should be 500ppm compliant. I'm afraid to tell you the answer is no.

[TDJ]

@FBL I believe STM32CubeU5 Issue #31 has nothing to do with SVD register description. If it did, I would know it since it was me who submitted this issue.
What is the accuracy of MSIS clock CRS SYNC-ed with LSE using 20ppm crystal? How far insufficient is it for the purpose of USB clock?

[FBL]

Hello @TDJ 

Thank you for your inputs. Indeed, it is true the issue is more linked to CMSIS definitions but I thought you see them in debug as I did a consequence SVD files are not inline with RM0456. 

The accuracy of the MSIS clock CRS SYNC-ed with LSE using a 20ppm crystal in the STM32U5 series is not explicitly stated in the available resources. I guess it would result in a clock accuracy more than +/- 20 ppm from LSE's nominal frequency as LSE can be influenced by several factors including temperature, voltage, and the quality of the crystal. Also, VCO frequency is proportional to the voltage at the input. For further information check AN2867 section 4.2 How to select an STM32-compatible crystal.

Thank you for your feedback.

[tjaekel]

Hi TDJ,

also working on a NUCLEO-5A5 board (and my own PCB with this chip), my five cents:

• I think, the NUCLKEO-U5A5 board has a UCPD chip on board: as I understand, it should be also able to provide the VBUS power when acting as a host - but you must control the power enable as a host
• the USB (as HS, with integrated PHY) seems to be very sensitive for the right clock generation (e.g. just HSE, not internal HSI), and the PLL configuration seems to be very "sensitive":
  I got my USB device working, but it ended up in using the right PLL-config in System_ClockConfig().
  If device works - actually than also USB host should work (if you enable the VBUS power

Another important reminder is:

I have started with STM32U575. When this was working - I tried to port project over for a STMU5A5:

But, even both chips are pretty similar - they differ a lot on USB!
U575 has just an (integrated) USB FS, but the U5A5 has an integrated HS PHY: on a U575 you have to configure the USB DP and DM pins (PA11, PA12) via ALT as such one.
On a U5A5 - with integrated HS PHY - there is nothing to do on PA11, PA12: the pins are "automatically" used as DM, DP, when you configure USB stack properly as HS.

(very tricky difference, esp., when you "reuse" an existing project)

And bear in mind: a U5A5 works only with an external OSC (or XTA), with a dedicated precision (100 ppm stability).
And for me, the SystemClock config was the main issue (just selecting a different set of PLL config values, even resulting in the same PLL output frequencies - FAILED, e.g. my impression: PLL_M should remain 1, even you can find same PLL clock frequencies with PLL_M  = 2).

[TDJ]

@tjaekel Thank you for sharing your observations. For the main part my problem appears to be solved, I posted working code here. All now I try to accomplish is to find out why it was not working.
I believe MSIS clock CRS SYNC-ed with LSE using 20ppm crystal is stable enough to be used for USB. I actually measured it and confirmed.

My numerous tests indicate that PLL1P USB clock source must be used with /2 divider.

The problem with such bold claim is that, I admit, it sound unbelievable so those who kindly try to help you first assume that most likely you do not know what you are doing. As a result, this thread is quite long. However, at least one person seems to experience the same issue and confirms the same solution - see STM32CubeU5 issue #34. "Working only with PLL1P/2. With PLL1P still facing timeout issue"

As far as UCPD; Nucleo-U5A5 uses TCPP01-M12 chip designed only to receive power (sink), not to provide it.
I believe NDK 32kHz NX1610 crystal used on this board has sufficient 20ppm accuracy. See NDK specs here.

[FBL]

Hello @TDJ 

I am trying to reproduce the behavior on myside as you described, and I will come back to you ASAP as this potential issue should be linked to product not the IP controller. 

Thank you for your understanding.