2023-09-28 07:27 AM - edited 2023-11-05 04:40 AM
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.
Solved! Go to Solution.
2024-02-06 06:56 AM
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,
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2023-09-28 12:05 PM - edited 2023-09-29 03:57 AM
@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.
2023-09-29 01:58 AM
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
2023-09-29 06:38 AM
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,
2023-09-29 09:55 AM - edited 2023-09-30 01:33 AM
@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.
2023-09-29 02:04 PM - edited 2023-10-02 09:27 AM
@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.
2023-10-23 01:12 AM
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
2023-10-23 06:34 AM - edited 2023-10-23 07:11 AM
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.
2023-10-31 11:47 AM - edited 2023-10-31 12:01 PM
@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
2024-01-21 01:16 AM - edited 2024-01-21 11:15 PM
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)