FreeRTOS + MPU Support in ARM Cortex-M7

Kernel
#1

Hello all,

I am currently working with a SoC based on a Cortex-M7 (r0p1) core. The specific chip is the S32K344 MCU but I doubt I will get anyone who has worked with this chip, so I’ll try to generalize it.

We want to use the MPU available in the chip, which has 16 regions. I downloaded the latest version of FreeRTOS, navigated to the demos folder, and opened the demo application:

FreeRTOSv202112.00\FreeRTOS\Demo\CORTEX_MPU_M7_NUCLEO_H743ZI2_GCC_IAR_Keil

I just ordered this board to try to run this demo, but I found something rather interesting.

Under the Source folder of FreeRTOS, there’s no folder for the Cortex-M7 with MPU support, there’s only support for Cortex-M4. The demo application actually uses this M4 port to run on the M7.

I’ve read through the forums that the Cortex-M4 MPU has 8 regions. I want to use this port on my Cortex-M7 chip, with a 16-region MPU.

  1. Is it worth pursuing trying to “add” the 16 region functionality?
  2. What are the downsides of using the M4 port (other than less regions)?

Why is there no support for Cortex-M7 + MPU in the FreeRTOS source yet? There are plenty of chips that use this architecture now, I feel like I’m not the only person asking this

Any help, guidance, and lessons are much appreciated

Thanks in advance

#2

You can use Cortex-M4 port on Cortex-M7 as there is nothing different to do for the scheduler.

We already support 16 MPU regions - FreeRTOS-Kernel/port.c at main · FreeRTOS/FreeRTOS-Kernel · GitHub. You need to define configTOTAL_MPU_REGIONS to 16 in your FreeRTOSConfig.h. The example you mentioned showcases the use of 16 MPU regions - FreeRTOS/FreeRTOSConfig.h at main · FreeRTOS/FreeRTOS · GitHub

Thanks.

1 Like
#3

Will this apply for Cortex-M7 r0p1 as well as newer revisions of the silicon without the errata?

Thanks for your answer!

#4

You will need to diff the m4f port with the m7r0p1 port to see the changes, which are few, then make those same changes in the standard m4f mpu port.

#5

@MateoSegura : I opened a pull request applying the workaround from the CM7 r0p1 port to the CortexM4-MPU GCC and RVDS ports:

Add Cortex M7 r0p1 Errata 837070 workaround to CM4_MPU ports by paulbartell · Pull Request #513 · FreeRTOS/FreeRTOS-Kernel · GitHub .

#6

Thank you!

I have one last question. If I use the MPU port, but decide to use xTaskCreate() with dynamic allocation, is there any overhead added?

In other words, if I do NOT use the MPU functionality, but I do use the MPU kernel port, will there be context switch performance hits, or any other technicalities I should be aware of?

#7

Yes there is a performance hit as the mpu regions are saved and restored even if they are not used. That is faster (a couple of asm instructions) than testing to see if they are used, and needed anyway to clear any mpu regions used by the task being switched out.

#8

I spent a bit of time working with FreeRTOS + MPU on an arm cortex-a. In the end, I felt like the value of the whole MPU thing wasn’t worth it, the overhead isn’t trivial, and if your code is going to crash, having an MPU really only would help some in the development phase.

#9

Yes, “Just” an MPU isn’t enough to let your whole program just ignore pieces that “crash”. It just lets you fail more gracefully in a safer manner.

If the task never trips the MPU, then the MPU wasn’t actually needed, which means for most programs, the MPU is really just a development phase support, perhaps kept in the application to avoid major changes at release, and to make safer the fail mode if something does go wrong. This can be important, but still, only affect things if something goes wrong.