Why Use MPU in RTOS Systems?

First, let me clarify that MPU has many meanings, and there are two common ones:

  • MPU:Memory Protection Unit;
  • MPU:Microprocessor Unit;

Additionally, some may associate it with modules like MPU-6050. So, please do not confuse MPU.

Why Use MPU?

If you develop embedded projects that suffer significant economic losses or major accidents due to memory overflow or memory faults, you will understand why a Memory Protection Unit (MPU) is necessary.

Using an MPU in embedded systems can help detect memory-related bugs early in development, saving more time.

Moreover, fixing bugs or adding features later in the project can reduce the time needed for documentation and testing.

Why Use MPU in RTOS Systems?

In other words, using an MPU can prevent the situation where fixing one bug leads to multiple bugs (0 produces 1, 1 produces countless).

How Does MPU Achieve Memory Protection?

Simply put, it protects all data that is unrelated to the currently executing code.
Take RTOS tasks A and B as an example: Task A and B should not interact with each other’s data, but if there is an error, Task A might accidentally write to some data occasionally used by Task B, which does not affect Task A’s correct operation. However, when Task B tries to use the corrupted data, it may crash unexpectedly.
If MPU is not configured to prevent Task A from writing to Task B’s data, this bug could take a long time for developers to trace. If the bug is small, or if Task B rarely uses that data, it will be difficult to resolve. However, with an MPU, the bug will be detected early.
On some architectures, MPU can even help you detect NULL pointer references because you can set MPU regions to prevent non-privileged code from accessing memory 0x0.
A well-designed set of MPU regions in an application can effectively protect important memory areas to prevent specific issues.
A good example is to prevent buffer overflow by placing a buffer at the end of an MPU region. You can also place task stacks in areas inaccessible to non-privileged code. If done this way, each task must use one of its MPU regions to set its access permissions to its stack.

Benefits of Using MPU

Whether it is an operating system or a bare-metal system, without the ability to prevent malicious access to erroneous memory, the system will have significant security issues and be a minefield for vulnerabilities.
Using a Memory Protection Unit (MPU) has many advantages, allowing you to run in privileged or non-privileged mode, using a set of ‘regions’ to determine whether the currently executing code has access to code and data.
Each region is a contiguous block of memory with a set of permissions for that memory, distinguishing between privileged and non-privileged access. Compared to a subset of non-privileged code, privileged code often has access to most (but not all) memory.
Throughout the system’s runtime, these regions do not have to be the same. MPU regions can be modified based on each task, and each task can have its unique set of regions configured when the task transitions to the running state.
This allows you to set access permissions only for tasks that need code and data, and the embedded operating system with MPU will manage each task’s regions and privilege levels during every context switch.
For example, setting different memory protection regions for two RTOS tasks:
Why Use MPU in RTOS Systems?
Everyone should understand this diagram, right? The Flash and memory regions are protected separately.
Two global protection regions: Flash start, RAM start;
In Flash, one part is accessible only to Task 1, which cannot be accessed by Task 2; simultaneously, in another area of Flash, it is accessible only to Task 2, and cannot be accessed by Task 1. If these two regions are accessed by each other, an MPU fault will occur.
In the RAM region, the same part of the region can be read by one and written by another; if not operated as agreed, it will also produce an MPU fault.

When Not to Use MPU?

There are generally two situations where you can avoid using the MPU feature on the processor:

  • A simple project
  • A project where performance is critical

The first is simple: a very simple application basically does not need to use the MPU, and instead increases the complexity of the system. Without setting memory protection, you can easily find bugs in RAM and peripheral device MPU regions.

The second is for projects with high performance requirements: setting memory protection and stack operations during context switches may affect the real-time performance of the system, leading to system anomalies. This needs to be considered based on the actual project situation whether to use the MPU feature.

Why Use MPU in RTOS Systems?

END

Source: strongerHuang

Copyright belongs to the original author. If there is any infringement, please contact for deletion.
Recommended Reading
Model of Layered Isolation in Embedded Software
He brought the Linux system back to China
Several tricks of state machines in Embedded Systems
→Follow to avoid getting lost←

Leave a Comment

Your email address will not be published. Required fields are marked *