Hard fault inside freeRTOS tasks restarts schedurer before hit fault handler on debugger

Hi all,

I am working on stm32f769 project, running freeRTOS task, with stm32cubeIDE(1.7.0) debugger.

The debugger does not hit hard faults inside the faulty task , but later, reporting scheduler restart in debug calling stack.
That way I completely miss the error source. how can I locate the error inside the task, while debugging?

I have fitted the task with fault code: illegal_instruction_execution(); which You can found on

" How to debug a HardFault on an ARM Cortex-M MCU" to issue the handler, which in my case issues “MemManage_Handler(void)” , but when the debugger hit this handler, the scheduler is just restarted, and the debugger tab calling stack reports the lastest scheduler restart, no task calling stack before fault code…

How to avoid scheduler restart, or just hit the handler inside and on task running? any help will be appreciated, thanks


What is the MemManage_Handler() - is that a memory protection unit (MPU) port you are using? Can you put a break point in that handler?

The scheduler will not restart itself, so something else is restarting it. Is your application using a watchdog timer?

Hi Richard,
Sorry but i did some further test and I discovered the scheduler was not restarted: simply the latest call stack trace since the GDB entered the freeRTOS scheduler, did not report any further call, because GDB does not trace the private freeRTOS tasks stack.
Unfortunately, to catch the MCU access error that I fit into one of the system task as a debug purpose, I did not have any backtrace to help locate the issues, just for debug…
The only useful info I can get from my debugger IDE(stm32CubeIDE) , is the faulty task, because, when the hard-fault-handler is hit, i can browse the task state and I can see the faulty task ‘running’ .
What I really need is something the let me browse/analize the private task stack memory to possibly get the functions call backtrace and locate the fault.
I would like to know if the above backtrace I need may be done without costly tools…

This page has information about how to find the offending instruction in case of hard faults: Debugging and diagnosing hard faults on ARM Cortex-M CPUs

thank You Gaurav, I’ll try as son as i get back to the fault!

Hi Gaurav,
I have added the code suggested by You on the link above, to investigate and get the fault source code but I didn’t find easy to locate the fault code, furthermore, I tried to fit the ‘bad’ istruction in another ‘C’ module than the assembly code suggested and I get a total different behaviour with no chance to hit the breakpoint fit into the register read into ‘C’ variable as in the example. Probably I need to dig into the MCU register datasheet or do some further test which I’ll do at a later time in the project development. Thank again for Your suggestions