Fix STM32 crashes on boot due to unset VTOR

[c1728p9]

Remove HAL_Init and related code from SystemInit and move it to mbed_sdk_init. The function SystemInit is called early in the boot sequence before RAM is initialized or the VTOR is setup, so it should not be used to perform the HAL initialization.

This fixes crashes due the vector table being used before it has been relocated.

[c1728p9]

/morph test

[bscott-zebra]

I think this SystemCoreClockUpdate() call (and associated comment) can be removed since this call is now being added at the end of this function, after setting up the clocks (same comment applies to all changed mbed_overrides.c files).

[c1728p9]

Hi @monkiineko, does HAL_Init need the clock speeds to be set before it is called? Just want to double check before I go through and remove this.

[bscott-zebra]

@c1728p9 I've now spent some time investigating everything being done in the STM32 HAL_Init() and clock setting functions, and while I think it's a little wasteful doing the clock detection twice, the HAL RCC clock setting functions actually make use of the HAL tick timer for checking timeouts when starting oscillators and such, so it is safer to keep the extra SystemCoreClockUpdate() call as you have it to ensure these clock setup timeouts are of the proper duration. So, from my point of view, your code is okay as is.

[0xc0170]

@monkiineko Thanks for the review

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 545

All builds and test passed!

[0xc0170]

cc @adustm @bcostm @LMESTM @jeromecoutant Please review. This should work for mbed 2 and mbed 5.

I'll run some mbed 2/5 tests to be sure this is now corrected.

[LMESTM]

@c1728p9 @monkiineko Thanks for the PR.
Few months ago, we've been through the init sequences of MBED in all supported Toolchain and have come to the conclusion that HAL_Init was needed in SystemInit because we needed it before the clock settings but also before the C++ objects creation.

There is now a nice sequence description of boot calls in mbed_boot.c here (https://github.com/ARMmbed/mbed-os/blob/master/rtos/mbed_boot.c#L43) and I have 2 questions:

• when are C++ objects creators being called in those sequences ?
• can we get a similar sequence description when no RTOS is being used ?

[RobMeades]

Confirmed that this resolves the problem I raised in #4532.

[0xc0170]

can we get a similar sequence description when no RTOS is being used ?

Issue created #4550

when are C++ objects creators being called in those sequences ?

ARM: __rt_lib_init
GCC_ARM: __libc_init_array
IAR: __iar_dynamic_initialization

All of these are invoked from pre_main, after mbed_sdk_init

Confirmed that this resolves the problem I raised in #4532.

Thanks for testing

[jeromecoutant]

Hi
Quick test:
| OK | NUCLEO_F411RE[F269] | GCC_ARM | MBED_2 | stdio | 0.74 | 20 | 1/1 |
| OK | NUCLEO_L073RZ[F35F] | GCC_ARM | MBED_2 | stdio | 0.74 | 20 | 1/1 |
| TIMEOUT | NUCLEO_L476RG[F353] | GCC_ARM | MBED_2 | stdio | 60.26 | 30 | 0/1 |
| OK | NUCLEO_F746ZG[F929] | GCC_ARM | MBED_2 | stdio | 0.82 | 20 | 1/1 |
| OK | NUCLEO_F042K6[E197] | GCC_ARM | MBED_2 | stdio | 0.78 | 20 | 1/1 |
| OK | NUCLEO_F302R8[F009] | GCC_ARM | MBED_2 | stdio | 0.8 | 20 | 1/1 |

[0xc0170]

| TIMEOUT | NUCLEO_L476RG[F353] | GCC_ARM | MBED_2 | stdio | 60.26 | 30 | 0/1 |

Interested in this one, handler or what is the failure?

[LMESTM]

I'm trying to debug ....

#0  WWDG_IRQHandler ()
    at C:\Data\Workspace\mbed\targets\TARGET_STM\TARGET_STM32L4\TARGET_STM32L476xG\device\TOOLCHAIN_GCC_ARM\startup_stm32l476xx.S:121
#1  signal handler called
#2  LoopCopyDataInit ()
    at C:\Data\Workspace\mbed\targets\TARGET_STM\TARGET_STM32L4\TARGET_STM32L476xG\device\TOOLCHAIN_GCC_ARM\startup_stm32l476xx.S:90
#3  0xffffffff in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

it looks like I don't even reach SystemInit ... and I don't understand why (yet) :-(

[jeromecoutant]

Last STM32 family quick test:
| OK | NUCLEO_F103RB[0527] | GCC_ARM | MBED_2 | stdio | 0.79 | 20 | 1/1 |
| OK | NUCLEO_L152RE[0729] | GCC_ARM | MBED_2 | stdio | 0.77 | 20 | 1/1 |
| OK | NUCLEO_F207ZG[F07D] | GCC_ARM | MBED_2 | stdio | 0.74 | 20 | 1/1 |

[LMESTM]

the issue on L476RG / GCC_ARM seems to be somehow related to the changes for bootloader support that were done during 17q2 workshop and which have been rebased and merged recently after cmsis5 updates ...

[0xc0170]

I run CI test shield on F411, all OK. mbed 2 examples on F030R8 - OK

the issue on L476RG / GCC_ARM seems to be somehow related to the changes for bootloader support that were done during 17q2 workshop and which have been rebased and merged recently after cmsis5 updates ...

lets deal with this separately then. I just got the board, going to check what is going on. Is it only GCC ARM ?

I believe this patch is ready to go in for 5.5.1

[0xc0170]

the issue on L476RG / GCC_ARM seems to be somehow related to the changes for bootloader support that were done during 17q2 workshop and which have been rebased and merged recently after cmsis5 updates ...

can you create an issue? I tested ARM, working on that target, GCC_ARM seems to go somewhere with frames corrupted, will require investigation.

[LMESTM]

I think I found the issue in ld file for GCC_ARM: new issue created #4553

[LMESTM]

@0xc0170 maybe you can try that out and confirm it's ok as well on your side: #4554
Thanks !

[waymond91]

Hey Guys,
After playing around with a Nucleo-F411 board for a while I decided I wanted to deploy this MCU to a custom PCB for my application.
I am using an external 8 Mhz crystal, and I believe I have selected the right capacitors for the oscillator.
Regardless, my system hangs and does not make it to the main() function of my code when building via mbed-cli and GCC ARM (using OpenOCD + ARM GDB to debug which is painful).
Configuring to the HSI using the mbed compiler does not work because the program doesn't reach my main function.
If I comment out this line of system_stm32f4xx.c
237 SetSysClock();
the program will make it to my application, but of course everything runs at the default 16Mhz.

Configuring the MCU using CoIde and no mbed libraries seems to work until I set the RCC params and Hal_InitTick() is called within stm32f4xx_hal_rcc.c on line 847.

It seems like you all have worked out a solution here, but I am not quite there. I have updated all the libraries within my build folder. Can anyone point me to a solution here?

[0xc0170]

@waymond91 Please create a new issue for this where someone can help you

provide details about versions of toolchains, mbed OS, mbed-cli, etc , any detail that can help