Home >

Demystifying Memory Protection Units (MPUs)

Jean Labrosse - Watch Now - Duration: 52:55

A Memory Protection Unit (MPU) is hardware that improves the safety and security of an embedded device by only allowing access to memory and peripheral devices by the code that needs to access those resources.  The application can be organized by processes, each having access to its own memory and peripheral space.  Not only does the MPU prevent application code from accessing memory or peripheral devices outside its designated area, but it can also be a useful tool for detecting stack overflows, one of the most common causes of issues when using an RTOS. 

This class discusses some of the features provided by most MPUs, but specific examples assume the MPU found in most ARM Cortex-M MCUs. Topics covered include: 

  • Privilege modes
  • Limiting RTOS APIs for user code
  • Preventing code from executing out of RAM
  • Sharing data
  • Keeping RTOS objects in RTOS space
  • Handling faults
  • And more
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

mgaron
Score: 0 | 5 months ago | 1 reply

I used an MPU once and this lecture kicked me in making it an habit. Thank you for getting out of retirement for this interesting lecture. Also glad I could meet you in person in ESC Boston roughly 10 years ago.
Warm thanks from Qc.

JeanLabrosseSpeaker
Score: 0 | 5 months ago | no reply

Awesome. Great to know you enjoyed the class. As you noted, it’s a great device to use, especially since it’s included with most Cortex-M. as I indicated at the beginning of the Q&A, you DON’T have to force your code to run in user mode. If you have the discipline of not tampering with the MPU from your application, you still get a lot of benefits from using the MPU, except with less protection and less overhead.

CarlesMarsal
Score: 0 | 5 months ago | 1 reply

Hats off Mr. Labrosse.
You just fit a master class on RTOS, their entities, and their protocols, all the while giving away most useful insights, tips and pitfalls in a super-divulgative and well-explained talk. It really shows this is a very known territory to you. I will definitely look at the "more reading" part of the end of the presentation.

JeanLabrosseSpeaker
Score: 0 | 5 months ago | no reply

Thank you for your kind words. I’m glad you enjoyed it.

burak.seker
Score: 1 | 5 months ago | 1 reply

Thanks for the effort and this good presentation. The topic is really interesting and make me wanna use MPU in my projects.
If I understand correctly, uCoSIII will be able to provide an MPU module in future releases. When do you think it will be available?
Also beyond the borders of this great presentation, I wonder that is there any plans to offer multicore (SMP or AMP) support with uCoS? I am wondering because I can only use one of the cores with CortexA9 chip and the other core is just waiting idle.
Regards

JeanLabrosseSpeaker
Score: 0 | 5 months ago | no reply

Well, I'm not sure whether it will be uC/OS-III or the Weston Embedded Solutions (WES) version which is called CesiumOS3. Weston Embedded is formed of ex-Micrium guys and they created a derived product from the Micrium software. That's because Silicon Labs released the uC/ product as open source but many 'customers/users' prefer having a commercial version of the Micrium products. The initial version of CesiumOS is identical to the uC/ products when Silicon Labs released the product for open source. From now on, CesiumOS will be maintained for commercial users. WES also maintains the uC/ products, though.

I know that WES has an AMP version of uC/OS-III. SMP is a different animal. Check with WES: www.Weston-Embedded.com for any updates.

DS
Score: 0 | 5 months ago | 1 reply

Excellent presentation. Thank you.
I had a question about the exception that can be fired when the stack overflows. Which stack does the exception use since the task's stack just overflowed - is it the RTOS's stack?

JeanLabrosseSpeaker
Score: 0 | 5 months ago | no reply

All exceptions (on the ARM Cortex-M) forces the CPU to switch to an 'exception' (or ISR) stack. So, it's not technically the RTOS stack but the CPU's ISR/exception stack.

DaveN
Score: 0 | 5 months ago | 1 reply

What about 3rd party libraries that use malloc/free? For example newlib, ST's drivers, etc?

JeanLabrosseSpeaker
Score: 0 | 5 months ago | no reply

You 'could' use an MPU region to 'wrap' all of the Heap space and add that region to all process tables. You won't be able to distinguish each of the allocated areas and protect them from one another.

Cleo
Score: 0 | 5 months ago | 1 reply

So if a device is not in a task's process table, then it cannot access it?

JeanLabrosseSpeaker
Score: 0 | 5 months ago | no reply

That's correct. This is done to ensure that a task that has no business accessing an I/O device doesn't. For example, a TCP/IP stack should be allowed to access the Ethernet controller but not a User Interface process. However, if you need to access the I/Os then you simply add a region for the MPU to access those I/Os.

OUR SPONSORS