A better fault handler and error handler?

[john doe]

Posted on April 06, 2017 at 03:10

I'm pretty new to debugging using something other than an LED and printf.  Now that I have my big boy pants on and am starting to use an actual debugger, I'm finding that the spin-in-an-infinite-loop handler could be improved upon.

Clive One, you mentioned in a post to check out some person's work regarding fault handlers but I cant find the post

Also, what do you guys do for a better Error_Handler() ?

[Tesla DeLorean]

Posted on April 06, 2017 at 04:16

Joseph Yiu of Essential Cortex-Mx and ARM fame published some examples.

This is my take on that

 

There are bunch of similar posts, but this one is more of a 'Do Exactly This' form

Now this is of course reliant on printf via SWO or USARTx is implemented and still functional, and the stack work. If the system is totally hosed you'll need the debugger, but for most things where you touch memory wrong, execute illegal instructions, or do misaligned loads/stores, this will at least provide some telemetry without a debugger attached.

[Tesla DeLorean]

Posted on April 06, 2017 at 04:31

The Cortex-M3/M4 is generally quite tolerant of alignment, one pitfall I run into most frequently is loading a double from an unsigned char pointer, ie double foo = *((double *)&p[8]);

Keil will use LDRD to do that 64-bit load into two registers, if the pointer is unaligned then bang!

The Cortex-M0 is very fussy about alignment. Like the old ARM7/9 days use memcpy() to bring potentially unaligned structures into a known aligned one, ie a local/auto variable the compiler has allocated.

For the Cortex-M4 make sure the FPU (coprocessor) is enabled, if a function uses floating point extended instructions it can use extended instructions to push the context upon entry.

Code compiled for an M4 is run on an M3, there are a couple of new instructions Keil uses, will catch out the unwary. If code targets both M3 and M4 cores, compile as an M3

[Andrei Chichak]

Posted on April 06, 2017 at 07:39

I'd just like to say this about that: the error handler routine that is generated in Cube is malformed. It is used to handle all of the various errors that are generated in the interface routines for the various peripherals, BUT IT DOESN'T TAKE ANY PARAMETERS.

So you have a function declared void Error_Handler(void) that is used in all cases. You have no context, no parameter to differentiate between the cases, so you can't print anything useful, and you don't know where to look for errors, nothing.

Now if Error_Handler was replaced by some sort of macro that, by default, expanded to void Error_Handler(void), but you could fill in a bit of the body and use __FILE__ and __LINE__, you could do something useful.

But, we're going to have to get a little help from ST on this one.  What do you say ST? Can you change the error handler to give some context information?

Andrei