cancel
Showing results for 
Search instead for 
Did you mean: 

Hard fault at SystemClock_Config after jumping from OpenBootloader to application

newbie_stm32
Associate III

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?

13 REPLIES 13
Foued_KH
ST Employee

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

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

newbie_stm32
Associate III

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?

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.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

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.

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

TDK_0-1693486197216.png

 

If you feel a post has answered your question, please click "Accept as Solution".

You are wrong. :)

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
newbie_stm32
Associate III

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

newbie_stm32_0-1693544512157.png

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

 

:grinning_face:

newbie_stm32
Associate III

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.