Nucleo F401RE fails to execute Clock init issue

PlatformIO Core
1

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.

Screenshot_20201230_142334
Screenshot_20201230_1423341204×896 163 KB

This looks related : ST Community

2

What’s your platformio.ini?

Possibly related report on another F4 board: Target Halted Due to debug-request - #8 by fek9

3

Hereby the ini file

[env:nucleo_f401re]
platform = ststm32
board = nucleo_f401re
framework = arduino
4

Changing this line :
platform = ststm32@6.0
Also worked for me, after clean build.

5

Hi Vortex314 you beat to a reply… :slight_smile:

Had the same issue with my old Nucleo F401RE, here’s my platformio.ini entry
platform = ststm32@6.1.1…

Version 7.0 and up to current the same error…

6

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.

7

BTW : Nice to see this community is really alive !

8

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?

9

Hereby the picture.

IMG_20201230_154216
IMG_20201230_1542161000×1333 259 KB

It doesn’t indeed have an X3 crystal. I didn’t do any change to solder bridges;

10

Hi maxgerhardt, the board is pretty much stock. I did up date the ST-Link firmware to lastest…

Version: V2J37M26
Build:   May 13 2020 17:07:43

WhatsApp Image 2020-12-30 at 16.43.10
WhatsApp Image 2020-12-30 at 16.43.101200×1600 224 KB

11

Okay and that board doesn’t have an X2 LSE, too.

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).

12

Hold up. Why select an F401RE when you have a F411RE? Needs this one doesn’t it ST Nucleo F411RE — PlatformIO latest documentation

13

Max I agre that the 8 Mhz clock should pass via the ST-link chip, according to the doc it should work like that.

MCO
MCO772×402 72 KB

SB16 should be closed, but by inspection of the board I see that it is open. Going to try.

14

Both pictures above are of Nucleo F401RE…

15

Oops, my mistake : bad title

16

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.

1609341008738
16093410087381200×1600 483 KB

17

Ok, guys , I think I cracked it.
Also soldering bridge 50 is missing. After putting this also together with SB16, it works with the most recent version.
MCO2
Looks these boards were manufactured with the idea that an X3 crystal would be present.

2 Likes
18

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.

1 Like
19

Looks we are not the first one looking for this mystery.
https://forum.micropython.org/viewtopic.php?t=1384

20

Tomorrow at the office I’ll have a look at my SB50, then bridge it if need. Will let U guys know the outcome… :slight_smile:

1 Like