ARM Cortex-M Exception Handling: Timing, Interruptibility, and Memory Access Behavior

ARM Cortex-M Exception Handling and Instruction Interruptibility

The ARM Cortex-M series of processors, particularly the Cortex-M3, Cortex-M4, and Cortex-M7, are widely used in embedded systems due to their efficient exception handling mechanisms. However, understanding when and how exceptions are taken into account, especially in the context of instruction execution and memory access, is critical for developing reliable and deterministic systems. This post delves into the intricacies of exception handling in ARM Cortex-M processors, focusing on the timing of exception servicing, interruptibility of instructions, and the behavior of memory access operations during exceptions.

Exception Handling in ARM Cortex-M Processors

Exception handling in ARM Cortex-M processors is a complex topic due to the interplay between the processor’s architecture, the memory system, and the specific implementation details of each Cortex-M variant. Exceptions in ARM Cortex-M processors can be broadly categorized into synchronous and asynchronous exceptions. Synchronous exceptions, such as SVC calls or precise bus faults, are directly tied to the instruction stream and occur at predictable points in the program flow. Asynchronous exceptions, such as interrupts from peripherals or the SysTick timer, can occur at any point in the instruction stream, making their handling more nuanced.

The ARMv7-M architecture, which underpins the Cortex-M3, Cortex-M4, and Cortex-M7, does not explicitly specify the exact timing of exception handling. Instead, this behavior is left to the implementation of the processor. However, the technical reference manuals (TRMs) for these processors provide detailed insights into how exceptions are handled, particularly with respect to the interruptibility of instructions and the completion of memory access operations.

Interruptibility of Instructions During Exception Handling

One of the key aspects of exception handling in ARM Cortex-M processors is the interruptibility of instructions. Not all instructions can be interrupted at any point during their execution. The behavior varies depending on the type of instruction being executed and the specific Cortex-M processor in use.

For Cortex-M3 and Cortex-M4 processors, if the current executing instruction takes multiple clock cycles, it can be interrupted, but only under specific conditions. For example, memory access instructions such as LDM (Load Multiple), STM (Store Multiple), PUSH, and POP can be interrupted, but only after the current data transfer on the AHB (Advanced High-performance Bus) is completed. The state of the interrupted instruction is saved in the ICI (Interruptible-Continuable Instruction) bits of the stacked xPSR (Program Status Register). This allows the instruction to be resumed from the point of interruption once the exception handler completes.

In the case of LDRD (Load Doubleword) and STRD (Store Doubleword) instructions, if only half of the transfer is completed when an exception occurs, the entire instruction is abandoned and restarted after the exception handler finishes. This ensures data integrity but can introduce additional latency in certain scenarios.

For non-memory access instructions that take multiple cycles, such as divide operations or branch instructions, the instruction is abandoned and restarted after the exception handler completes. This behavior ensures that the processor state remains consistent but can impact performance in time-critical applications.

Floating-point instructions, which are supported in Cortex-M4 and Cortex-M7 processors, exhibit different behavior. These instructions can continue execution in parallel with the stacking operation that occurs during exception handling. This allows for more efficient handling of exceptions in applications that heavily utilize floating-point operations.

The Cortex-M7 processor, which is based on the AXI (Advanced eXtensible Interface) bus rather than the AHB bus, introduces additional complexities. The AXI bus allows the processor to issue new transfers before outstanding transfers are completed. This means that the Cortex-M7 can start processing an interrupt request while there are still outstanding transfers on the bus. However, there are restrictions to ensure data integrity. For example, if the instruction is a read from a Device or Strongly Ordered memory region, the current transfer must complete before the exception handling sequence can begin. Similarly, exclusive writes to shareable memory locations must complete before exception handling can proceed.

Memory Access Behavior During Exceptions

Memory access behavior during exceptions is another critical aspect of exception handling in ARM Cortex-M processors. The type of memory being accessed (Normal, Device, or Strongly Ordered) and the specific memory access instruction being executed can significantly impact how exceptions are handled.

