A Way to Detect Imprecise Hard Fault Source

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

A Way to Detect Imprecise Hard Fault Source

No ratings

A Way to Detect Imprecise Hard Fault Source

This document was created in collaboration with Dragos Musoiu

Trying to debug a hard fault on MKW24D512, ARM Cortex M4 based microcontroller, we did not find too much documentation on working with IMPRECISE hard faults.  We started our investigation from the post of Erich Styger Debugging Hard Faults on ARM Cortex-M. Based on this, we used Erich’s code to find the hard fault source, but it was impossible to find the instruction that caused the hard fault, because the executed instructions around the saved PC looked to be correct. 

After, we checked the Hard Fault Status Register, from the System Control Block of the ARM Cortex M4 processor, we found the FORCED bit set. The ARM Cortex M4 documentation mentions that this bit indicates a forced hard fault, generated by escalation of a fault with configurable priority that cannot be handled, either because of priority or because it is disabled. When this bit is set to 1, the HardFault handler must read the other fault status registers to find the cause of the fault. We checked the other fault registers and we found, in the Configurable Fault Status Register (Bus Fault Status Register) from the System Control Block of the ARM Cortex M4 processor, the IMPRECISERR bit set. According to the ARM Cortex M4 documentation, if this bit is set a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. So that explained why we did not find the instruction that caused the hard fault using Erich’s indications. Also, this is an asynchronous fault. Therefore, if it is detected when the priority of the current process is higher than the BusFault priority, the BusFault becomes pending and becomes active only when the processor returns from all higher priority processes.

The Cortex M4 processors have a write buffer feature that when a write is carried out to a bufferable memory region, the processor can proceed to the next instruction before the transfer is completed. This is great for performance, but can cause some complexity in debugging imprecise bus faults.

Studying better the documentation, we found in the ARM Cortex M4 Auxiliary Control Register the DISDEFWBUF bit that when set to 1, disables write buffer use during default memory map accesses. This causes all BusFaults to be precise BusFaults but decreases performance because any store to memory must complete before the processor can execute the next instruction. In this way the processor will not continue executing the next instruction until the write operation is completed, and so enabling this bit and using Erich’s code the saved PC pointed to the instruction which caused the hard fault.

In other case, if the Bus Fault is triggered by an instruction executed in an interrupt handler, with higher priority than the BusFault handler, setting the DISDEFWBUF can be useful in the debugging process because the BFAR register value remains valid in case of precise error.

Comments

Hi @andreikovacs-b5  / all,

We're using NXP S32K3 which is based on Cortex M7F where we could not find the DISDEFWBUF bit. it is not available. Is there some other mechanism to find out the IMPRECISEERR.

Version history
Last update:
‎02-23-2015 01:26 AM
Updated by: