Controlling Critical Sections with PRIMASK and BASEPRI

1. The Problem: Race Conditions and Non-Atomic Operations

In programming, an atomic operation is one that is guaranteed to complete without being interrupted. A single assembly instruction, like LDR R0, [R1], is atomic. However, a single line of C code often is not.

Consider this seemingly simple C statement:

uint16_t g_counter = 0;
// in main loop or a task
g_counter++;

A C compiler might translate g_counter++ into three distinct assembly instructions for a 32-bit ARM processor:

1. LDR (Load): Load the current value of g_counter from memory into a core register.
2. ADD (Add): Increment the value in the register.
3. STR (Store): Store the new value from the register back into the memory location of g_counter.

Now, imagine an ISR also increments this counter:
void Timer_ISR(void) { g_counter++; }

What happens if the timer interrupt occurs right after the main loop has executed the LDR but before it has executed the STR?

1. Main Code: LDR loads the value of g_counter (e.g., 100) into a register (R0).
2. ---> INTERRUPT OCCURS <--- The processor saves context and jumps to Timer_ISR.
3. ISR: The ISR executes its own LDR (loads 100), ADD (increments to 101), and STR (stores 101 back to g_counter). g_counter is now 101.
4. ---> ISR RETURNS <--- The processor restores context and resumes the main code.
5. Main Code: It continues from where it left off. It performs the ADD on its register R0 (which still holds the old value, 100), making it 101.
6. Main Code: It performs the STR, storing 101 back to g_counter.

The counter was incremented twice, but its final value is 101, not 102. An update has been lost. This is a classic race condition. To prevent this, the LDR-ADD-STR sequence must be made atomic. This is achieved by creating a critical section.

2. The Solution: Critical Sections via Interrupt Masking

A critical section is a segment of code that must be executed without being preempted to ensure data integrity. The most direct way to enforce this is to temporarily disable interrupts before entering the critical section and re-enable them immediately after exiting.

This ensures that once your code begins the LDR-ADD-STR sequence, no ISR can interrupt it, guaranteeing the operation's atomicity relative to the interrupt sources.

The ARM Cortex-M architecture provides two primary mechanisms for this: the PRIMASK register and the BASEPRI register.

3. The "Sledgehammer": Global Interrupt Disable with PRIMASK

The simplest approach is to disable all configurable interrupts globally. This is done using the PRIMASK register. It contains a single bit, the I bit, which acts as a master switch.

• PRIMASK[0] = 1: All interrupts with configurable priority are disabled (masked).
• PRIMASK[0] = 0: Interrupts are enabled.

While you can modify this register directly, it's standard practice to use assembly instructions or CMSIS core functions designed for this purpose.

As the article shows, you have two main ways to control PRIMASK in your code:

1. Inline Assembly:

__asm volatile ("cpsid i");  // disable interrupts (set PRIMASK)
// ... critical section ...
__asm volatile ("cpsie i");  // enable interrupts (clear PRIMASK)

2. CMSIS Functions (Recommended): The Cortex Microcontroller Software Interface Standard (CMSIS) provides a portable hardware abstraction layer. These functions are the standard, toolchain-independent way to control the core.

#include "core_cm4.h" // Or your specific core header

__disable_irq(); // Sets PRIMASK bit
// ... critical section ...
__enable_irq();  // Clears PRIMASK bit

Our previous corrupted counter example can now be fixed:

void safely_increment_counter() {
    __disable_irq();
    g_counter++;
    __enable_irq();
}

Drawback: Using PRIMASK is a blunt instrument. It blocks every interrupt, including high-priority, time-sensitive ones like a motor control timer or emergency stop signal. This increases the interrupt latency for all sources. For this reason, critical sections protected this way must be kept as short as possible.

4. The "Scalpel": Priority-Based Masking with BASEPRI

For more sophisticated control, ARM Cortex-M3, M4, and M7 cores (but not M0/M0+) offer the BASEPRI register. This allows you to disable interrupts only up to a certain priority level, leaving higher-priority interrupts unaffected.

• BASEPRI is set to a priority value (e.g., 5).
• Any interrupt with a priority numerically greater than or equal to BASEPRI's value is blocked. (Remember, on ARM, a higher number means lower urgency).
• Interrupts with a priority numerically less than BASEPRI's value (i.e., higher urgency) can still preempt the code.

The key CMSIS function for this is __set_BASEPRI(). Unlike the simple enable/disable for PRIMASK, using BASEPRI requires a careful save-and-restore sequence to avoid unintended side effects.

#include "core_cm4.h"

#define UART_INTERRUPT_PRIORITY 5 // Example priority

void safely_access_uart_buffer() {
    uint32_t prev_basepri;

    // 1. Save current BASEPRI value
    prev_basepri = __get_BASEPRI();

    // 2. Set BASEPRI to block UART interrupt and lower-priority interrupts
    // Note: Priority values must be shifted to align with the register's format.
    __set_BASEPRI(UART_INTERRUPT_PRIORITY << (8 - __NVIC_PRIO_BITS));

    // ... critical section accessing a buffer shared with the UART ISR ...

    // 3. Restore the original BASEPRI value
    __set_BASEPRI(prev_basepri);
}

