Understanding Cortex-M3 Fault Exceptions

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

Author | strongerHuang

WeChat Public Account | strongerHuang

Many friends encounter the HardFault_Handler situation while learning or developing STM32.

So, how many people have seriously analyzed the Fault type exceptions?

Below, I will explain the content of these exception interrupts in conjunction with STM32F1 (Cortex-M3 core).

1Cortex-M3 Exceptions

Speaking of Fault, we must mention the exceptions of Cortex-M3.

Cortex-M3 is equipped with an exception response system in its core, supporting numerous system exceptions and external interrupts.

List of CM3 exceptions:

The priority of these exception interrupts varies; some are fixed while others can be configured via software, such as UART transmission interrupts, DMA interrupts, etc.

Everyone should be familiar with this list, as you will see these exceptions in the startup code of STM32 and the interrupt code.

For example, in the stm32f10x_it.c file, you can see Fault exceptions like HardFault_Handler.

Vector Table

When an exception occurs and needs to be responded to, CM3 needs to locate the entry address of its handler. These entry addresses are stored in the “(exception) vector table.” Our interrupt functions correspond to an entry address.

2Fault Error Exceptions

InCortex-M3, there are several types of Fault error exceptions:

• BusFault

• MemManageFault

• UsageFault

• HardFault

1. BusFault

When data is being transmitted on the AHB interface, if an error signal is returned, a bus error occurs.

Situations that can trigger a bus error:

• Instruction fetch, commonly referred to as “prefetch abort”
• Data read/write, commonly referred to as “data abort”

Actions that can trigger a bus exception:

• PUSH action on the stack at the start of interrupt handling, known as “stack entry error”
• POP action on the stack at the end of interrupt handling, known as “stack exit error”
• Reading the vector after the processor starts the interrupt handling sequence. This is a rare special case classified as a hard error.

Causes of bus errors:

• Attempting to access an invalid memory region. Common when accessing an address with no corresponding memory.
• The device is not ready to transfer data. For example, attempting to access SDRAM before initializing the SDRAM controller.
• When attempting to initiate a data transfer, the size of the transfer is not supported by the target device. For example, a device only accepts word-sized data but is attempted to be sent byte-sized data.
• For some reason, the device cannot accept data transfer. For example, some devices only allow access at privileged levels, but the current level is user level.

2. MemManageFault

Memory management errors are often related to the MPU (Memory Protection Unit), and the causes are often due to an access violating the protection policies set by the MPU.

Common causes:

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

There is a passage in the CM3 manual:

After a MemManage fault occurs, if its service routine is enabled, the service routine will be executed. If other higher priority exceptions occur simultaneously, those higher priority exceptions will be prioritized, and the MemManage exception will be suspended.

If the processor is already handling the same or higher priority exception, or if the MemManage fault service routine is disabled, it will escalate to a hard fault, and the hard fault service routine will be executed.

When our program accesses memory out of bounds, we will find that the program enters the HardFault_Handler interrupt service routine. This can be understood in conjunction with the above passage.

3. UsageFault

Causes of usage faults:

• Executed an undefined instruction
• Executed co-processor instructions (Cortex-M3 does not support co-processors, but can use the fault exception mechanism to simulate co-processor functionality, making it easier to port between other Cortex processors)
• Attempted to enter ARM state (since CM3 does not support ARM state, usage faults will occur during the switch. Software can use this mechanism to test whether a processor supports ARM state)
• Invalid interrupt return (LR contains an invalid/error value)
• When using multiple load/store instructions, the address is misaligned. Additionally, by setting the corresponding control bits of the NVIC, usage faults can also occur in the following situations:
• Division by zero
• Any unaligned access

4. HardFault

HardFault is the result of the above three types of errors “escalating.” If the service routines for these fault errors cannot be executed, they will escalate to a hard fault.

In the NVIC, there is a HardFault status register (HFSR) that indicates the cause of the HardFault.

Status Register (HFSR):

3How to Respond to Fault Error Exceptions

During software development, we can determine program errors based on the values of various fault status registers and correct them. Below are common causes of various faults and response strategies.

MemManage fault status register provides information:

Bus fault status register provides information:

Usage fault status register provides information:

Hard fault status register provides information:

Common methods to respond to Fault errors:

1. Recovery: In some cases, there is still hope to resolve the issue causing the fault. For example, if the program tries to access a co-processor, this can be resolved using a software simulator for the co-processor—though at the cost of performance.

2. Abort related tasks: If the system runs an RTOS, related tasks can be terminated or restarted.

3. Reset: This is also a last resort. By setting the VECTRESET bit in the NVIC “Application Interrupt and Reset Control Register,” only the processor core is reset without resetting other on-chip facilities. Depending on the chip’s reset design, some CM3 chips can use the SYSRESETREQ bit of this register to reset. This reset limited to the core will not reset other system components.

Of course, after all this, we still need to start from the root cause, maintain good programming habits and follow necessary programming standards.

———— END ————

Reply to the background with 『STM32』『Cortex-M3』 to read more related articles.

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

Welcome to follow my video account:

Click “Read Original” to see more shares.