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.

[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]

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.

[waclawek.jan]

> I am getting a hard fault at SystemClock_Config

Where, exactly? What is changing at the moment which leads to HardFault, and how? You may want to single-step in disasm to find out exactly the answer, and also read out content of relevant RCC (and any other relevant) registers just before the fault happens.

JW

[newbie_stm32]

Hi @waclawek.jan it exactly hit hard fault at HAL_RCC_OscConfig.

[waclawek.jan]

HAL_RCC_OscConfig is a function, which has many individual lines. And it is open source, as all Cube is. So step through them (using Step Into) to determine, where exactly the problem happens.

If the problem happens *exactly* on the call (i.e. step-into won't work either, and in disasm single-step the problem occurs on bl xxxx), then it's either incorrectly set stack pointer - read out processor core registers to check this - or an incorrectly linked program - look at disasm whether the HAL_RCC_OscConfig makes sense.

JW

PS What is OpenBootloader? And which STM32 are you using?

[newbie_stm32]

Hi @waclawek.jan thanks for your input. I will follow your suggestion and get back to you.

> PS What is OpenBootloader?

It is an open-source implementation of bootloader by ST.

> And which STM32 are you using?

STM32G491RET