Default_Handler what is the source?

[pietrodicastri]

Good morning

I have a serious problem detecting the source of the interrupt defaulting to the Default handler,

I need a  procedure to identify what is causing this,

is there a guideline??+

Thank You

Pietro

[egoodii]

Debugging Hard Faults on ARM Cortex-M | MCU on Eclipse

It would seem REALLY USEFUL if ALL the 'demo projects' just included that 'fault handler' to give all 'newbies' just a little more info, as EVERYBODY runs into such faults at one time or another.  One difficulty, though, with the 'given' information is that the trouble is MOST LIKELY to be a 'write fault' (first setup to some peripheral register or the like) and the ARM architecture, Kinetis in particular, has 'write buffers', so the fault doesn't happen 'til a few clocks later', so the PC has 'moved on' (maybe even thru a 'call'), and in particular the 'Bus Fault Address Register' will NOT contain the 'downright useful' faulting address.  One 'test workaround' is to turn OFF such write buffering, at least to 'find' the code bug.

If you are looking for an NVIC-triggered interrupt, then use the 'interrupt in process' registers in NVIC to see 'who', and while usually 'unrelated' the 'old-PC' is visible right on the stack in the interrupt frame once the handler is entered.

[Robin_Shen]

Hi Pietro,

Maybe you can refer this  Application Note 209 Using Cortex-M3 and Cortex-M4 Fault Exception.

I have used the method (see the "Determining where the exception occurred" in that document) on CodeWarrior10.6

Best Regards,

Robin

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[pietrodicastri]

Hei Scott

The document is suggesting to assign a separate handler to each vector. I was thinking to analyse the stack to get

the PC where it was fired. Have you a suggestion for such analysis ??

It is not a fault, it is already handled..

Thank You

Pietro

[scottm]

There's an article here​ on tracking down interrupt sources.  Splitting each interrupt out to its own handler seems to be the easiest way to deal with it.

For me, it's usually a hardfault.  If that's the case, you'll see a 3 in the exception number in the XPSR register.

Scott