cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 Goes into HardFault_Handler() before going into HAL_Init()

Kunaalkk1
Associate II

Dear Community,

I am currently facing this issue where my STM32 Black Pill F411CE suddenly went into hard fault during runtime. The MCU was permanently gone and was not able to be re-programmed, and four others that I connected to the same hardware were also gone. After waiting some time, I replaced the Black Pill on my hardware with the same firmware. It was working; and it has been working fine for a couple of hours now. Note that the hardware is thoroughly tested and has been used for past few years, so I don't know if it could be a problem. Also, one of the MCUs that got damaged, is able to upload and even verify the code, but in the debug mode, it goes into Hard Fault Handler at start even before HAL Init. My understanding is that the flash got corrupted in all of them all at once. I have no RTOS in the firmware, and it uses STM32 HAL Libraries, and it is doubtful that there was any memory access issue, because the firmware is tested properly, and I really don't know how five microcontrollers flash corrupted all of a sudden. There is usage of DMA, and also, interrupts. Has anyone faced a similar issue?

I tried running the debugger. It directly starts in the hard fault handler instead of main. Here is the register info:
sp -> 0x2001ffd4
pc -> 0x8005408 <HardFault_Handler + 4>

Debugger Console:

 

 

 

Program received signal SIGTRAP, Trace/breakpoint trap.

HardFault_Handler () at ../Core/Src/stm32f4xx_it.c:95

95 {

warning: Could not fetch required XPSR content. Further unwinding is impossible.



Program received signal SIGINT, Interrupt.

HardFault_Handler () at ../Core/Src/stm32f4xx_it.c:99

99 while (1)

warning: Could not fetch required XPSR content. Further unwinding is impossible.

 

Regards,

Kunaal

1 ACCEPTED SOLUTION

Accepted Solutions
Kunaalkk1
Associate II

UPDATE: Turns out this was a problem with STM32CudeIDE v1.16.0. I never faced this in STM32CudeIDE v1.14.0. What happened was that I had cloned the project for two separate Hardwares in separate workspaces. When I modified the IOC and selected "Generate code", the code did not re-generate at all, even though the IOC was updated. Unknowingly, I put the black pill in my new hardware, and it failed because the changes in IOC were not updated in the generated code. I figured out this issue when I removed I2C channel from my IOC and replaced it with other pins, but I saw later that my code still had "i2c.h" and MX_I2C_Init () in the main.c. Moreover, I found that even other users are facing this code generation issue in cloned projects. @stmicro please fix this major bug in the IDE. I made some changes in the code, and now I am not facing this issue.

 

Thanks to all responders in this thread for their suggestions.

Regards,

Kunaal

View solution in original post

7 REPLIES 7
TDK
Guru

Examine the SCB registers to understand the reason for the hard fault. Lots of code gets executed before main() is called. Set a breakpoint just after Reset_Handler in the startup file and step through the code to understand where it's crashing.

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

Start with a simple firmware (such as blinking an LED) to isolate hardware from firmware problems.

SofLit
ST Employee

Hello,

Black Pill /Blue Pill / X Pill flavor boards suffer from counterfeits of STM32 MCUs.

I suggest you to purchase one of ST boards example: NUCLEO-F411RE

See also this discussion: https://community.st.com/t5/stm32-mcus-products/stm32f1-canbus-problem-zephyr/m-p/721112

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.
Andrew Neil
Evangelist III

@Kunaalkk1 wrote:

 Black Pill 


As @SofLit suggested, there is a near-zero chance that a Black Pill has a genuine STM32

Here's another thread on the woes of Black/Blue Pill and other fakery:

https://community.st.com/t5/stm32-mcus-products/blue-pill-stm32f1-board-gets-programmed-through-arduino-ide-but/m-p/667923

 

Look at what's actually faulting, a while loop in the HardFault_Handler() is stock code and tells us nothing.

Inspect the context pushed on the stack.

Look at code in startup.s and SystemInit() which runs prior to main()

Look at what it's copying where, from external memories, or other things which haven't been initialized yet.

Watch for a stack frame (SP) being placed into CCM (0x10000000), that needs to be enabled first

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Kunaalkk1
Associate II

UPDATE: Turns out this was a problem with STM32CudeIDE v1.16.0. I never faced this in STM32CudeIDE v1.14.0. What happened was that I had cloned the project for two separate Hardwares in separate workspaces. When I modified the IOC and selected "Generate code", the code did not re-generate at all, even though the IOC was updated. Unknowingly, I put the black pill in my new hardware, and it failed because the changes in IOC were not updated in the generated code. I figured out this issue when I removed I2C channel from my IOC and replaced it with other pins, but I saw later that my code still had "i2c.h" and MX_I2C_Init () in the main.c. Moreover, I found that even other users are facing this code generation issue in cloned projects. @stmicro please fix this major bug in the IDE. I made some changes in the code, and now I am not facing this issue.

 

Thanks to all responders in this thread for their suggestions.

Regards,

Kunaal

Thanks @TDK @Tesla DeLorean @Andrew Neil @SofLit @liaifat85 for your responses, issue is resolved, please check the accepted solution for updates.