Context Switching: Mechanics and Stack Management

1. The Problem: Saving and Restoring a Task's "Mind"

Before we dive into the hardware specifics, let's build a strong conceptual model. A running task's entire state of execution—its "mind," so to speak—is contained within the CPU's registers at any given moment. To switch tasks, the OS must save the current task's state to memory and load the state of the next task from memory.

But how can an OS save the state of a task that is currently running? The very act of saving the state would seem to alter it. This is a classic chicken-and-egg problem that cannot be solved by software alone.

The following video provides an excellent high-level overview of why hardware assistance is essential for this process.

2. Processor State on the ARM Cortex-M

As the video explained, the "context" is the set of CPU registers. On an ARM Cortex-M processor, this context can be broken down into three main groups. A deep understanding of these registers is fundamental.

To summarize the key takeaways from that reading:

• Core Registers: General-purpose registers r0-r12, Stack Pointer (SP, r13), Link Register (LR, r14), and Program Counter (PC, r15).
• Special Registers: These control the processor's state. The xPSR (Program Status Register) holds flags, the CONTROL register selects the stack pointer, and PRIMASK/BASEPRI manage interrupt masking.
• Stack Pointers: The Cortex-M has two stack pointers. The Main Stack Pointer (MSP) is used by the OS kernel and exception handlers. The Process Stack Pointer (PSP) is typically used by user tasks. This provides a crucial layer of separation and protection.
• Floating-Point Registers: If an FPU is present (like in Cortex-M4F or M7F), there's an additional set of registers (s0-s31 and FPSCR) that are part of the context.

3. The Context Switch Mechanism: An Orchestrated Dance

A context switch is a dance between hardware and software, typically orchestrated within a special interrupt handler. On ARM Cortex-M, this is almost universally done in the PendSV (Pendable Service Call) exception.

Here's the sequence of events:

1. The Trigger: An event occurs that requires a context switch. Often, this is the SysTick timer interrupt, which an RTOS uses for time-slicing. The SysTick handler runs, calls the scheduler, and if the scheduler decides a higher-priority task should run, it pends the PendSV interrupt.
2. The Exception Entry (Hardware): When the PendSV interrupt is taken, the CPU hardware automatically performs the first part of the context save. It pushes a basic stack frame containing 8 registers (r0-r3, r12, LR, PC, xPSR) onto the current task's stack (the PSP).
3. The Context Save (Software): The PendSV_Handler begins to execute. Its job is to save the rest of the context. It pushes the remaining callee-saved registers (r4-r11) onto the same stack (the PSP).
4. Saving the Stack Pointer: The handler reads the final value of the PSP and saves it into the current task's Task Control Block (TCB), a data structure the RTOS uses to store all information about a task.
5. Restoring the Next Context: The handler gets the TCB of the next task to run, retrieves its saved stack pointer, and loads it into the PSP.
6. The Context Restore (Software): The handler pops the callee-saved registers (r4-r11) from the new task's stack.
7. The Exception Exit (Hardware): The handler executes a special return instruction (BX LR) using a magic EXC_RETURN value that was placed in the Link Register upon exception entry. This value tells the processor to:
   • Un-stack the basic frame (r0-r3, r12, etc.) from the PSP.
   • Resume execution at the new task's saved Program Counter.

This diagram provides a great visual summary of the process.

Now, let's see how this is implemented in practice. We'll look at it from two perspectives: building it from scratch and analyzing a real-world example in FreeRTOS.

Building the PendSV Handler

This video shows how to implement a PendSV_Handler in assembly, which is required for direct manipulation of the stack and core registers.

Analyzing the FreeRTOS PendSV Handler

Now, let's cement this knowledge by stepping through the official FreeRTOS implementation using a debugger.

4. The FPU Complication: Extended Stack Frames and Lazy Stacking

If your processor has a Floating-Point Unit (FPU), the context is larger. Saving and restoring an extra 33 registers (s0-s31 and FPSCR) on every single context switch would introduce significant overhead. The ARM architecture has a clever optimization for this called lazy stacking.

• Standard Behavior: When an exception occurs on a system with an FPU, the hardware saves an extended stack frame, which includes space for the basic registers and the FPU registers.
• Lazy Stacking Optimization: The hardware only reserves space for the FPU registers on the stack. It defers the actual saving of the FPU registers. Only if the interrupt handler itself executes an FPU instruction will the hardware pause, save the original task's FPU state into the reserved space, and then continue. If the ISR never uses the FPU, the expensive save/restore operation is skipped entirely, saving valuable cycles.

The FreeRTOS PendSV_Handler explicitly checks if the FPU was in use and needs saving:

" tst r14, #0x10 \n " // Test bit 4 of EXC_RETURN
" it eq \n "          // If result is zero (FPU was used)
" vstmdbeq r0!, {s16-s31} \n " // Save the other FPU regs

This is a key detail that top-tier interviewers look for, as it shows you've considered performance optimizations.

Conclusion

You now have a detailed, low-level understanding of one of the most fundamental RTOS operations. In an interview, being able to articulate this process with precision will set you apart.

Key Takeaways:

• A context switch is a hardware-software collaboration, initiated by an OS scheduler and executed in a low-priority interrupt handler like PendSV.
• What is saved: The entire processor context, including general-purpose registers (r0-r15), special registers (xPSR), and FPU registers if applicable.
• How it's managed:
  1. Hardware automatically saves a basic frame (r0-r3, r12, LR, PC, xPSR) on exception entry.
  2. Software (in PendSV_Handler) manually saves the remaining callee-saved registers (r4-r11 and FPU registers s16-s31).
  3. The stack pointer is managed using the PSP for tasks and MSP for the kernel/exceptions. The final PSP value is stored in the task's TCB.
  4. A special EXC_RETURN value in LR orchestrates the hardware-assisted return to the new context.
• Advanced Topic (FPU): Lazy stacking is a key performance optimization that avoids unnecessarily saving the FPU context, reducing interrupt latency.

Preview of the Next Lesson:

Now that we know how the RTOS switches between tasks, a new problem emerges: what happens when two tasks need to access the same peripheral or piece of memory? If they are preempted at the wrong time, data can be corrupted. In our next lesson, we will tackle this challenge by exploring the essential tools for synchronization: mutexes, semaphores, and spinlocks.