Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training


Adding MPU support to existing port

Posted by nburkitt on February 7, 2015

Pardon any multiple posts - this is my third attempt. What's involved in adding MPU support to an existing port? It seems like it shouldn't be a major project. Is there any documentation on what needs to be provided, and how it needs to interface to the kernel? Thanks,


Adding MPU support to existing port

Posted by rtel on February 7, 2015

Which architecture are you wanting to add MPU support to?


Adding MPU support to existing port

Posted by nburkitt on February 7, 2015

Thanks - I'm using the Microblaze port. I figure at this point that the time I've spent chasing a memory overwrite bug is probably about equal to the time it would have taken to implement MPU support. At least it feels that way. :-/ I understand there's an update to the MB port coming - any chance it includes MPU support? Thanks again,


Adding MPU support to existing port

Posted by rtel on February 8, 2015

Unfortunately I'm not familiar with how the MPU works on the Microblaze, so will give a generic reply.

'Standard' (non MPU) ports work by linking the FreeRTOS API functions directly into the application code. That is the best/most efficient way if memory protection or security are not a concern.

If memory protect or security are a concern then you will want to run some user tasks with a low privilege levels, while leaving the RTOS code running with a high privilege level. You then need a method of switching from the low privilege task code to the high privilege RTOS code when an API function is called. That is normally done by creating a software interrupt - interrupts always running at a high privilege level.

Traditionally, in MPU restricted applications, API functions are called by pushing the function's parameters onto the stack, then calling a software interrupt generating instruction with a parameter. For example, in old DOS systems, the instruction was "INT" and you would pass a parameter that would identify the function being called, so you might call "INT #16".

The software interrupt handler then looks at the parameter (that can be tricky as it is often encoded as part of the assembly instruction) to see which function to call. Once it knows which function to call it knows the number of parameters to pop off the stack.

However, FreeRTOS does not normally go that far, and instead uses a simpler but method that is fine provided for systems that only run code of known providence. In the FreeRTOS scheme it wraps each API function in an version that uses a software interrupt to raise the CPU privilege, calls the API function, then sets the privilege back to whatever it was when the special version started running. It does that uses macros (you will find a file called mpu_wrappers.h) so is somewhat transparent to end users.


Adding MPU support to existing port

Posted by nburkitt on February 9, 2015

Thanks, that's a good start. The Microblaze MMU can be configured in any of three modes, "user," "protection," and "virtual" (four if you count "none"). I think "protection" is probably the right choice here. It appears to be something along the lines of virtual memory minus address translation, but documentation is in short supply. The manual claims that the MMU implementation is the same as the PowerPC, but likely it is talking only about "virtual" mode. Who's responsible for creating and mapping memory regions? Do I need to provide a version of malloc that understands MB TLB setup, and can deal with each task having its own heap? Thanks again,


Adding MPU support to existing port

Posted by rtel on February 9, 2015

When I have done this I have allocated the stacks dynamically, allowing them to be placed where needed (using the linker), then used the xTaskCreateRestricted() function to pass the stack in to FreeRTOS: http://www.freertos.org/xTaskCreateRestricted.html


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists