ARM Architecture: Registers, Modes, and Privilege Levels

1. The Programmer's Model: A High-Level View

Before we dissect each component, let's get a unified overview of how these concepts fit together. The Cortex-M architecture provides a consistent programmer's model that balances simplicity with the features needed for robust and secure systems.

To start, watch this brief segment from an Arm official video. It introduces the core registers and the concepts of execution modes and privilege levels.

As the video explained, the processor's state is defined by three key aspects at any point in time:

• The values in its registers.
• The execution mode it is in (Thread or Handler).
• The privilege level at which it is operating (Privileged or Unprivileged).

Let's explore each of these in more detail.

2. The ARM Cortex-M Register Set

When you debug using Trace32, the register window is your primary view into the processor's soul. Understanding what each register does is crucial. We can group them into three categories.

To guide this section, we'll refer to an excellent technical article from Memfault, which provides the level of detail you'll appreciate.

General-Purpose Registers (GPRs): R0-R12

• R0-R3: These are primarily used as argument/scratch registers. According to the ARM Procedure Call Standard (AAPCS), which we'll cover in a future lesson, they are used to pass the first four arguments to a function and to return a result from a function.
• R4-R11: These are "callee-saved" variable registers. A function must preserve the values of these registers for its caller.
• R12 (IP): The Intra-Procedure-call scratch register. It's a special scratch register that can be used by the linker for veneers (small code stubs to handle long branches), but is otherwise a general-purpose scratch register.

Special-Purpose Core Registers: R13-R15

These registers have roles assigned by the hardware itself.

• R13 (SP - Stack Pointer): This register holds the current address of the top of the stack. A key feature of Cortex-M is that the stack pointer is banked. This means there are two physical stack pointer registers:

  • Main Stack Pointer (MSP): The default stack pointer, used by the OS kernel and exception handlers.
  • Process Stack Pointer (PSP): Used by user application code or RTOS tasks.
    This hardware separation is fundamental for RTOS design, as it provides a clean way to isolate the kernel's stack from each task's stack. The processor automatically uses the MSP when it enters an exception handler.

• R14 (LR - Link Register): When a function is called using a Branch with Link (BL or BLX) instruction, the hardware automatically saves the return address (the address of the next instruction) into the LR. It is also used in exceptions to hold a special EXC_RETURN value that tells the processor how to return from the exception.

• R15 (PC - Program Counter): This always holds the address of the next instruction to be fetched from memory. Directly writing to the PC causes a branch.

Special Registers

Beyond the core registers, a set of special-purpose registers configures and reports on the processor's state. They are accessed using the special MSR (Move to Special Register) and MRS (Move from Special Register) instructions. The most important one for our current topic is the CONTROL register.

The CONTROL register has two critical bits for managing state:

• nPRIV (bit 0): Controls the privilege level in Thread mode.
  • 0: Thread mode is Privileged.
  • 1: Thread mode is Unprivileged.
• SPSEL (bit 1): Selects the active stack pointer in Thread mode.
  • 0: Use the Main Stack Pointer (MSP).
  • 1: Use the Process Stack Pointer (PSP).

In Handler mode, the processor ignores these bits and always operates as Privileged, using the MSP.

3. Processor Modes and Privilege Levels

Now, let's formalize the concepts of modes and levels. An excellent article from EmbeddedPrep breaks this down clearly.

Let's synthesize this information with the state diagram below.

Here’s how to interpret the diagram and the concepts from the article:

• Reset: After a reset, the processor starts in Privileged Thread Mode, using the MSP. This allows the startup code to have full control to initialize the hardware (clocks, memory, etc.).
• Thread Mode: This is the processor's normal operating state. It executes your main() function and general application logic. It can be:
  • Privileged: Full access to all memory and special registers. Ideal for an RTOS kernel or bare-metal system.
  • Unprivileged: Access is restricted. For example, it cannot change interrupt masks or access certain system control registers. This is perfect for sandboxing user tasks in an RTOS.
• Handler Mode: The processor automatically enters Handler Mode whenever an exception (like an interrupt or a system fault) occurs.
  • Handler Mode is always Privileged. This is a critical security and stability feature, ensuring that an interrupt service routine (ISR) has the necessary rights to manage the system, regardless of what the application code was doing.
