2023-08-31 01:59 AM
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?
2023-09-01 02:27 AM
> 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
2023-09-04 02:36 AM
Hi @waclawek.jan it exactly hit hard fault at HAL_RCC_OscConfig.
2023-09-04 07:01 AM - edited 2023-09-04 07:04 AM
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?
2023-09-04 08:39 PM
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