STM32H745 USB_OTG intermittently fails to respond to Core reset

[R.Keelan]

I have an application running on an STM32H745 MCU on a custom board. I'm initializing both USB ports (FS and HS) but I'm not using a HS PHY, I'm using both ports as FS.

I have an intermittent issue where either or both ports fail to initialize because the USB_CoreReset() function call times out waiting for GRSTCTL.CRST to clear.

I've seen that there have already been a couple of similar questions posted. In both cases, the issue turned out to be a misconfigured clock.

In this case (https://community.st.com/s/question/0D50X00009yH4Yc/stm32h743-usbotgfs-not-responding-to-core-reset?t=1627568262222) the issue was that the ULPI clock was being enabled when it shouldn't be. I've confirmed that I'm not enabling the ULPI clock.

In this case (https://electronics.stackexchange.com/questions/224174/stm32-usb-host-will-not-return-from-reset-request), the external oscillator was not functioning. I've confirmed that my external oscillator is producing the frequency that I expect.

I've modified both my code and the STM32H7 Eval Board CDC example to make the boot up code as similar as possible, but I don't see the same issue on the Eval Board.

One the one hand, this suggests a hardware issue. On the other hand, this initialization seems pretty strictly confined to the MCU itself. Other than the external oscillator, I'm at a loss as to how the hardware might matter.

Any ideas for things to check are appreciated.

Thanks,

Richard

[R.Keelan]

The issue I was facing was the time between selecting the Full-Speed Embedded PHY and attempting the core reset.

1. In my case, I'm not using an external PHY, so inside the function HAL USB_CoreInit(), I go into the else branch
2. After selecting the embedded PHY ("USBx->GUSBCFG |= USB_OTG_GUSBCFG_PHYSEL"), the line of code is calling USB_CoreReset()
3. One thing I noticed, but didn't put in my original description, was that disabling optimizations on USB_CoreReset() prevented the issue. On High Optimization, this function is in-lined, and there's just a handful of instructions before the soft core reset.
4. The STM32H7 Eval Board CDC uses a system clock frequency of 400 MHz (480 MHz is the maximum)
5. With High Optimizations, and the maximum system clock frequency, code execution is just fast enough that sometimes, you attempt to do the soft core reset before (I guess) the embedded PHY select has taken effect. But if you relax either condition (change the optimizations are reduced the system clock frequency), the issue does not occur.

My solution was to add a do-while loop that makes sure USB_OTG_GUSBCFG_PHYSEL is set before proceeding. I have no particular reason to believe that the bit being set indicates that whatever changes need to happen have propagated through the system, but it does seem to add enough of a delay to fix my issue.

[waclawek.jan]

Hi Richard,

Thanks for coming back with the solution. This is an interesting piece of information.

@Amel NASRI​ , can ST please comment on this?

JW