Difference between Sub regions and Overlapping Regions in MPU

Overlapping regions:

Each region is defined by a base address, a size and some attributes.

If you define multiple regions, it is possible some might overlap.  For example:

Region A: Covers 1MB starting at 0x0

Region B: Covers 4KB starting 0x10000

The address range 0x10000-0x10FFF is now covered by both A and B.  So which attributes should it use?  The overlapping region rules in the PMSA describes how this is resolved.

Sub-regions:

Each region (as long as it's at least 256 bytes) is sub-divided into 8 sub-regions.  With an enable bit per sub-region.  Effectively allowing you to "poke a hole" in a region.  The corresponding addresses are not treated as part of the region.  They will either pick-up the attributes of an overlapping region (if there is one), or use the defaults.

Allowing overlapping and sub-regions gives you flexibility, and can in many cases reduce the total number of regions you need to define.

Martin's answer is correct.

As for the birds-eye view on why to use the Memory Protection Unit:

You can write your firmware as two 'parts'

1. A part that speaks directly to hardware.
2. A part, which does trivial jobs and calculations.

The part, which speaks directly to hardware, needs to be privileged.

Privileged level means that it has full access to everything.

The other part, which just do calculations and other trivial jobs, does not need to be privileged and thus should not have any access to peripherals. In addition, this part should not have access to the supervisor stack pointer.

Now, if you protect the memory, which belongs to the 'privileged part', errors, such as 'buffer overruns' will not harm the essential part of your program; eg. errors that cause the trivial jobs to have accidents can be completely avoided.

Thus it will reduce serious errors to the 'privileged part', which is usually a very small part of the firmware, and it's easier to make sure that this small part is completely correct.

So if you focus on making the privileged part correct, then you are free to make the unprivileged part go crazy in its sandbox, which will not harm anything but itself. The privileged part can even watch the other part and be able to make corrections to its behaviour.

In addition to the above, you can create a memory allocator, which only allows writing to allocated blocks and disallows writing to 'free' blocks, making further protection against errors. This will also make it easier for you to spot errors, as you will be notified by any access to protected areas.

To access privileged functions, you can for instance use SVCall, so that way, you can communicate with the hardware.

Thanks for the reply martin.

Regards,

Techguyz

Hi Jens,

Thanks for the detailed illustration.

Now I could see the apt usage of the features.

Regards,

Techguyz