Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3.

Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language.

Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register).

BusFault status register bits

The definition for imprecise and precise bits is:

[2]	IMPRECISERR	Imprecise data bus error: 0 = no imprecise data bus error 1 = 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. 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. If a precise fault occurs before the processor enters the handler for the imprecise BusFault, the handler detects both IMPRECISERR set to 1 and one of the precise fault status bits set to 1.
[1]	PRECISERR	Precise data bus error: 0 = no precise data bus error 1 = a data bus error has occurred, and the PC value stacked for the exception return points to the instruction that caused the fault. When the processor sets this bit is 1, it writes the faulting address to the BFAR.

An imprecise error is most often caused by a write to an invalid address. Because writes can be cached the write can happen an instruction or more after the instruction that performed the write. This delay is the cause of the imprecise error, the current instruction is not the instruction that caused the fault.

A good starting debugging step is to determine the revision of the Cortex-M3 core. Revision 2 of the Cortex-M3 core have the Auxiliary Control register (ACTLR) Older version 1 cores lack this register. If you are using a r2 core you should disable write buffering at startup by setting the DISDEFWBUF bit to 1 . This will slow the execution speed of your application code but it will convert difficult to locate imprecise faults into precise faults, enabling you to look at BFAR to see the address of the instruction that caused the fault. At that point you should be able to debug the issue by looking at the assembly code and call chain and put a breakpoint on the offending line of code to examine the cause.

If, like me, you are using a revision of the Cortex-M3 that lacks the ACTLR register and the ability to disable write buffering, such as the STM32F10x series, you'll have to move to a much more time consuming approach.

Start by determining under what conditions your system is seeing imprecise faults. Reproducible faults are debuggable faults. Bisect the code with prints or breakpoints until you've narrowed down the fault then switch to single stepping through each instruction. As you step through the code record the instruction addresses. At some point you'll step and the processor will jump to the HardFault exception handler. At that point you should restart the system and reproduce the error and start single stepping from the last valid address you recorded. Eventually you should determine precisely where the fault happens. The offending instruction will be within a few instructions of the one that jumps to the HardFault exception.

Debugging imprecise faults isn't easy. I'd recommend trying to use a Cortex-M3 processor with support for disabling write buffering via the ACTLR. I like the STM32F10x series processors but the hundred or more hours spent debugging imprecise bus faults in the past few years hasn't been fun. Hope this helps.