Hi All,
The title may seem a bit negative, just from my personal point of view.
What is the main reason of the two requirements of setting up MPU, namely size and start addresses of MPU regions.
First, the size of an MPU region must be 2^n x 32 bytes. This makes quite some of waste of memory space because one must size an output section in linker script corresponding to its MPU size. Second, the start address of an MPU region must be multiple of the MPU size.
So, during linking, one must place an output section aligned to its MPU region. This again creates some waste in the memory space.
Moreover, one must do twice linking! One gets the actual size of an output section in the first time and computes new size and start address according to its MPU region. Then, the second linking must be performed to place all output sections at right place.
A less serve problem I encountered was the number of MPU regions. In my opinion, 8 cannot be enough in some cases.
How do you guy think of the problem described here?
Best regards. Teddy
Hi,
Thanks for your question.
The requirement that all regions are naturally aligned simply makes the address decode easier. This allows the MPU to operate without any time penalty on instruction execution. It is usually not too onerous to comply with this.
With regard to the number of regions, are you aware of the concept of "sub regions"? Each region (larger than 128 bytes) can be divided into 8 sub-regions, each of which can be individually disabled. You can find details of that in the ARM ARM.
Hope this helps.
Chris
Hi Chris,
Thanks a lot for your answer. I can understand your reasoning.
Chris Shore wrote: It is usually not too onerous to comply with this.
Chris Shore wrote:
It is usually not too onerous to comply with this.
Here I cannot fully agree with you. I would say it is very likely that an output section in the linker script will not comply with the requirements of MPU.
Last week, I even encountered another problem. For some code, after second linking to comply with MPU sizes, ARM GCC inserts some veneer, which changes the size of an output section. That required me to the third time linking!
Hi Teddy,
The orginal ARM MPU programmer's model is optimized for minimum gate count. If defining the MPU region in other ways to allow a fully flexible arrangement, the gate count (silicon area) and power would also increase. The Cortex-M3 and M4 MPU are designed based on the similar programmer's model and therefore inherited the same limitations.
In the Cortex-M7 processor we increased the maximum MPU region to 16.
Currently the most common usages for the MPU included:
1) settting up stack space for application tasks in RTOS
Since the size of the stack for application tasks can be determined during compilation, we can create stack layout to match MPU regions manually (I know, it is not easy). As Chris mentioned, sub region disable is a useful feature to enable a finer memory layout control.
2) setting up memory attributes for certain memory space
Some Cortex-M chips can have cache (e.g. Cortex-M7 processor have built-in cache, and other Cortex-M processor can have system level cache). You can use the MPU to define cache attributes to utilize teh cache feature.
3) Use the XN (eXecute Never) attribute to make a memory space (e.g. communication buffer in SRAM ) non-executable for security reason.
Using of MPU regions for program code access control is less common because of difficulties of handling this in most standard MCU tools (as you mentioned). However, even if we change the prgrammer's model of the MPU, you might still need to compile the code twice because you don't know the code size until you compiled it the first time. (Depends on whether there is a way to feed the size information into some sort of MPU settings table in the development tools).
It is an area we looked into, but to improve that we need to break the current software compatibility and cope with the impact of larger silicon size (and power). So it might need a bit more thinking time to decide.
regards,
Joseph