How to Know which Peripheral is causing Hard Fault?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to Know which Peripheral is causing Hard Fault?

Jump to solution
3,245 Views
Amit_Kumar1
Senior Contributor II

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

1 Solution
2,045 Views
LuisCasado
NXP Employee
NXP Employee
0 Kudos
10 Replies
2,045 Views
luizdavimartins
Contributor II

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

0 Kudos
2,046 Views
Amit_Kumar1
Senior Contributor II

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

2,046 Views
luizdavimartins
Contributor II

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!

0 Kudos
2,046 Views
Amit_Kumar1
Senior Contributor II

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

0 Kudos
2,046 Views
egoodii
Senior Contributor III

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.

0 Kudos
2,046 Views
luizdavimartins
Contributor II

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.

0 Kudos
2,046 Views
BlackNight
NXP Employee
NXP Employee

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

Erich

0 Kudos
2,049 Views
BlackNight
NXP Employee
NXP Employee

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

0 Kudos
2,046 Views
LuisCasado
NXP Employee
NXP Employee
0 Kudos
2,049 Views
Amit_Kumar1
Senior Contributor II

Hi Luis

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


Regards

Amit Kumar

0 Kudos