Hard fault at SystemClock_Config after jumping from OpenBootloader to application

[newbie_stm32]

Hello Community,

I am getting a hard fault at SystemClock_Config when executing the application after jumping from OpenBootloader. It is confirmed by single stepping through application. The bootloader uses HSI (16MHz) and PLL to operate at 72MHz and the application uses HSE (24MHz) and PLL to run at 170MHz. When the application clock is configured to use HSI and run at 170MHz it works fine.

So what might be missing here?

Any hints?

[Foued_KH]

Hello @newbie_stm32, 

Make sure that the clock configuration code in your application is correct and matches the clock configuration used in the OpenBootloader.
If there is a mismatch, it could cause a hard fault.

Foued

[newbie_stm32]

Hi @Foued_KH thanks for the reply.

Yes, there are differences. The bootloader uses HSI and our application uses HSE. So is there any way to overcome this?

In the RM0440 it is mentioned that a transition state is required when switching from HSI16 to HSE. How to apply this if we are using code generation from STM32CubeIDE?

[gbm]

The easy way is to deconfigure the system clock completely. You may call SystemInit(), defined in the system_xxx.c file.

For me, the safest option is to write the bootloader in such a way that it enters the user app right after reset, with the MCU at default settings. This is achieved by putting some magic value in one of backup registers, then resetting the MCU via software. In the first lines of bootloader code, the bootloader checks for his value and invokes the app, skipping the booloader-related MCU configuration code.

[newbie_stm32]

Hi @gbm correct me if I am wrong. SystemInit() is used to set the vector table and has nothing to do with clock configuration and SystemInit() is called in the startup file.

[TDK]

A quick look at SystemInit will show you it does change clock settings.

[gbm]

You are wrong. 🙂

[newbie_stm32]

Hi @gbm, @TDK thanks for your inputs. I am referring to this. Which is defined in the system_stm32g4xx.c file by STM32CubeIDE.

@TDK can you please point out which file are you referring to?

[newbie_stm32]

😀

[newbie_stm32]

Hi @gbm, @TDK, @Foued_KH issue is because of different clock sources. Although it is recommended to use HSI on the bootloader can I change the bootloader to use HSE in that way both the bootloader and our application have the same clock sources.