ARM Cortex-M BASEPRI and BASEPRI_MAX Register Access Ordering
The ARM Cortex-M architecture provides a robust mechanism for managing interrupt priorities through the BASEPRI and BASEPRI_MAX registers. These registers are critical for controlling the execution priority of the processor, ensuring that high-priority interrupts are serviced promptly while lower-priority tasks are temporarily suspended. However, the interaction between these registers and the potential need for memory barriers (DMB, DSB, ISB) can be a source of confusion, especially when considering the nuances of instruction reordering and exception handling.
In the context of ARM Cortex-M processors, the BASEPRI register is used to mask interrupts below a certain priority level, while BASEPRI_MAX is a conditional variant that only updates BASEPRI if the new priority level is higher (numerically lower) than the current level. The question arises whether a Data Memory Barrier (DMB) is required between a load (MRS) from BASEPRI and a store (MSR) to BASEPRI_MAX to prevent instruction reordering. The answer lies in understanding the ARM architecture’s handling of special register accesses and the guarantees it provides regarding instruction ordering.
Special register accesses, such as those involving MRS and MSR instructions, are strongly ordered in the ARM Cortex-M architecture. This means that the processor ensures that these instructions are executed in the order they appear in the program, without reordering. This strong ordering eliminates the need for a DMB between a load from BASEPRI and a store to BASEPRI_MAX. However, this does not mean that all scenarios involving these registers are straightforward. The behavior of these registers during exception handling and the visibility of priority changes can introduce complexities that require careful consideration.
Exception Handling and Priority Visibility in ARM Cortex-M
When dealing with exceptions and interrupts, the ARM Cortex-M architecture provides specific guarantees regarding the visibility of changes to the execution priority. These guarantees are crucial for ensuring that the system behaves predictably, especially in real-time applications where timing is critical. The architecture specifies that changes to the execution priority resulting from an MSR instruction are serialized in certain scenarios, particularly when the priority is increased (numerically decreased).
For example, if an MSR instruction increases the execution priority, the change is immediately visible to the instruction stream. This means that any subsequent instructions will see the updated priority level, and any pending interrupts of a lower priority will be masked accordingly. However, if the MSR instruction decreases the execution priority, the architecture only guarantees that the new priority is visible after either executing an Instruction Synchronization Barrier (ISB) or performing an exception entry or return. This distinction is important because it affects how the processor handles interrupts that arrive while the priority is being updated.
Consider a scenario where the last instruction in an Interrupt Service Routine (ISR) is an MSR instruction that sets BASEPRI_MAX to a certain value. If an interrupt of the same or higher priority arrives at the same time, the architecture ensures that the MSR instruction is either completed before the new ISR is entered or is abandoned and restarted after the new ISR completes. This behavior is consistent across different Cortex-M processors, including the Cortex-M4 and Cortex-M7, and is designed to maintain the integrity of the interrupt handling mechanism.
The order of special register accesses is also maintained across exceptions. This means that if an ISR is entered while an MSR instruction is pending, the processor ensures that the MSR instruction is completed before any instructions in the new ISR are executed. This guarantee is essential for maintaining the correct execution priority and ensuring that the system responds appropriately to interrupts.
Implementing Memory Barriers for BASEPRI and BASEPRI_MAX Operations
While the ARM Cortex-M architecture provides strong ordering guarantees for special register accesses, there are scenarios where memory barriers may still be necessary. Memory barriers, such as DMB, DSB, and ISB, are used to enforce ordering constraints on memory operations and ensure that certain operations are completed before others begin. In the context of BASEPRI and BASEPRI_MAX operations, the need for memory barriers arises primarily when the execution priority is decreased, and the new priority level needs to be made visible to the instruction stream.
As mentioned earlier, when an MSR instruction decreases the execution priority, the architecture only guarantees that the new priority is visible after executing an ISB or performing an exception entry or return. This means that if the code following the MSR instruction relies on the new priority level, an ISB should be inserted to ensure that the change is visible. For example, if an MSR instruction is used to lower the execution priority, and the subsequent code includes a Supervisor Call (SVC) instruction, an ISB should be placed between the MSR and SVC instructions. This ensures that the SVC instruction is executed with the correct priority level and is not inadvertently blocked due to the priority change not being visible yet.
The following table summarizes the scenarios where memory barriers may be required when working with BASEPRI and BASEPRI_MAX:
| Scenario | Memory Barrier Required | Explanation |
|---|---|---|
| MSR increases execution priority | None | The change is immediately visible to the instruction stream. |
| MSR decreases execution priority | ISB | The new priority is only visible after an ISB or exception entry/return. |
| MRS followed by MSR or vice versa | None | Special register accesses are strongly ordered. |
| MSR followed by SVC | ISB | Ensures the SVC is executed with the correct priority level. |
In addition to the ISB, other memory barriers such as DMB and DSB may be required in specific scenarios, particularly when dealing with memory accesses that need to be ordered relative to special register operations. For example, if a memory access needs to be completed before a change to BASEPRI takes effect, a DMB or DSB may be necessary to enforce the ordering constraint.
In conclusion, while the ARM Cortex-M architecture provides strong ordering guarantees for special register accesses, understanding the nuances of exception handling and priority visibility is essential for implementing correct and efficient code. Memory barriers play a crucial role in ensuring that changes to the execution priority are visible at the right time, particularly when the priority is decreased. By carefully considering the scenarios where memory barriers are required, developers can ensure that their systems behave predictably and respond appropriately to interrupts and exceptions.
