Nucleo U5A5ZJ-Q USBX - Ux_Device_CDC_ACM MX_USB_OTG_HS_PCD_Init() timeout with MSIS

[darshanmirajkar-eaton]

Trying to run STM32CubeU5\Projects\NUCLEO-U5A5ZJ-Q\Applications\USBX\Ux_Device_CDC_ACM of main branch with HSI facing the issue of MX_USB_OTG_HS_PCD_Init() timeout with MSIS

• Nucleo U5A5ZJ-Q
• IDE version 1.13.2

MX_USB_OTG_HS_PCD_Init() timeout in USB_CoreReset.

Steps to reproduce

1. Open IOC. Disable HSE

2. Set the clock as shown in image

3. While initializing MX_USB_OTG_HS_PCD_Init() timeout can be observed while debugging

Can someone help to identify issue and resolve this.

[ALABSTM]

Hi @darshanmirajkar-eaton,

From what I understood of the modification you brought to the project is that your system will start being clocked by the MSI clock just after the reset.

In the screenshots you shared, the PLL1P clock, derived from the MSI clock, is indicated to be oscillating at 20MHz. However, according to page 486 of the RM0456 Rev.4 "After restart from reset or when exiting Shutdown mode, MSIS and MSIK frequencies are set to their default value 4 MHz".

Could this explain the timeout you are experiencing? Could it be that you should leave the HSE clock enabled after a reset and switch to the MSI clock only after ensuring this latter is oscillating at the desired frequency, i.e., 20MHz after it has been configured to? Please keep me informed.

With regards,

[darshanmirajkar-eaton]

@ALABSTM I tried HSE enabled after reset and switch to MSI. This case I am not experiencing time out. But in our case, we are not using HSE. USB should work with MSI also, right??

[darshanmirajkar-eaton]

@ALABSTM I further investigated. I Tried this OTG HS Clock Mux with HSE is working. OTG HS Clock Mux with PLL1P leads to MX_USB_OTG_HS_PCD_Init() timeout in USB_CoreReset.

[ALABSTM]

Hi @darshanmirajkar-eaton,

From what I see from your last test, although your USB OTG HS clock is fed by the HSE clock, your PLL1P is still fed by the MSIS. Hence, the same issue and the timeout.

According to our development teams, the recommendation is to use the HSE clock for the USB OTG HS. An alternative is the HSE clock bypass mode using an external clock source. This would allow you to use only the OSC_IN pin and spare the OSC_OUT. You can refer to the reference manual for more details.

I am not sure whether the HSI clock would be any of a solution. However, our development teams strongly discourage such option. I hope this helps.

With regards,

[darshanmirajkar-eaton]

@ALABSTM USB OTG is working with HSE. Is there any specific reason not to use PLL1P?

And another observation is with PLL1P/2 at least I am not observing timeout, but USB is not working.

[tdjastrzebski]

@darshanmirajkar-eaton Check out this post Why OTG_HS USB/USBX Host on STM32U5Axx just does not work? (2) It seems that indeed there is some hardware USB bug that ST staff is not allowed to admit (no offence, I do understand). Also, you may find some very relevant info in this thread: https://github.com/STMicroelectronics/STM32CubeU5/issues/30

[tdjastrzebski]

@darshanmirajkar-eaton Note that MSIS clock may not be correctly CRS-synced with LSE unless RTC is enabled as well. There was a bug in CubeMX I reported here. It seems it is corrected in the latest release 6.10.

[darshanmirajkar-eaton]

@tdjastrzebski we able to initialize using MSIS with below clock settings
Working only with PLL1P/2. With PLL1P still facing timeout issue

[tdjastrzebski]

@darshanmirajkar-eaton Thank you for the confirmation, it is consistent with my observations: HSE or "/2" must be used. Otherwise, internal register values may not be stored and all sorts of things can happen.

[riscy00]

I have the same USB core reset issue with the STM32U5A5ZJTXQ Nucleo board with V140 CubeMX (CubeIDE is V141, just updated). I generated the code from the start via CubeMX on CDC_ACM (Device) and then copied the code from the demo code CDC-ACM from the example folder. I use HSE of 16MHz that feeds to the USB_PHY device. I get CSRST not clearing itself. After reading this comment here, I'm unsure what needs to be done to fix this; thanks. The older demo code (dated 2021) CDC_ACM is working fine but I cannot use this version.

[riscy00]

I have tried MSIS, HSE and RTC (LSE) setting variants as described above and found not working with CSRTS self clearing and time out. I'm open for idea what to do next?

[tdjastrzebski]

There are two problems:

1. For the IP clock HSE or PLL1P with /2 divider and 2x higher frequency has to be used. PLL1P without divider does not work. Why? I have not clue, but it seems like it is a hardware bug ST is not ready to confirm yet, probably until they have a solution - that is, a new version. See this post Why OTG_HS USB/USBX Host on STM32U5Axx just does not work? (2)
2. CRS SYNC did not work (was not really enabled), unless RTC was enabled as well. I have reported this CubeMX bug to ST, it has been fixed in the latest release 6.10. See this post CRS SYNC setup with LSE and CubeMX puzzle

Complete working solution I put together is available here: https://github.com/tdjastrzebski/Nucleo-U5A5ZJ-USBX

