Understanding Fault Types and Causes in Cortex-M3

Follow+Star Public Account Number, don’t miss exciting content

Author | strongerHuang

Public Account | Embedded Column

In our usual projects, we may encounter situations of freezing, and through online debugging or printing messages, we may find out how we entered the HardFault_Handler interrupt.

This “hard fault” is a common type of fault, and there are many causes for hard faults. This article discusses the related content of Fault faults concerning Cortex-M3.

Embedded Column

Types of Faults

There are many types of Fault faults, taking this article’s Cortex-M3 as an example, mainly including:

HardFault: Hard Fault
MemManage: Memory Management Fault
BusFault: Bus Fault
UsageFault: Usage Fault

For example, in the stm32f10x_it.c source code, there is such an interrupt entry:

void HardFault_Handler(void){  /* Go to infinite loop when Hard Fault exception occurs */  while (1)  {  }}
void MemManage_Handler(void){  /* Go to infinite loop when Memory Manage exception occurs */  while (1)  {  }}
void BusFault_Handler(void){  /* Go to infinite loop when Bus Fault exception occurs */  while (1)  {  }}
void UsageFault_Handler(void){  /* Go to infinite loop when Usage Fault exception occurs */  while (1)  {  }}

Embedded Column

Fault Description

Each type of Fault fault must have certain causes. If your code generates a Fault fault interrupt, it indicates that certain parts of the code have caused the Fault fault.

1. HardFault: Hard Fault

From the description in the screenshot, you will find that a hard fault is an “unprogrammable” fault, because if memory management faults, bus faults, and usage faults cannot be executed, they will be treated as hard faults.

For example: a bus fault generated when accessing a vector is also treated as a hard fault. So, you will find that many times the faults encountered are hard faults.

Hard Fault Status Register Description:

From the status register, you will find that the causes of hard faults include the above several types.

2. MemManage: Memory Management Fault

Memory management faults are usually related to the MPU (Memory Protection Unit). I previously shared an article about the MPU titled What is the Cortex-M Core’s MPU?.

Usually, we say that “memory out of bounds” will lead to memory management faults. The specific causes of this fault include:

Accessed an address outside the range set by the MPU
Wrote data to a read-only region
Accessed an address that is only allowed to be accessed at the privileged level while at the user level

Memory Management Fault Status Register:

From the status register, you will find some causes of this fault.

3. BusFault: Bus Fault

Bus faults, as the name suggests, are faults that occur due to problems with bus operations.

For example: when data is being transmitted on the AHB interface, if an error signal (error response) is returned, a bus fault will occur.

Situations that cause bus faults:

Instruction fetching, usually referred to as “prefetch abort”
Data read/write, usually referred to as “data abort”

Actions that trigger bus faults:

PUSH action of the stack at the beginning of interrupt handling, referred to as “stack entry error”
POP action of the stack at the end of interrupt handling, referred to as “stack exit error”

Similarly, you can understand the causes of bus faults through the bus fault status register:

4. UsageFault: Usage Fault

Usage faults are relatively uncommon; this fault usually occurs due to “unaligned access operations”. Other issues that lead to this fault are rare.

For example: executing an undefined instruction, a divisor of 0 (which the compiler will avoid), invalid interrupt returns, etc., are relatively rare situations.

Usage Fault Status Register:

Embedded Column

Dealing with Faults

I wonder if everyone usually has effective measures to avoid these?

Here are a few simple measures to deal with faults:

1. Determine program errors through the values of fault status registers

In the fault interrupt function, read the fault status (described above), for example, for hard faults:

void HardFault_Handler(void){  // Read status register, print status register, determine the cause of the fault  printf("Status x information");  while (1)  {  }}

If you don’t want the system to be in a deadlock state, you can perform a soft reset in the interrupt.

2. Analyze and predict the code in advance

For example: use static code analysis tools to analyze the code and find bugs.

Not long ago, I shared an article: Recommended Static Code Analysis Tools

3. Other diagnostic methods

I previously shared an article titled Tracking Library for Diagnosing HardFault in Cortex-M that can effectively diagnose the “hard faults” discussed in this article.

I’ll stop here for now; there are more and better methods. Feel free to leave comments to supplement.

———— END ————

Reply in the background 『Cortex-M3』『Microcontroller』 to read more related articles.

Welcome to follow my public account, reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.

Welcome to follow my video account:

Click “Read the Original” to see more shares, welcome to share, collect, like, and check.

Leave a Comment Cancel reply