cancel
Showing results for 
Search instead for 
Did you mean: 

stm32cubeIDE debugger running stm32f769 w/ freeRTOS tasks does not hit hard faults inside the faulty task , but later on scheduler restart , missing the error source info...

philsax
Associate II

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 (appended).

How to avoid scheduler restart, or just hit the handler inside and on task running? I appreciate any tips and suggestion,

Roberto

3 REPLIES 3
philsax
Associate II

Hi all,

after some test I found NO scheduler restarting, as I supposed at first. The call stack simply remains freezed on freeRTOS scheduler first start,

maybe because task activity is performed on private freeRTOS stack and no more 'traced' by GDB debugger.

Maybe I just need a freeRTOS 'task' function call stack to be retrieved when fault handler is hit...

TDK
Guru

A MemManage fault indicates a critical failure within your program. You should find and correct the source of that rather than trying to restart the program.

See if the MMFAR address points somewhere useful, find out where that is, and find out why the fault was triggered. Possibly some memory has been inadvertently overwritten. Increasing stack/heap size may help.

https://developer.arm.com/documentation/dui0646/a/cortex-m7-peripherals/system-control-block/memmanage-fault-address-register

If you feel a post has answered your question, please click "Accept as Solution".
philsax
Associate II

Hi TDK,

I Have voluntarily driven the error just for debug purpose, because in past development activity I fall​ into a 'real' unlocated hard fault which takes me many hours to catch. This time I 'd like just to found the necessary debugging info and tools to speed up the time to locate the error source. What i am looking for is for example, the way to browse the tasks stack , to do some backtrace on the function called before the fault.