You copied the Doc URL to your clipboard.

Fault handling

In ARMv7-M and the ARMv8-M architecture with Main Extension, several Fault Status Registers (XFSR) are available to allow fault handlers to identify the cause of the fault exceptions. Each fault has an associated Fault Status Register. Fault Address Registers (XFAR) are available to indicate the address of the access that triggers the fault.

The fault status registers indicate the cause of a fault. For synchronous BusFaults and MemManage faults, the fault address register indicates the address that is accessed by the operation that caused the fault.

The following table shows the fault status and fault address registers:

Handler

Status register name

Address register name

Register description

HardFault

HFSR

-

HardFault Status Register

MemManage

MMFSR

-

MemManage Fault Status Register

MMFAR

MemManage Fault Address Register

BusFault

BFSR

-

BusFault Status Register

-

BFAR

BusFault Address Register

UsageFault

UFSR

-

UsageFault Status Register

The following table shows:

  • The type of fault
  • The handler that is used for the fault.
  • The corresponding fault status register, and
  • The register bit that indicates that the fault has occurred.

Fault

Handler

Bit name

Fault status register

Bus error on a vector read

HardFault

VECTTBL

HardFault Status Register

Fault escalated to a hard fault

FORCED

MPU or default memory map mismatch:

MemManage

-

MemManage Fault Status Register

On instruction access

IACCVIOL

On data access

DACCVIOL

During exception stacking

MSTKERR

During exception unstacking

MUNSKERR

During lazy floating-point state preservation

MLSPERR

Bus error:

BusFault

-

-

During exception stacking

STKERR

BusFault Status Register

During exception unstacking

UNSTKERR

During instruction prefetch

BUSERR

During lazy floating-point state preservation

LSPERR

Precise data bus error

PRECISERR

Imprecise data bus error

IMPRECISERR

Attempt to access a coprocessor

UsageFault

NOCP

UsageFault Status Register

UNDEFINED instruction

-

UNDEFINSTR

Attempt to enter an invalid instruction set state

INVSTATE

Invalid EXC_RETURN value

INVPC

Illegal unaligned load or store

UNALIGNED

Divide By 0

DIVBYZERO

Note

A fault inside a HardFault handler locks up the core.

Synchronous and Asynchronous bus faults

Bus Faults are subdivided into two classes:

A synchronous bus fault.

This is also described as a precise bus fault in older versions of ARM documents, and refers to the fault exception that takes place immediately after the bus transfer is carried out.

An asynchronous bus fault.

This is also described as an imprecise bus fault in older versions of ARM documents, and refers to the fault exception that can take place a certain time after the bus transfer is carried out, where the processor could have executed further instructions before the exception sequence started.

Synchronous bus fault

A synchronous BusFault can escalate into lockup if it occurs inside an NMI or HardFault handler. Cache maintenance operations can also trigger a bus fault.

The fault handler can use BFSR to determine whether faults are asynchronous or synchronous. Asynchronous faults are often unrecoverable, as you do not know which code caused the error.

Asynchronous bus fault

An asynchronous bus fault can happen when there is write buffering in the processor design. As a result, the processor pipeline proceeds to subsequent instruction execution before the bus error response is observed.

Debug accesses can also trigger Bus Faults. Debugger load or store accesses are synchronous, and are visible to the debugger interface only.

When an asynchronous bus fault is triggered, the BusFault exception is pended. If another higher priority interrupt event arrived at the same time, the higher priority interrupt handler is executed first, and then the Bus Fault exception takes place. If the BusFault handler is not enabled, the HardFault exception is pended instead. The HardFault caused by the asynchronous BusFault never escalates into lockup.

Lockup state

The processor enters lockup state if a fault occurs when executing the NMI or HardFault handlers. When NMI is Non-secure and a Security violation is detected, it triggers a Secure HardFault at priority level 3. When the processor is in lockup state, it does not execute any instructions.

The processor remains in lockup state until either:

  • It is reset.
  • An NMI occurs.
  • A debugger halts it.

Note

If lockup state occurs from the NMI handler, a subsequent NMI does not cause the processor to leave lockup state.

Non-secure fault handler considerations

When migrating software from ARMv6-M or ARMv7-M to ARMv8-M architecture, software developers that create Non-secure software must be aware of some possible changes:

  • The HardFault and BusFault handler might no longer be used because the Secure software on chip has its own HardFault and BusFault handlers (AIRCR.BFHFNMINS might be set to 0).
  • Self-reset might not be accessible from Non-secure software. When TrustZone technology for ARMv8-M is implemented, Secure software can configure whether Non-secure software can access the SYSRESETREQ bit in AIRCR. Also, the AIRCR.VECTRESET bit in ARMv7-M is not available in ARMv8-M architecture.

General considerations

In general, software developers for Secure software:

  • Must always implement fault handlers to ensure that software developers creating Non-secure software can be aware of problems during software development.
  • Secure software must utilize stack limit registers to ensure that stack overflow in Secure software can be detected and handled by a Secure HardFault or Usage Fault handler.
  • Secure fault handlers must not call Non-secure functions to prevent Non-secure code gaining access to the Secure state which can be used for DoS attack.
Was this page helpful? Yes No