Note: BASEPRI cannot be used to disable interrupts with the highest priority (priority 0). For that, you must still use PRIMASK.

This selective masking is a powerful feature for real-time systems. It allows you to protect a resource from a low-priority logging interrupt without delaying a critical, high-priority motor control interrupt.

5. Critical Sections in a FreeRTOS Environment

Given your background and the job description, understanding how this low-level hardware is used by an RTOS like FreeRTOS is essential. An RTOS must protect its own internal data structures (like task lists and scheduler states) using critical sections. FreeRTOS provides its own API for this, which intelligently uses PRIMASK or BASEPRI under the hood.

Here's the practical summary for your interview preparation:

• User API: You use taskENTER_CRITICAL() and taskEXIT_CRITICAL() to protect your own application's shared data.
• Core-Specific Implementation:
  • On Cortex-M0/M0+, which lack BASEPRI, FreeRTOS has no choice but to use __disable_irq(). All interrupts are blocked during kernel critical sections.
  • On Cortex-M3/M4/M7, FreeRTOS uses __set_BASEPRI().
• The configMAX_SYSCALL_INTERRUPT_PRIORITY Setting:
  • This crucial setting in FreeRTOSConfig.h defines the priority value that FreeRTOS writes into BASEPRI when it enters a critical section.
  • This creates a powerful interrupt partitioning model:
    • ISRs with priority below configMAX_SYSCALL_INTERRUPT_PRIORITY (higher numeric value): These ISRs are allowed to call FreeRTOS API functions (e.g., xQueueSendFromISR). However, they will be blocked by the RTOS kernel's critical sections.
    • ISRs with priority above configMAX_SYSCALL_INTERRUPT_PRIORITY (lower numeric value): These are "real-time" ISRs. They are never blocked by the RTOS kernel, ensuring the lowest possible latency. The trade-off is that they cannot call any FreeRTOS API functions.

This design is a key reason why FreeRTOS on Cortex-M4/M7 can provide excellent real-time responsiveness while still offering a rich set of OS features.

Interview Preparation

• Question: "What is a race condition? Give me an embedded systems example."

  • Your Answer: "A race condition occurs when the outcome of a system depends on the unpredictable timing of concurrent operations. A classic example is a 16-bit or 32-bit global variable, like a counter, that is incremented in both a main application task and an ISR. Since the increment operation (variable++) is not atomic at the machine level—it's a load, modify, store sequence—an interrupt occurring between the load and store can cause one of the increments to be lost."

• Question: "How would you prevent that race condition? What tools does the ARM Cortex-M core provide?"

  • Your Answer: "By implementing a critical section, which ensures the non-atomic operation completes without being interrupted. The Cortex-M core provides two main registers for this. The first is PRIMASK, which acts as a global switch to disable all configurable interrupts. The second, on M3/M4/M7 cores, is BASEPRI, which allows for more granular control by disabling interrupts only up to a specific priority level."

• Question: "What are the trade-offs between using PRIMASK and BASEPRI?"

  • Your Answer: "PRIMASK is simple but acts like a sledgehammer, disabling all interrupts and potentially increasing the latency for high-priority, real-time events. It's suitable for very short critical sections or on Cortex-M0 cores that lack BASEPRI. BASEPRI is a scalpel, allowing you to block lower-priority interrupts (like a UART) while leaving high-priority ones (like a safety-critical ADC) enabled. This minimizes interrupt latency but requires more careful management of interrupt priorities."

• Question (Advanced): "How does an RTOS like FreeRTOS handle critical sections on a Cortex-M4, and what does configMAX_SYSCALL_INTERRUPT_PRIORITY do?"

  • Your Answer: "FreeRTOS on a Cortex-M4 cleverly uses the BASEPRI register. When the kernel enters a critical section, it doesn't disable all interrupts. Instead, it writes the value of configMAX_SYSCALL_INTERRUPT_PRIORITY to BASEPRI. This creates a priority ceiling. Any ISR with a priority numerically lower than this value (higher urgency) is not affected by the RTOS kernel at all, guaranteeing low latency. ISRs with a priority at or below this ceiling are temporarily blocked but are permitted to call RTOS API functions, like those ending in ...FromISR."

Conclusion

Today you've learned one of the most fundamental concepts in concurrent embedded programming: protecting shared resources. You now understand how a simple C statement can lead to data corruption and how to use the core's hardware features to prevent it.

Key Takeaways:

• Non-atomic operations on shared data can lead to race conditions.
• Critical sections are code segments that must execute without preemption to ensure atomicity.
• PRIMASK provides a global interrupt disable, which is simple but impacts latency for all interrupts.
• BASEPRI (on Cortex-M3+) provides a priority-based interrupt mask, allowing high-priority ISRs to remain responsive.
• RTOSs like FreeRTOS build on these hardware features to provide safe and efficient multitasking, using BASEPRI to partition interrupts into real-time and non-real-time groups.

Next Lesson Preview:
We've repeatedly mentioned the term "interrupt latency." Disabling interrupts, even for a short time, increases it. In our next lesson, we will formally define interrupt latency, break down all the hardware and software factors that contribute to it, and explore advanced ARM core features like tail-chaining and late-arriving interrupts that are specifically designed to minimize this latency and optimize interrupt handling performance.