[stm32] Wait until the PHYC PLL is stable

[salkinium]

Describe the PR

Thank you for this awesome project, very enjoyable to work with!

I've been integrating TinyUSB using custom firmware on the STM32F723E-DISCOVERY board and got stuck in reset_core when initializing the HS port. Waiting 2ms after PLL enablement fixes this issue.

Additional context

The solution for this was already discovered in #2074 (comment), where the CubeHAL waits 2ms, since there's no USB_HS_PHYC_PLLRDY bit in the USB_HS_PHYC peripheral

Closes #2074.

[hathach]

can you provide the RM/specs that specify how long we should wait ?

[salkinium]

Unfortunately no, the RM0431 p1560 does not mention anything about PLL stability.

The CubeHAL code is here though

[hathach]

#2074 is tested with h747, which I don't think have USB_HS_PHYC as F723, therefore it is probably another issue. I also have the F723 discovery and has no issue with stocked examples. Can you make an minimal changes to oone of stock example that coould cause the issue ?

[HiFiPhile]

👀
Me too I didn't have this issue on STM32F723E-DISCOVERY, with both IAR 8.3 and GCC 12.3 compilers.

[salkinium]

Ah, well… at first I also couldn't reproduce this issue with the tinyusb examples, until I power cycled the board:

cd tinyusb
python3 tools/get_deps.py stm32f7
cd examples/device/cdc_msc
rm -rf _build; \
    make BOARD=stm32f723disco RHPORT_DEVICE=1 LOG=2 all && \
    openocd -f board/stm32f7discovery.cfg -c "program _build/stm32f723disco/cdc_msc.elf verify reset exit"

*power cycle board*

picocom --imap lfcrlf -b 115200 /dev/tty.usbmodem103

*reset board*

USBD init on controller 1, speed = Full
sizeof(usbd_device_t) = 56
sizeof(dcd_event_t) = 12
sizeof(tu_fifo_t) = 12
sizeof(tu_edpt_stream_t) = 20
CDC init
MSC init
guid, gsnpsid, ghwcfg1, ghwcfg2, ghwcfg3, ghwcfg4
0x00003100, 0x4F54330A, 0x00000000, 0x229FE1D0, 0x03EED2E8, 0x23F00030
Highspeed UTMI+ PHY init
<----- gets stuck here in reset_core

If you then apply my patch, it progresses past the reset.
If you then undo my patch it also progresses past this step until a power cycle.

So something related to the PLL in the DWC2 core is sticky? Or it's an issue with GCC 14:

 $ arm-none-eabi-gcc --version
arm-none-eabi-gcc (Arm GNU Toolchain 14.2.Rel1 (Build arm-14.52)) 14.2.1 20241119

EDIT: Nope, I tried this exact procedure with GCC12 and GCC13 and the behavior does not change.
EDIT2: Here is the failing ELF file compiled with GCC14, and here is the ELF file with my patch.

[HiFiPhile]

I still can't reproduce the issue with your binary.

UART is connected from jumper CN6 to allow full power-off, no matter power cycle (cable unplug&re-plug) or press reset button it always runs correctly.

I'm wondering if it's related to chip/board revision, I have:

• MCU Rev A; PHL 7B 724
• Board MB1260-F723E-D03

[HiFiPhile]

@Lurcy38 Hi, do you know anything about this ?

[salkinium]

Hm, I have the exact same board and MCU revison as you…
Well maybe just leave it open then in case others have the same issue, I'm using a patched TinyUSB version anyways.