STM32G484 HardFault_Handler

[ErX]

Hi,

I got stuck in the HardFault_Handler every time after editing some code.

I'm using FreeRTOS in c++ combination with classes. First I thought this would be a memory issue.

After increasing configTOTAL_HEAP_SIZE and configMINIMAL_STACK_SIZE, I was still stuck in the HardFault_Handler. Even by jumping into a function, before I returned from this function the HardFault_Handler was tripped again.

I really tried a number of things...

I made a function (bool Controller::DefaultConfig()) to set the default configuration when nothing was available in the flash and I forgot the return true or false. When adding the return with a result, the problem with HardFault was solved.

Is this a logical behavior? (A compiler error would make more sense)

Greetings,

ErX

[mƎALLEm]

Hello,

How to debug a HardFault on an Arm® Cortex®-M STM32

[KnarfB]

There is a fault analyzer in STM32CubeIDE and STM32Cube VS Code extension (Fault Status Register View) that gives you detailed insight about what exactly happened.

Segger has excellent stuff here Cortex-M Fault - SEGGER Knowledge Base.

FreeRTOS has options to get stack usage high watermarks during runtime (uxTaskGetStackHighWaterMark, uxTaskGetStackHighWaterMark2 - FreeRTOS™).

hth

KnarfB

[Andrew Neil]

In addition to the STM32-specific link from @mƎALLEm, here are some more general Cortex-M resources:

https://community.arm.com/support-forums/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault

[CTapp.1 · Accepted solution]

---

@ErX wrote:

I made a function (bool Controller::DefaultConfig()) to set the default configuration when nothing was available in the flash and I forgot the return true or false. When adding the return with a result, the problem with HardFault was solved.

Is this a logical behavior? (A compiler error would make more sense)

---

You should get a compiler warning for this, but you may need to enable it in the project's settings.

• -Wall (which I would recommend be turned on for all projects)
• -Wreturn-type to catch only this issue.

As you are probably already aware, not having a return statement leads to undefined behaviour - which is one of the things that can lead to a hard fault being signalled.