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.

[TDJ]

@ABOUA, @PPAIL.1, @Imen.D Maybe ST could take a look? I hope this is just some HAL bug.
First, to Nucleo-U5A5ZJ-Q I tried to port USB OTG_HS host example available STM32U5G9J-DK2 (only). It should work with no problem since both MCUs seem to use exactly the same USB IP, described in the same RM, but it did not work - OTG_HS_IRQHandler() did not fire.
Of course, I could not test it with STM32U5G9J-DK2 board since this board was not available yet.
Complete repro available here.

[Imen.D]

Hello @TDJ ,

Thank you for rising this up.

I will escalate this request to involved people to take a closer look at the problem.

I'll make sure to post any updates here as soon as I hear back from them.

Thanks

Imen

[ABOUA]

Hello TDJ,

Reviewing the shared code, we highly recommend you to check the provided example for U5A available under this path Firmware\Projects\NUCLEO-U5A5ZJ-Q\Applications\USBX\Ux_Device_CDC_ACM at least to refer to clock configuration where HSE should be used to have an accurate Clock for HS PHY PLL.

And as reference for host start up you could also refer to Firmware\Projects\STM32U5x9J-DK\Applications\USBx\Ux_Host_HID\USBX\App\app_usbx_host.c file

in fact the start of host HAL driver should be called only after linking the HCD HAL driver to USBX middleware in this way

MX_USB_OTG_HS_HCD_Init();

/* Initialize the host controller driver */
ux_host_stack_hcd_register(_ux_system_host_hcd_stm32_name,
_ux_hcd_stm32_initialize, (ULONG)USB_OTG_HS,
(ULONG)&hhcd_USB_OTG_HS);

/* Enable USB Global Interrupt*/
HAL_HCD_Start(&hhcd_USB_OTG_HS);

Regards,

[TDJ]

@ABOUA I have to say that I was skeptical since what I try to accomplish is USB host app, not device, but I gave it another try and for the first time it worked - I was able to save text file on USB-C pendrive using Nucleo-U5A5ZJ-Q. Now I need to understand what made the difference because I have tried porting the original examples more than once following the original code and flow to the letter. Most likely USB clock source is the culprit. Thank you for the encouragement.

[TDJ]

@ABOUA I am showing that USB OTG_HS works as long as HSE 16 MHz or PLL1P with /2 divider is used as a USB clock source. I successfully tested it with PLL1P 32, 40, 48 and 64 MHz frequencies, PLL1P clocked with MSIS 16MHz CRS-SYNCed with LSE 32.768 kHz. It repeatedly and consistently does NOT work with PLL1P without /2 divider - which exactly is the USB clock setup I have tried until now.
Is it a known problem, just not described in the device errata yet or some CubeMX bug?
Is USB OTG_HS particularly sensitive to clock signal condition and /2 divider, probably placed close to the IP within the IC, preconditions it? It may explain why GAHBCFG.GINTMSK register value did not write which, regardless of proper initialization sequence, should not have happened. It is important to understand what happens because I try to avoid using HSE. I use Nucleo-U5A5ZJ-Q just as a common test platform. The actual design is custom.

[ABOUA]

Hello TDJ,

It's good to see that you succeed to get the USB working, please note that USB HS phy PLL takes as input only this range of frequencies, for more details you could refer to RM0456 the section 11.4.19 OTG_HS clock

     Bits 5:2 CLKSEL[3:0]: OTG_HS PHY reference clock frequency selection
0011: 16 MHz
1000: 19.2 MHz
1001: 20 MHz
1010: 24 MHz
1110: 26 MHz
1011: 32 MHz

Regards

[TDJ]

Hello @ABOUA, I am well aware that OTG_HS PHY takes only the listed frequencies. CubeMX shows an error if the effective frequency it is not one of the supported ones and I know that the selected clock frequency needs to be specified again in the IP config property. Probably I should be more specific here.

The problem I try to describe is that my tests repeatedly show that it makes a critical difference whether, for example, PLL1P frequency is set to 64MHz and /2 divider is used or PLL1P frequency is set to 32MHz and /2 divider is not active. In both cases the effective OTG_HS PHY clock frequency is 32Mhz, but in the the first case USB works while in the second case it does not, and symptoms are those I described initially. In another words, /2 divider must always be used.
I think, this may indicate a serious problem.

[TDJ]

@ABOUA Could you confirm the issue I described? It is very important to me because unknowingly I maybe doing something incorrect. I am willing to provide a repro for Nucleo-U5A5ZJ-Q if you, or someone else, is willing to modify the default board jumper which requires soldering. Unfortunately, I am not aware of any STM32U5xx boards with USB-HS  capability which can also provide USB device power out of the box.
CC: @Pierre_Paris 

[TDJ]

The problem has been confirmed by another engineer, details here:
Nucleo U5A5ZJ-Q USBX - Ux_Device_CDC_ACM MX_USB_OTG_HS_PCD_Init() timeout with MSIS · Issue #34 · STMicroelectronics/STM32CubeU5 (github.com)

Complete working solution: tdjastrzebski/Nucleo-U5A5ZJ-USBX: Nucleo-U5A5ZJ-Q (STM32U5A5), USBX, USB-C host, reading and writing pen drive files (MSC) (github.com)

[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).

[waclawek.jan]

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

JW