• Transitions:
  • Privileged Thread -> Unprivileged Thread: This is a software-controlled transition. You do it by setting the nPRIV bit in the CONTROL register, as we saw earlier.
  • Any State -> Privileged Handler: An exception occurs. The hardware automatically saves key registers onto the current stack, loads the PC with the address of the handler, and enters Privileged Handler mode.
  • Privileged Handler -> Any Thread State: This occurs upon an exception return. The special EXC_RETURN value loaded into the LR during the exception tells the processor which mode and stack pointer to return to.
  • Unprivileged Thread -> Privileged Thread: This transition cannot be made directly. An unprivileged application cannot simply grant itself more privileges. It must trigger an exception, such as a Supervisor Call (SVC instruction), to enter Handler Mode. The privileged SVC handler can then perform the requested action on behalf of the application or choose to return to Privileged Thread mode. This is the fundamental mechanism for system calls in an OS.

4. A Practical Code Example

Theory is essential, but seeing it in action solidifies the concepts. The same EmbeddedPrep article provides a full bare-metal code example that demonstrates these transitions.

The code demonstrates the following flow, which is a textbook example of how privilege levels are used:

1. Start: main() begins in Privileged Thread Mode. It has full access to configure GPIOs.
2. Demotion: The code explicitly switches to Unprivileged Thread Mode by writing to the CONTROL register using inline assembly. Now, it has restricted access.
3. System Call: The code triggers a software interrupt, which is a form of exception. The CPU automatically transitions to Privileged Handler Mode to execute the EXTI3_IRQHandler.
4. Return: After the ISR finishes, the CPU returns to the main loop, which is still in Unprivileged Thread Mode.

This example perfectly illustrates the secure boundary between application code and system/driver code, which is a cornerstone of reliable embedded systems and a direct application of your ISO 26262 experience at the hardware level.

Interview Corner

Be prepared to discuss these topics clearly and concisely.

1. "Can you describe the core registers of an ARM Cortex-M processor and their primary roles?"

   • Hint: Group your answer: GPRs (R0-R12 for arguments and variables), and Special-Purpose Core Registers (SP, LR, PC). Mention the banked stack pointers (MSP/PSP) and their use with an RTOS.

2. "What is the difference between Thread mode and Handler mode?"

   • Hint: Thread mode is for normal execution; Handler mode is for exceptions/interrupts. Handler mode is always privileged. The transition to Handler mode is automatic on an exception.

3. "Explain the concept of privileged versus unprivileged execution. How does an RTOS leverage this feature?"

   • Hint: Privileged mode has full system access; unprivileged is restricted. This creates a secure sandbox. An RTOS runs its kernel in privileged mode to manage hardware and tasks, while running user application tasks in unprivileged mode to prevent them from interfering with the kernel or each other.

4. "How does a processor transition from an unprivileged level to a privileged one?"

   • Hint: It cannot do so directly. It must trigger an exception (like an interrupt or an SVC instruction). This causes an automatic, secure transition into privileged Handler mode.

Conclusion

Great job. We've moved from the high-level architecture of ARM families down into the core's internal state machine. This is the foundation upon which all low-level software is built.

Key Takeaways:

• The Cortex-M programmer's model consists of 16 core registers, including special-purpose SP, LR, and PC.
• The Stack Pointer (SP) is banked, with a Main Stack Pointer (MSP) for the kernel/handlers and a Process Stack Pointer (PSP) for user tasks.
• The processor operates in one of two modes: Thread Mode for normal code and Handler Mode for exceptions.
• Execution occurs at one of two levels: Privileged (full access) or Unprivileged (restricted). Handler mode is always privileged.
• Transitions between levels are tightly controlled by the hardware, forming the basis for secure system calls in an RTOS. The CONTROL special register is key to software management of these states.

Next Lesson Preview:

Now that we understand the processor's state, the next logical step is to understand how it executes instructions. In the next lesson, we will explore the ARM instruction pipeline and its impact on execution timing. This will help you understand why certain instruction sequences can be faster than others and introduce concepts like data hazards and branch prediction, which are important for performance optimization.