How to Know which Peripheral is causing Hard Fault?

[Amit_Kumar1]

Hi
I am using K60 with cw10.6. I am trying to debug the board using PE Multilink. It goes to the following loop in CPU.C

/*

** ===================================================================

** Method : Cpu_Cpu_ivINT_Hard_Fault (component MK60DN512LL10)

**

** Description :

** This ISR services an unused interrupt/exception vector.

** This method is internal. It is used by Processor Expert only.

** ===================================================================

*/

PE_ISR(Cpu_ivINT_Hard_Fault)

{

}

How Do I know which part of the code is creating this hard fault? Is there any tutorial or document which states how to debug efficiently using PE multilink / JTAG / SWD ?

Kind Regards

Amit Kumar

[luizdavimartins]

Did you discover what was wrong? Can you share it with us?

[Amit_Kumar1]

Hi Luiz

The RTC module was on but the VBAT was not powered on. That was creating a hardfault. There can be many issue causing this but for my case that was the issue.

Kind Regards

Amit Kumar

[luizdavimartins]

I understand, Amit.

I'm facing a similar issue with a KL04Z8 processor. However I got no VBAT pin here. I'm afraid there's something else causing this problem.

Would you have any clues on that?

Best regards!

[Amit_Kumar1]

Hi Luiz

Please check the following link you might get some help here http://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/

Regards

Amit Kumar

[egoodii]

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.

[luizdavimartins]

Earl,

in this case, it was even worse: This is a BUG on freescale Kinetis Design Studio.

The PE memory map was wrong.

I hope they correct it ASAP.

Thanks y'all.

[BlackNight]

FYI, the wrong memory map (linker file) thread is in https://community.freescale.com/message/436064#436064.

Erich

[BlackNight]

In addition to that: try to isolate the instruction causing the hard fault. It could be that you try to access a peripheral and the clocks are not enabled for it.

Erich

[LuisCasado · Accepted solution]

Hello,

Check this : http://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/

Regards,

Luis

[Amit_Kumar1]

Hi Luis

Thanks for the quick reply.  This is what I was looking for.

Regards

Amit Kumar