[riscy00]

I tried https://github.com/tdjastrzebski/Nucleo-U5A5ZJ-USBX yesterday, and there is no CSRST issue (via Cube/MX 1.3.x), but it is set up as a USB Host. I am on USB Device under CDC_ACM under 1.4.0/1.4.1 CubeMX/IDE install. Does anyone have a working USB / USBX device (regardless of whether this is CDC_ACM or variants)? I do not wish to use the demo version supplied by STM since it was written in 2021, and I do not want to downgrade to an older version of Cube IDE/MX in case of other bugs in Azure stuff and library.

[riscy00]

I have placed the code __HAL_RCC_SYSCFG_CLK_ENABLE(), as shown below, and the CSRST issue went away, but I do not see the COM port on my laptop. It seems the config clock was left disabled before configuring. I review it later in the week and maybe make a fresh Device CDC_ACM project from Cube IDE/MX V140/V141. I have applied PLL1P/2 and RTC enabled.

void HAL_HCD_MspInit(HCD_HandleTypeDef* hhcd)

{

  RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};

  if(hhcd->Instance==USB_OTG_HS)

  {

  / USER CODE BEGIN USB_OTG_HS_MspInit 0 /

  __HAL_RCC_SYSCFG_CLK_ENABLE();

  / USER CODE END USB_OTG_HS_MspInit 0 /

From Palm LLM: The HAL_RCC_SYSCFG_CLK_ENABLE() function enables the clock for the System Configuration Controller (SYSCFG) in STM32U5 microcontrollers. The SYSCFG peripheral is responsible for configuring and managing various system-level features such as power management, clock control, and interrupt handling. By enabling the SYSCFG clock, you can access and control these features through the HAL library functions.

[darshanmirajkar-eaton]

Can you share the clock settings @riscy00

[riscy00]

046_STMU5A5_AzureUSBX.txt Rename the postfix to ioc. This contains the clock setting. The USPD is not generating interrupts to start the USB so it remains disconnected from USB bus. I think there bug in USPD or incomplete code on V140/V141 library. The missing source code that process CAD which make it hard to figure out just cause. Can you supply USBPD_CAD_Process() source code?

[ALABSTM]

Hi everyone,

Thank you for this instructive exchange. Glad to read you found a solution.

As this is not related to the software published within this repository, but rather to hardware aspects, please allow me to close this thread. Nevertheless, you can continue using it to exchange further about this topic. Thank you for your comprehension.

With regards,

[tdjastrzebski]

@ALABSTM, @riscy00 Indeed, so far everything suggests it is a hardware issue. I believe ST is in the process of analyzing it.

[ALABSTM]

Hi everyone,

Further details from the reference manual RM0456 Rev.5, page 487, paragraph 11.4.3 MSI (MSIS and MSIK) clocks:

The MSI advantage is to provide a low-cost (no external components) low-power clock source. In addition, when used in PLL-mode with the LSE, the MSI provides a very accurate clock source that can be used by the OTG_FS, or the USB, and feeds the PLL.

As you can see, the OTG HS is not mentioned, implying the MSI clock is not adapted as clock source.

On the other hand, page 497, paragraph 11.4.19 OTG_HS clock:

The OTG_HS kernel clock is generated by the OTG_HS PHY. This PHY can accept only frequencies of following list (16, 19.2, 20, 24, 26 or 32 MHz), with an accuracy of ± 400 ppm. Those frequencies can be achieved using either HSE, HSE/2, PLL1_P or PLL1_P/2, and selected by the OTGHSSEL[1:0] multiplexer.

For the sake of precision, please note that the PLL1 P, if used in this case, shall be clocked by the HSE clock.

Thank you all again.

[tdjastrzebski]

@ALABSTM One comment: RM0456 p. 487 mentions OTG_FS, but not OTG_HS. Maybe it applies to OTG_HS as well, but maybe not. It does not say.

[riscy00]

I wish to note the earlier demo code for STM32U5 USB-Device CDC-ACM believed to be written under V130 is working fine but V140/V141 generated by CubeMX (based on MOOC and variants) and copied the selected code from V130 into V140/V141 does not work, I fixed the clock init issue by enabling the clock into config however the interrupt is not working to start the USB and unable to debug due to missing source code (CAD process). NB: I would like to use HS not FS. I am looking forward to the ST investigation on hardware issue (any details?) and waiting for them to have a working CDC-ACM code based on V140/V141 via Azure USBX so I can move on.

[ALABSTM]

@tdjastrzebski,

Thank you for your comment. I updated mine above. To conclude:

• There is no hardware bug.
• The OTG HS, to be correctly used, needs the HSE clock as clock source or the PLL1 P clocked by the HSE clock.

Other sources, like the MSI clock shall not be used with the OTG HS.

With regards,

[tdjastrzebski]

@ALABSTM I think it may be a good idea to update RM0456. The only OTG_HS clock requirement mention is 400 ppm accuracy, which, according to the actual measurements I did, can be fulfilled using LSE sync-ed MSIS clock. However, I understand that it is more than that and even LSE sync-ed MSIS clock is not good enough to be used for OTG_HS. Needless to say, It is not a good news because that means that new MCUs equipped with OTG_HS require 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.