Hi Folks,
I have spent some time searching to download the FreeRTOS code for an Arm m3/m4 processor that uses the MPU. Lots of info on how it works but no actual library of the code. Finally found the CORTEX_MPU_LPC1768_GCC_RedSuite in the FreeRTOS demo zip. Is this the only example?
Many thanks, Ron
What exactly do you want to employ the MPU for?
The app consists of a number of code modules that manage input streams from the usart, ethernet and USB. The first module unpacks and streams the packets to a module that decides if this unit will manage that packet. If so it will pass the partially decoded packet to another module that properly decodes the packet in detail and operates on its embedded command. The latter could consist of a parameter configuration but usually will be a command to a motor controller which is itself a module.
All standard stuff that already works on a LPC1349 using standard FreeRTOS where each module includes a task that manages the data flow via queues, ensuring no message is lost and proper handshaking with the host occurs. However a number of new requirements are coming up that will exceed the 1349’s capabilities. So a port to a different processor and a reliability requirement for the modules to run as MPU User mode tasks means I am looking at the FreeRTOS MPU version.
Here are some other examples in the same zip:
- https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS/Demo/CORTEX_MPU_LPC54018_MCUXpresso
- https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS/Demo/CORTEX_MPU_M3_NUCLEO_L152RE_GCC
- https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS/Demo/CORTEX_MPU_M7_NUCLEO_H743ZI2_GCC_IAR_Keil
- https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS/Demo/CORTEX_MPU_STM32L4_Discovery_GCC_IAR_Keil
Thanks.
Well, I think I must admit defeat with linking a FreeRTOS MPU project.
My next project needs to use an LPC54114 and its MPU, but to do some learning I decided to try with an existing FreeRTOS MPU project first. To this end I ported the LPC1768 project to the LPC1549 using the current MCUXpresso IDE.
I think I have read every document published about how to setup the linker script using either the internal “Manage linker script” or hand-editing the associated linker scripts. I am obviously missing something as I cannot figure so far how to configure the linker to treat the privileged_data section as bss and automatically clear it. I can do this programatically but that is pointless. I am also unsure if the privileged_functions are correctly positioned although they do look ok in the map. On testing I either get a hard memory fault or a MallocFailed fault. I can debug the reasons for these faults but have given up because I cannot find a clear explanation of how the linker in a FreeRTOS project is configured to position the code and data as required.
I have no problems with FreeRTOS as I now have several projects successfully using it, both in C and C++. My intent for the LPC54114 project was to explore the advantages of including an MPU to increase the code security.
I’ll give it a rest for a while - perhaps go off and read the GCC ld manual from cover to cover.
Regards, Ron Kreymborg
You can configure it as data section and let the startup code initialize it. How your startup code initializes the data section will determine if you need to do anything special in the linker script. Here is a linker script for MCUXpresso (where a data table is defined to be used by the startup code) - https://github.com/FreeRTOS/FreeRTOS/blob/main/FreeRTOS/Demo/CORTEX_MPU_LPC54018_MCUXpresso/Projects/MCUXpresso/FreeRTOSDemo.ld
Your flash and RAM should be partitioned like the following:
RAM FLASH
__SRAM_segment_start__ -----------> +------------------+ +-------------------+ <------------+ __FLASH_segment_start__
| | | |
| | | |
| Privileged Data| | Privileged Code |
| | | |
| | | |
| | | |
| | | |
__privileged_data_end__ -----------> +------------------+ __syscalls_flash_start__ --> +-------------------+ <------------+ __privileged_functions_end__
| | | |
| | | System Calls |
| | | |
| | | |
| | __syscalls_flash_end__ -----> +-------------------+
| | | |
| | | |
| Unprivileged Data| | |
| | | |
| | | |
| | |Unprivileged Code |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
__SRAM_segment_end__ --------> +------------------+ +-------------------+<--------------+ __FLASH_segment_end__
The privileged data and privileged code section need to satisfy the alignment requirements of the MPU hardware as MPU regions are used to protect them.
I am happy to setup a joint debugging session, if you think that will help. Or if you want to create a minimal separate project (without your proprietary code) and want me to look at your linker script, I am happy to do that too.
Thanks.
You likely need to alter the startup code to create TWO .bss sections, one in the privileged data and one in the unprivileged data blocks,
Many thanks Gaurav. That is a very generous offer of assistance.
I am aware of what needs to be done, just cannot find the fine detail of how to do it. As Richard suggests, it would seem I need two bss sections covering the privileged and unprivileged data sections although this would require changes to the ResetISR function in the cr_startup_lpc15xx code. The MPU is not involved when the bss is being cleared, so you would think they could be defined as essentially contiguous.
Rather than spend any more time on this converted '1768 project using V8 FreeRTOS, I will start a similar test project with a '54114 (OM13089 board) using the current FreeRTOS MPU code. The changes to the linker required here will become common as more programmers start to use MPUs.
My long term hope is to be able to configure MCUXpresso to manage the linking without editing automatic files or using FreeMarker. I am also interested in using some of the suggestions in the Good Motive but Bad Design: Why ARM MPU Has Became an Outcast in Embedded Systems paper by Zhou et al on using the sub-region disable field in the RASR.
I’ll let you know how I go Gaurav.
Thanks again, Ron
I do not think that is needed - privileged data is placed in a separate section and you should treat it as initialized/data section (as opposed to bss).
Thank you!
‘Privileged Data’ may well contain data that doesn’t need to be initialized, but is generated at run time, and as such doesn’t need a copy of the initial zero state in the boot flash.
This is really a ‘tool’ problem.
I wonder if the issue is that for this sort of system, classically the ‘application’ is often built in two totally independent pieces, a privilege program that lives almost totally in the privilege section, with a published API, and an unprivileged program that lives totally in the unprivileged section, using that API, so at any one time you only really need to live with one type of code, and the code uses two different copies of the ‘startup’ code.
Ok, I was just wondering if the bss sections could be combined. As you say, it matters not at all to the application.
The idea of a 3-layer application is more or less what I do now : the FreeRTOS code, a set of well known functions that provide the various internal interfaces in both directions, and the functions that must deal with the sometimes unknowable environment. With an MPU the latter would all be protected tasks so the application has some chance of managing a really unexpected event by unwinding the perceived damage. I would not want this code to have anything to do with initialization of the runtime environment.
Many thanks again for your advise. Moving to the latest MPU FreeRTOS for an LPC54xxx may solve all these problems. I am assuming there is one!
Regards, Ron
Yes, you are right. Thanks you!
If you face any problem there, I am very interested in knowing so that we can address those. Please keep us posted.
Thanks.