Derek Snell

Tracking down Hard Faults

Discussion created by Derek Snell Employee on Apr 12, 2013
Latest reply on Oct 23, 2013 by Erich Styger

Hard faults can be a pain to track down, especially if they are intermittent and don't happen consistently in the same location. A Hard Fault is an ARM Cortex exception, and the ARM M0 Generic User Guide lists the following sources for a hard fault:


Faults are a subset of exceptions, see Exception model on page 2-19. All faults result in

the HardFault exception being taken or cause lockup if they occur in the NMI or

HardFault handler. The faults are:

  • execution of an SVC instruction at a priority equal or higher than SVCall

  • execution of a BKPT instruction without a debugger attached

  • a system-generated bus error on a load or store

  • execution of an instruction from an XN memory address

  • execution of an instruction from a location for which the system generates a bus


  • a system-generated bus error on a vector fetch

  • execution of an Undefined instruction

  • execution of an instruction when not in Thumb-State as a result of the T-bit being

previously cleared to 0

  • an attempted load or store to an unaligned address.


But I find usually a hard fault is caused by a bus error or unaligned address. Bus errors in Kinetis are usually accessing an invalid address (usually from a bad pointer), or accessing a peripheral register before the clock gate is enabled. In either case, the bus stalls out with no response, triggering a hard fault.


Debugging hard faults is a common issue in ARM cores, and if you Google the issue, you will find several guides and tips available for help finding the root cause of the hard fault, including this appnote below from Keil, although it is targeted at M3 and M4 cores:


IAR also has a macro to help with their debugger.  Here's more details, with some tips for diagnosing hard faults:

IAR Debugging a HardFault on Cortex-M 


From NXP, our software expert Erich has a blog site, where he has posted some good information on tracking down hard faults. This link describes a hard fault handler he implemented to find the PC location of where the hard fault occurred:


He also has a post on automating the GDB debugger to run a script with the hard fault details, which can be used within the Kinetis Design Studio (KDS) IDE:

Debugging ARM Cortex-M Hard Faults with GDB Custom Command | MCU on Eclipse 


And then he discusses how to use the Micro Trace Buffer in the M0+ core to get more visibility in the execution history leading up to the hard fault


For legacy users using Processor Expert, he even wrapped his handler in a Processor Expert component