Error_Handler debugging

[David Pekin]

Posted on February 27, 2018 at 19:29

Hello,

The HAL code uses a Error_Handler() function which just spins forever in a tight loop.   I've seen comments about changing the call to report __FILE__ & __LINE__  which I may do.   But I thought setting a breakpoint in the Error_Handler() code would lead me to the caller and failure.   I'm using the IAR tools and when the breakpoint is hit, the call stack shows, main, Exception Frame, and Error_Handler.  This doesn't tell me what called the Error_Handler() function.  

Does anyone know how to track down the caller using the IAR debugger?

Thanks!

[Tesla DeLorean]

Posted on February 27, 2018 at 19:46

The LR register would indicate where it was called from, and if you just break-point and permit it to return as you step it you'll see the point too.

The optimizer gets in the way, folding multiple calls into a singular dispatch point. The CubeMX approach with __FILE__ and __LINE__ is likely the optimal way to instrument and report automatically.

[Tesla DeLorean]

Posted on February 27, 2018 at 22:28

DAHMEN.IMEN

‌

st.mcu

‌ Please have the HAL team migrate ALL the example code trees to use the Error_Handler(__FILE__,__LINE) methodology, the consistent application between that and CubeMX will allow bugs and issues to be run down more quickly. Having this as a definable behaviour will also help reduce objections, like the FULL_ASSERT, would allow you to tune out on release builds if desired, although frankly having a release product that outputs some diagnostic rather than fall into a black hole is surely preferable.

I might also lobby for a better default HardFault_Handler, I have this variant of Joseph Yiu's original, where I dump more of the working registers, this can help in the field to provide clues about what went wrong without the need to involve the customer or a debugger.

CM0(+) mod

https://community.st.com/0D70X000006T1bfSAC

Default console IO to SWV would also be nice, but probably too big an ask.