I am trying to use platformio with some old Nucleo F401RE boards I have laying around. Compilation and download to device look ok. However there doesn’t seem to be any execution. When debugging I notice that the initialization sequence fails in SystemClock_Config. See debugging output.
Thanks for the feedback. Wondering if regression to an older version is a good approach to keep solving this. I guess it’s part of ST code inherited here. Any idea what is the real root cause ? Saw something similar on the old STM32DUINO forum, where it was related to an incorrect assumption on the quartz crystal frequency.
This doesn’t feel like the right fix at all, the current Arduino-STM32 core (and platform) should just work with such a well-known board.
Can you take a photo of your board, especially regarding the crystall oscillator? My Nucleo F103RB e.g. gets fed its high-speed clock via the “clock in” feature (GND on XTAL2, signal on XTAL1) and the ST-Link chip on the upper side, which sources it from an 8MHz crystal, and has an unpopulated crystal slot marked “X3” otherwise. But it does have a 32.768kHz low-speed / LSE crystal.
Have you made any modifications / changed solder bridges on your Nucleo board that might affect things?
If the Arduino core assumes a X3 crystal of 8MHz to create the HSE_XTAL+PLL config, that’s the fault. I assume it uses the same technique that the clock is actually sourced from the ST-Link and 8MHz crystal above and the STM32F4 chip directly gets the needed clock.
I’ll double check the clock init code of the Arduino core. It needs to do HSE in BYPASS mode (to get a nice high clock speed, or HSI = internal for low-speed but still working).
Okay then that’s good, but the title and text of the first post is still wrong then.
The clock init code is at
And looks “okay”. Depending on whether it’s a ARDUINO_NUCLEO_F401RE or a ARDUINO_NUCLEO_F411RE operates the HSE in BYPASS mode, expecting an input frequency of 8 MHz to then use the PLL with factors / divisors, in the first case, of “/ 8 * 336 / 4” to get 84 MHz. For the F411RE it changes the factors to to / 4 * 100 / 2 to get 100 MHz.
But for that to work the clock needs to get through to the STM32. And that is by default not the case? SB16 is open on maybe older boards, when it should be closed so that the chip gets the clock?
Edit: On my Nucleo F103RB board, the SB16 bridge is closed / jumpered with 0 Ohms.
Yep, while the Arduino core assumes that (apparently on my newer Nucleo base board revision), the SB16 and SB50 are closed so that the 8MHz gets through to the chip and it can then do HSE_BYPASS + PLL.
Then this mystery seems solved: Either do the hardware modification as above, or, adapt the code to source the clock from the internal HSI RC-oscillator and the PLL. The SystemClock_Config() function is WEAK so it can be overwritten in user code / sketch. I’ll shortly post code that implements this code can be found below.
Then with either a hardware or software modification, these (seemingly) older-revision Nucleo F401RE boards should work without problems in the latest STM32 platform and Arduino core.
Maybe also a patch should be proposed in the Arduino-STM32 core that switches it to HSI. Or at least have a note in a Wiki that that might be necessary.