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.

[FBL · Accepted solution]

Hello @TDJ 

To conclude, this is not hardware issue. MSI should not feed USB_OTG_HS clk source. In RM0456 page 487, it is mentioned, MSI provides a very accurate clock source that can be used by the OTG_FS, or the USB, and feeds the PLL.

An internal ticket 172770 is reported to CubeMX to exclude this option in the configuration,

[TDJ]

@FBL  It may be a good idea to update RM0456 and clearly state that MSI is not supported as OTG_HS clk source. True, p. 487 does not mention OTG_HS, but it does not necessarily mean that it is not supported. I think the only relevant requirement stated in RM0456 is 400 ppm accuracy which I think can be fulfilled using MSIS LSE sync-ed.

Anyway, although it is not a good news, thank you for the clarification and confirmation: OTG_HS requires HSE.
As a result, new MCUs equipped with OTG_HS requires HSE - no matter if one actually uses high speed or not.
It is a considerable disadvantage to be aware of, something to be taken into account designing a new hardware.

[FBL]

Hi @TDJ 

We are considering your valuable feedback in order to provide best customer experience. If your question is answered, would you please close this post by selecting Accept as Solution. 

Thanks