You copied the Doc URL to your clipboard.

Fault exceptions

In ARMv8-M processors, error conditions are handled by fault exceptions. Fault exceptions are similar to interrupts, where piece of software that is called a handler is executed when fault event taken place.

Events can generate faults, for example:

  • A bus error on:
    • An instruction fetch or vector table load.
    • A data access.
  • An internally detected error like an UNDEFINED instruction.
  • Attempting to execute an instruction from a memory region marked as Execute Never (XN).
  • A privilege violation or an attempt to access an unmanaged region causing an MPU fault.

Description of fault types

Based on the processor implementation and the optional features included, there can be different type of fault exceptions available.

Fault type

Short name

Descriptions

Hard Fault

HardFault

Default Fault exception.

Always enabled.

Occurs because of an error during exception processing, or because an exception cannot be managed by any other exception mechanism.

Bus Fault

BusFault

Occurs because of a memory-related fault for an instruction or data memory transaction. This might be from an error that is detected on a bus in the memory system.

Disabled by default. Only enable if necessary.

Not available in the ARMv8-M architecture or ARMv6-M processors.

Usage Fault

UsageFault

Occurs because of a memory protection-related fault.

Disabled by default. Only enable if necessary.

The MPU or the fixed memory protection constraints determine this fault, for both instruction and data memory transactions.

This fault is always used to abort instruction accesses to Execute Never (XN) memory regions.

Not available in the ARMv8-M architecture or ARMv6-M processors.

Memory Management Fault

MemManage

Caused by violation of access permission set by the Memory Protection Unit (MPU) or attempting to execute code from XN (eXecute Never) address regions.

Disabled by default. Only enable if necessary.

Not available in the ARMv8-M architecture or ARMv6-M processors.

Secure Fault

SecureFault

Caused by Security violations.

Non-secure branches to unauthorized Secure addresses cause a SecureFault exception.

Available in the ARMv8-M architecture with main Extension only, and present only if the ARMv8-M Security Extension is implemented.

In ARMv8-M architecture, security violations are handled by HardFault.

A simple system might only use the HardFault handler.

Note

  • The Bus Fault, Usage Fault, Memory Management Fault, and Secure Fault exceptions are configurable fault exceptions. They can be enabled by software.
  • Configurable Fault exceptions have programmable exception priority levels similar to interrupts and other system exceptions.
  • The HardFault exception has a priority level of 1 (higher than all other exceptions apart from the NMI), or can be priority level 3 (higher than NMI) if it is triggered by a Security violation in Non-secure NMI in the ARMv8-M architecture.

If a fault event is triggered and the corresponding Configurable Fault exception is disabled, of if the priority level of the configurable fault exception is not high enough to trigger a preemption, the HardFault exception would be triggered instead. This is called escalation.

Fault escalation and HardFault

Fault escalation can occur for the following reasons:

  • The fault is not enabled.
  • The fault handler has insufficient priority to run.
  • The fault handler encounters the same fault.

For example:

  • An UNDEFINED instruction is decoded.
    • The processor tries to signal a UsageFault, but the UsageFault is not enabled.
  • With the MPU enabled an interrupt handler makes and illegal memory accesss
    • Processor tries to signal a memManage fault, bu the fault priority is lower than the priority of the running interrupt.
  • An UNDEFINED instruction is encountered in a UsageFault handler
    • An enabled fault handler causes the same kind of fault as is being serviced.

All fault exceptions except for HardFault have a configurable exception priority. Software can disable execution of the configurable fault handlers, but not the HardFault handler.

The exception priority, and the values of the exception mask registers determine whether the processor enters the fault handler, and whether one fault handler can preempt another fault handler.

In some situations, a fault with configurable priority is treated as a HardFault. This is called priority escalation, and the fault is described as being escalated to HardFault. Escalation to HardFault occurs when:

  • A fault handler causes the same kind of fault as the one it is servicing. The escalation to HardFault occurs because a fault handler cannot preempt itself because it must have the same priority as the current priority level.
  • A fault handler causes a fault with the same or lower priority as the fault it is servicing. This is because the handler for the new fault cannot preempt the currently executing fault handler.
  • An exception handler causes a fault for which the priority is the same as or lower than the currently executing exception.
  • A fault occurs and the handler for that fault is not enabled.

If a Bus Fault occurs during a stack push when entering a Bus Fault handler, the Bus Fault does not escalate to a HardFault. This means that if a corrupted stack causes a fault, the fault handler executes even though the stack push for the handler failed. The fault handler operates but the stack contents are corrupted.

Note

  • Only Reset and NMI can preempt the fixed priority HardFault. A HardFault can preempt any exception other than Reset, NMI, or another HardFault. In the ARMv8-M architecture, a Security violation in a Non-secure NMI handler (if BFHFNMINS is set to 1) would trigger and be preempted by a Secure HardFault exception.
  • In the case where a bus error occurred during an exception vector fetch, this is always handled by HardFault exception and not BusFault.
Was this page helpful? Yes No