Storing Stackframe in Hardfault for STM32F7 only works with debugger connected

[boehluk]

Hello, 

I want to store the stack frame when an exception happens into a no-init section of SRAM to analyse exceptions.

So I wrote a Hardfault handler to do this. 

I did the same for STM32F429 controller and it worked just fine but on STM32F756 it only works when I have my debugger connected. If it's not connected the handler doesn't store the data to the section. 

I tried to turn off optimization, disable the DCache and tried various ways to store it (with memcpy or via pointer) but all didn't help. 

The Hardfault_Handler assembly is derived from this site: Cortex-M Fault - SEGGER Wiki

I do a branch jump to my Hardfault_Handler_C routine. File is attached. 

What do I miss here?

Thanks in advance!

[Jacob WOODRUFF]

Hi All,

This case has been routed to our online support center for direct support.

Regards,
Jake

ST Support

[Bob S]

Without the debugger, how do you KNOW that the values are not stored in RAM? Do you see garbage/unexpected values when you reboot?

Since your fault handler enters an infinite loop, I presume you reboot the CPU somehow and your startup code checks that RAM area.  Does that reboot happen differently with the debugger?  For example, with the debugger I see you force a breakpoint.  I presume that is how you verify the data was written to RAM.  Do you then use the debugger to "reset" the CPU (i.e. the "reset the CPU and restart the debugger" button)?  Because that kind of "reset" is slightly different than a reset without the debugger (watchdog or hardware reset).

And please do not post your code as attachments.  Paste it in your message using the code formatting button (click on the "..." button then the "</>" button).  Forcing people to download files from "someone on some forum" goes against IT security "good practices".

[boehluk]

I can read out the RAM section through ethernet function and also when I do a debugger connect to running target I see, it is not stored there. I see garbage, random values. 

The infinite loop waits for independent watchdog to reset the MCU. I do not reset the MCU with the debugger. 

I also tried without the breakpoints, but didn't help.