Fault Handling in Arm Cortex Mx Processor : Master Fault Handling in ARM Cortex-Mx processors is a crucial mechanism that helps ensure system reliability and stability by detecting, reporting, and managing faults such as memory access errors, illegal instructions, or bus errors. When a fault occurs, specialized hardware fault status registers capture detailed information about the cause and location of the fault. The processor then transfers control to fault handlers—dedicated routines designed to analyze the fault, report diagnostic information, and take remedial actions like system recovery or reset.

This fault management system includes several layers of faults, such as Hard Faults, Usage Faults, Bus Faults, and Memory Management Faults, each with specific status registers and address registers that provide rich diagnostic data. Effective fault handling in Cortex-Mx processors enables embedded developers to build robust and fault-tolerant applications critical for modern real-time and safety-critical systems.

What is a Fault in a Processor?

In embedded systems or microcontrollers (like ARM Cortex-M), a fault is a type of exception generated by the processor itself when something goes wrong during code execution. This is also called a system exception.

Think of a fault like an emergency signal that tells the processor:

“Something’s not right — we need to pause and handle this issue properly!”

Why Do Faults Happen?

Faults usually happen when:

• A programmer violates the processor’s rules, like trying to divide by zero.
• The processor faces a problem while dealing with external interfaces, like memory.

What happens when a fault occurs?

When a fault happens:

1. The processor updates internal registers with important info:
   • What kind of fault happened?
   • At which address did it occur?
2. If the fault exception is enabled, the processor will jump to the exception handler — a special block of code written by the programmer.
3. The exception handler can:
   • Report the error (e.g., log it)
   • Try to fix it (if possible)
   • Or stop the faulty task

Example:

If your code does this:

int a = 5 / 0;

→ It causes a divide-by-zero fault, and the Usage Fault Exception Handler (if enabled) is triggered.
Inside the handler, you can decide what action to take (like terminating the task).

Types of Fault Exceptions

There are four major fault exceptions:

Exception Type	Enabled by Default?	Priority	Can Be Disabled?
Hard Fault	✅ Yes	Fixed (-1)	❌ No (only maskable using FAULTMASK)
Usage Fault	❌ No	Configurable	✅ Yes
MemManage Fault	❌ No	Configurable	✅ Yes
Bus Fault	❌ No	Configurable	✅ Yes

Causes of Faults

Here are common reasons faults can occur:

• ❌ Divide by zero (if divide-by-zero trap is enabled)
• ❌ Undefined instruction
• ❌ Executing code from forbidden memory region (marked as Execute Never, or XN)
• ❌ Violating Memory Protection Unit (MPU) rules
• ❌ Unaligned memory access (if unaligned access trap is enabled)
• ❌ Returning to thread mode with interrupts still active
• ❌ Bus errors (e.g., no response from SDRAM)
• ❌ Calling an SVC instruction from within SVC handler
• ⚙️ Improper debug configurations

Hard Fault Exception

• What is it?
  A HardFault is a serious error that happens when:
  • A configurable fault (like usage, bus, or memory faults) cannot be handled.
  • Something goes wrong while processing another exception.
• Why it occurs?
  1. A lower-priority fault couldn’t be handled (escalation).
  2. Bus error during vector table fetch.
  3. Breakpoint instruction is executed when debugging is off.
  4. SVC instruction executed inside SVC handler.
• Priority: 3rd highest after Reset and NMI (non-maskable interrupt).
• Debugging:
  Use the Hard Fault Status Register (HFSR) to find out what triggered the fault.

MemManage Fault Exception

• Purpose: Handles memory access violations.
• How to Enable:
  Set appropriate bits in System Handler Control and State Register (SHCSR).
• Causes:
  • Unprivileged code (like an RTOS task) accessing privileged memory.
  • Writing to read-only memory regions.
  • Executing code from peripheral memory region (often marked XN).

Bus Fault Exception

• Purpose: Raised when there is a bus error, usually while accessing memory.
• How to Enable:
  Set the appropriate bit in SHCSR.
• Causes:
  • Error during instruction fetch or data read/write.
  • Faulty or invalid memory device (e.g., SDRAM not responding).
  • Accessing protected memory regions.
  • Unprivileged access to restricted peripheral regions.

📝 Note: If a bus fault happens during vector fetch, it’s automatically escalated to a hard fault, even if bus fault is enabled.

Usage Fault Exception

• Purpose: Triggered by incorrect CPU instructions or settings.
• How to Enable:
  Configure the SHCSR register.
• Causes:
  • Running undefined instruction.
  • Using floating point instructions with FPU disabled.
  • Trying to switch to ARM instruction set (Cortex-M only supports Thumb).
  • Returning to thread mode with interrupt still active.
  • Using unaligned memory access (if traps are enabled).
  • Divide by zero (if trap is enabled).
  • Function pointer not aligned to Thumb instruction format.

Summary

Fault Type	Typical Cause	Handler Name
Hard Fault	Unhandled faults, vector fetch errors	HardFault_Handler
MemManage Fault	MPU violations, memory access errors	MemManage_Handler
Bus Fault	Memory bus errors, invalid memory access	BusFault_Handler
Usage Fault	Illegal instructions, divide by zero, etc.	UsageFault_Handler

Final Thoughts

Faults are important safety mechanisms in embedded processors.
They help you detect programming mistakes, interface issues, or system misbehavior early.

By writing proper exception handlers, you can detect, report, and recover from faults — which is essential for building robust and reliable embedded systems.

Detecting Cause of a Fault – Beginner Friendly Guide

Fault Status and Address Information

When a fault (unexpected error) happens in your program, it’s important to know why and where it happened.

To do this, inside the fault handler (a special function that runs when a fault occurs), you can check some special registers that give you more details.

These registers tell:

• What caused the fault
• At which instruction address the fault happened

This is very helpful for debugging your program.

Important Registers for Fault Information

📘 Hard Fault Status Register (HFSR)

• Tells about a Hard Fault (a serious system error).

Configurable Fault Status Register (CFSR)

• This register tells you the specific cause of a:
  • MemManage Fault (memory access error)
  • Bus Fault (bus error during instruction/data access)
  • Usage Fault (illegal operation like divide-by-zero)

Fault Address Information Registers

These registers store the memory addresses where the fault occurred:

• MemManage Fault Address Register
  → Holds the address that caused a memory management fault
• Bus Fault Address Register (BFAR)
  → Holds the address that caused a bus fault

Fault Handling and Analysis

To understand and fix faults, follow these steps:

• ✅ Implement a Hard Fault Handler
  → This is a special function to catch and handle hard faults.
• ✅ Analyze and Print the cause of the hard fault
  → Helps understand what went wrong.
• ✅ Print Register Contents
  → Print values from HFSR, CFSR, etc.
• ✅ Print the Last Stacked Stack Frame
  → Shows the program state at the time of the fault (helpful for debugging).

Error Reporting When Fault Happens

You can make your system more robust by handling faults smartly:

• ✅ Implement a Handler
  → Do something meaningful when a fault happens (like logging or safe shutdown).
• ✅ Implement a User Callback
  → Let the user define a custom error-reporting function.
• 🔁 Reset the Microcontroller/Processor
  → Restart the system if recovery isn’t possible.
• 🧵 In OS Environment
  → The task that caused the fault can be terminated and restarted.
• ✅ Report Register Values
  → Send out values from fault status and fault address registers.
• 🧾 Report Extra Info via Debug Tools
  → Print stack frame, etc., using tools like printf.