MPU for RTOS task isolation in ARM Architecture - Time & Space Complexity
When using an MPU (Memory Protection Unit) for RTOS task isolation, it's important to understand how the time to switch tasks and check memory access grows as the number of tasks or memory regions increases.
We want to know how the system's work changes when more tasks or memory rules are added.
Analyze the time complexity of this simplified ARM MPU configuration code for task switching.
// Simplified MPU setup for a task
MOV R0, #NUM_REGIONS // Number of MPU regions
MOV R1, #0 // Region index
setup_loop:
CMP R1, R0 // Compare index with total regions
BGE setup_done // If done, exit loop
LDR R2, [R3, R1, LSL #2] // Load region base address
STR R2, MPU_RBAR // Set MPU region base
LDR R2, [R4, R1, LSL #2] // Load region attributes
STR R2, MPU_RASR // Set MPU region attributes
ADD R1, R1, #1 // Increment region index
B setup_loop // Repeat for next region
setup_done:
BX LR // Return from function
This code sets up MPU regions for a task by looping through each region and configuring it.
Look for repeated steps that take most time.
- Primary operation: Loop that configures each MPU region.
- How many times: Once for each region, so the number of regions (n).
As the number of MPU regions increases, the time to set them up grows in a straight line.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 region setups |
| 100 | About 100 region setups |
| 1000 | About 1000 region setups |
Pattern observation: Doubling the number of regions roughly doubles the work.
Time Complexity: O(n)
This means the time to configure MPU regions grows directly with the number of regions.
[X] Wrong: "Setting up MPU regions happens instantly regardless of how many regions there are."
[OK] Correct: Each region requires separate configuration steps, so more regions mean more work and more time.
Understanding how MPU setup time grows helps you explain system responsiveness and task switching delays in real embedded systems.
What if the MPU hardware allowed configuring all regions in parallel? How would the time complexity change?
Practice
Solution
Step 1: Understand MPU role in RTOS
The MPU is designed to control which memory areas a task can access, preventing interference between tasks.Step 2: Compare MPU functions with other options
Increasing CPU speed, managing power, or handling I/O are not MPU functions.Final Answer:
To isolate tasks by controlling their memory access -> Option AQuick Check:
MPU isolates tasks = To isolate tasks by controlling their memory access [OK]
- Confusing MPU with CPU speed control
- Thinking MPU manages power or I/O
- Assuming MPU schedules tasks
Solution
Step 1: Identify MPU region setup requirements
MPU regions require a base address and size to define memory boundaries.Step 2: Determine correct access permissions for stack
The stack needs read/write access, not execute-only or disabled MPU.Final Answer:
Set region base address and size, then enable read/write access -> Option AQuick Check:
Stack needs base, size, read/write access = Set region base address and size, then enable read/write access [OK]
- Omitting base address when defining region
- Setting execute-only for stack
- Disabling MPU for stack memory
Task1: MPU region base=0x20000000, size=32KB, RW access
Task2: MPU region base=0x20008000, size=32KB, RW access
What happens if Task1 tries to access address 0x20009000?
Solution
Step 1: Calculate Task1's memory range
Task1's region starts at 0x20000000 and covers 32KB (0x8000 bytes), so it ends at 0x20007FFF.Step 2: Check if 0x20009000 is inside Task1's region
Address 0x20009000 is greater than 0x20007FFF, so it is outside Task1's allowed memory.Final Answer:
Access denied because address is outside Task1's region -> Option DQuick Check:
Address outside region = Access denied = Access denied because address is outside Task1's region [OK]
- Assuming overlapping regions allow access
- Miscalculating region size boundaries
- Ignoring MPU enforcement
Solution
Step 1: Understand MPU execute permission
Enabling execute permission on data memory allows instructions to run from that area.Step 2: Identify security risk
This can lead to security risks like code injection or unintended execution.Final Answer:
It may allow code execution from data memory, risking security -> Option CQuick Check:
Execute permission on data = security risk = It may allow code execution from data memory, risking security [OK]
- Thinking execute permission affects reading data
- Assuming MPU disables task on wrong permissions
- Confusing stack size with MPU permissions
Solution
Step 1: Understand shared peripheral access
Peripheral registers must be accessible by tasks that use them, typically with read/write permissions.Step 2: Configure MPU regions for safe sharing
Creating an MPU region with read/write access for the peripheral and sharing it among tasks allows controlled access without disabling MPU.Final Answer:
Create an MPU region for the peripheral with read/write access and share it among tasks -> Option BQuick Check:
Shared peripheral needs shared RW MPU region = Create an MPU region for the peripheral with read/write access and share it among tasks [OK]
- Disabling MPU instead of configuring regions
- Setting execute-only permission on peripherals
- Blocking access by setting no-access
Ready to prove it?
Pass the test and this pattern moves unknown