For Cortex-M3 and Cortex-M4 processors, memory access instructions such as LDM, STM, PUSH, and POP can be interrupted, but only after the current transfer on the AHB bus is completed. This ensures that data integrity is maintained, but it can introduce delays in exception handling, particularly for instructions that involve multiple data transfers.

In the case of LDRD and STRD instructions, if an exception occurs during the transfer, the entire instruction is abandoned and restarted after the exception handler completes. This behavior is necessary to ensure that the doubleword transfer is completed atomically, but it can introduce additional latency in certain scenarios.

For Cortex-M7 processors, the behavior is more complex due to the use of the AXI bus. The AXI bus allows for more concurrent transfers, but this also means that the processor must ensure that certain memory access operations are completed before exception handling can proceed. For example, reads from Device or Strongly Ordered memory regions must complete before the exception handling sequence can begin. Similarly, exclusive writes to shareable memory locations must complete before exception handling can proceed.

Floating-point memory access instructions, such as VLDM (Vector Load Multiple) and VSTM (Vector Store Multiple), are handled similarly to LDM and STM instructions. The state of the interrupted instruction is saved in the ICI bits of the stacked xPSR, allowing the instruction to be resumed after the exception handler completes.

Synchronous vs. Asynchronous Exceptions

The distinction between synchronous and asynchronous exceptions is crucial for understanding exception handling in ARM Cortex-M processors. Synchronous exceptions, such as SVC calls or precise bus faults, are directly tied to the instruction stream and occur at predictable points in the program flow. When a synchronous exception occurs, the exception handling sequence begins immediately, and the stacked Program Counter (PC) points to the instruction that caused the exception or the next instruction in the sequence.

Asynchronous exceptions, such as interrupts from peripherals or the SysTick timer, can occur at any point in the instruction stream. The point at which the interrupt handling sequence begins is not guaranteed to have a constant relationship with the instruction stream. For example, if an interrupt occurs when the PC is at address X, by the time the stacking operation occurs, the processor may have executed several instructions beyond X, and the stacked PC will reflect this.

This asynchronous nature of interrupts can lead to subtle issues in real-time systems, particularly when dealing with time-critical operations or when precise timing is required. Developers must be aware of this behavior and design their systems accordingly, using techniques such as critical sections or disabling interrupts during critical operations to ensure deterministic behavior.

Practical Implications and Best Practices

Understanding the nuances of exception handling in ARM Cortex-M processors is essential for developing reliable and efficient embedded systems. Here are some practical implications and best practices to consider:

1. Minimize Interrupt Latency: To minimize interrupt latency, avoid using long-running instructions such as LDM, STM, LDRD, and STRD in time-critical sections of code. Instead, use single-load and single-store instructions where possible.

2. Use Critical Sections: When performing operations that must not be interrupted, use critical sections to disable interrupts temporarily. This ensures that the operation completes without being interrupted by an asynchronous exception.

3. Optimize Floating-Point Operations: For applications that heavily utilize floating-point operations, take advantage of the fact that floating-point instructions can continue execution in parallel with exception handling. This can help reduce the impact of exceptions on performance.

4. Understand Memory Attributes: Be aware of the memory attributes (Normal, Device, Strongly Ordered) of the memory regions being accessed. Accesses to Device or Strongly Ordered memory regions can introduce additional delays in exception handling due to the need to complete the current transfer before the exception handling sequence can begin.

5. Leverage the ICI Bits: When using instructions that can be interrupted, such as LDM, STM, PUSH, and POP, ensure that the state of the interrupted instruction is correctly saved in the ICI bits of the stacked xPSR. This allows the instruction to be resumed correctly after the exception handler completes.

6. Test and Validate: Thoroughly test and validate the exception handling behavior in your application, particularly in scenarios involving multiple exceptions, nested interrupts, and complex memory access patterns. This will help identify any potential issues and ensure that the system behaves as