2024-09-16 11:38 PM - edited 2024-09-17 12:52 AM
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
Solved! Go to Solution.
2024-09-19 02:07 AM
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
2024-09-17 06:22 AM
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.
2024-09-17 07:06 AM
Start with a simple firmware (such as blinking an LED) to isolate hardware from firmware problems.
2024-09-17 10:12 AM - edited 2024-09-17 10:13 AM
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
2024-09-17 10:19 AM
@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:
2024-09-17 10:38 AM
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
2024-09-19 02:07 AM
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
2024-09-19 02:09 AM - edited 2024-09-19 02:11 AM
Thanks @TDK @Tesla DeLorean @Andrew Neil @SofLit @liaifat85 for your responses, issue is resolved, please check the accepted solution for updates.