Memory Protection Unit (MPU)
14 Memory Protection Unit (MPU)
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
14.1 Introduction
The Memory Protection Unit (MPU) API provides functions to configure the MPU. The MPU is tightly
coupled to the Cortex-M4 processor core and provides a means to establish access permissions
on regions of memory.
Up to eight memory regions can be defined. Each region has a base address and a size. The size
is specified as a power of 2 between 32 bytes and 4 GB, inclusive. The region’s base address must
be aligned to the size of the region. Each region also has access permissions. Code execution can
be allowed or disallowed for a region. A region can be set for read-only access, read/write access,
or no access for both privileged and user modes. This can be used to set up an environment where
only kernel or system code can access certain hardware registers or sections of code.
The MPU creates 8 sub-regions within each region. Any sub-region or combination of sub-regions
can be disabled, allowing creation of “holes” or complex overlaying regions with different permis-
sions. The sub-regions can also be used to create an unaligned beginning or ending of a region by
disabling one or more of the leading or trailing sub-regions.
Once the regions are defined and the MPU is enabled, any access violation of a region will cause
a memory management fault, and the fault handler will be activated.
Generally, the memory protection regions should be defined before enabling the MPU. The regions
can be configured by calling ROM_MPURegionSet() once for each region to be configured.
A region that is defined by ROM_MPURegionSet() can be initially enabled or disabled. If the region
is not initially enabled, it can be enabled later by calling ROM_MPURegionEnable(). An enabled
region can be disabled by calling ROM_MPURegionDisable(). When a region is disabled, its con-
figuration is preserved as long as it is not overwritten. In this case it can be enabled again with
ROM_MPURegionEnable() without the need to reconfigure the region.
Care must be taken when setting up a protection region using ROM_MPURegionSet(). The function
will write to multiple registers and is not protected from interrupts. Therefore, it is possible that an
interrupt which accesses a region may occur while that region is in the process of being changed.
The safest way to protect against this is to make sure that a region is always disabled before
making any changes. Otherwise, it is up to the caller to ensure that ROM_MPURegionSet() is
always called from within code that cannot be interrupted, or from code that will not be affected if
an interrupt occurs while the region attributes are being changed.
The attributes of a region that has already been programmed can be retrieved and saved using
the ROM_MPURegionGet() function. This function is intended to save the attributes in a format
that can be used later to reload the region using the ROM_MPURegionSet() function. Note that
the enable state of the region is saved with the attributes and will take effect when the region is
reloaded.
When one or more regions are defined, the MPU can be enabled by calling ROM_MPUEnable().
This turns on the MPU and also defines the behavior in privileged mode and in the Hard Fault and
NMI fault handlers. The MPU can be configured so that when in privileged mode and no regions are
April 8, 2013 145
To Next Page
Loading...
Need help?
General
