应用笔记 | MPU 子区话题-电子发烧友网

关键字：MPU， SubRegion

目录预览

1 问题起因2 问题解析3 问题小结

1. 问题起因

有人询问STM32F7 和STM32H7 系列库例程中有关MPU 配置中的下面这句加绿色下划线的代码的意思是什么？有何用？

图1、芯片存储空间MPU 背景配置

从上面截图中的红色框内代码我们不难看出，这里进行MPU 设置就是将从0 开始的4G 空间，即整个STM32 可寻址空间定义为Strongly Ordered 存储属性。且此时MPU Region 编号为0。可代码注释上又说只是将未定义的区域配置为Strongly Ordered，这未定义区域到底啥意思，该如何理解？难道跟绿色下划线标示的那行代码有关系。

那么，这句代码MPU_InitStruct.SubRegionDisable = 0x87; 又是什么意思呢？

要理解这行代码的意思，我们就有必要了解MPU 的子区概念【Subregion】。

2.问题解析

所谓子区【Subregion】，当我们对任一存储空间不小于256B 的区域【Region】进行MPU 配置时，往往可以把该区【region】等分为8 个子区【Subregion】，并可以把当前MPU 配置选择性地针对各个子区进行排除性设置。在内核里有个关于MPU 配置的寄存器MPU_RASR,其中有个8 位字段SRD 就是用来设置各个子区的MPU 排除性设置或者说例外性配置。如果某位为0，表示该子区适用当前MPU 配置；如果某位为1，表示该位所对应子区不适用当前MPU 配置，即不受当前MPU 配置约束。下图是MPU_RASR 寄存器的描述截图：

图2、MPU_RASR寄存器

不妨举例说一下。假设我们选择了某64MB区域进行MPU设置，属性配置如下：

图3、某特定内存MPU配置代码

基于上面配置，该64MB空间配置为不共享、可缓存、可执行程序的MPU存储属性【细节可以核对下图4，其中C表示Cacheable，B表示Bufferable，S表示Shareable】

图4、MPU配置属性对应表

这里有针对个别子区做了MPU属性排除操作，就是靠下面这句代码实现的：MPU_InitStruct.SubRegionDisable = 0x28;//即二进制00101000

前面说过了，我们可以将大于256B的存储区等分为8个子区并做MPU属性排除配置。这里的0x28对应的8位2进制数表示各个子区针对当前MPU配置是否被排除在外的情况，若某位为0时表示相应子区适用当前MPU配置属性，为1则不适用当前MPU的配置。

结合前面寄存器描述和上面配置代码，被排除在外的即不适用当前MPU配置的子区就是下图5中的两个地址空间【标红色1的地方】：

图5、某特定内存MPU子区配置布局

若把上面图形左转90°即可看明白刚才那个SRD字段的配置值0x28的由来以及地址空间对应关系，SRD的高位对应高地址子区。基于上面配置，有2个8MB空间是不适用当前的MPU配置，即被排除在外了。

我们不妨再看看另一个关于MPU子区的示例【来自ARM M7内核技术手册】。

图6、带内存重叠的MPU配置

根据上面信息我们可以得知，MPU配置了2个存储区【Region】，其中Region1的地址空间与Region2部分地址空间是重叠的。在Region2中使用到子区【subregion】,其中与Region1重叠的两个子区做了MPU排除处理，即Region2中头2个子区的MPU属性不适用于Region2的MPU配置，这2个子区的MPU属性取决于Region1的配置。换言之，Region2的配置对头2个子区的MPU属性沿用了Region1的。

对MPU的区[Region]及子区[Subregion]介绍得差不多了，我们继续回到最开始那个问题。整个空间4GB被等分为8个子区，每个子区500MB。现在子区【Subregion】的MPU设置是这样的：

MPU_InitStruct.SubRegionDisable = 0x87;//10000111B

即有4个子区做了MPU属性排除处理【上面红色1注释标示的】，其它4个子区【绿色0标示出来的】适用Strongly ordered 存储属性。我们可以结合手册具体看看各个子区的分布情况。

图7、4G空间的MPU子区划分图

上图中红色区域并不适用当前配置的Strongly ordered 存储属性，只有其它绿色区域适用，他们集中在外部设备存储区。看到这里，有人或许发现这个MPU配置只是个粗线条的配置，重点对外部存储区域做了大致的初始背景配置，即配置为Strongly Ordered属性。

在实际应用中，开发者往往会根据实际情况针对外部存储器做进一步的MPU配置。当我们阅读STM32F7或 STM32H7系例相关应用代码时，我们会发现，除了看到开篇提到的的针对整个4G空间的MPU初始配置外，还有诸多针对外部存储区的特定MPU配置，比方下面这些就有针对外部SD RAM、QSPI、FMC控制的存储设备的MPU配置。主要就Region编号、起始地址、空间大小、Cacheable、Bufferable、Shareable等属性进行配置。【下图中打红色三角形的是针对整个4GB空间的MPU初始配置，其它打勾的是针对特定存储空间的MPU配置，该区间的MPU属性与4GB空间中重合部分的初始配置不一致时以新配置为准。】

图8、STM32H7产品的MPU配置代码示例

显然，上面SDRAMQSPIFMC的存储区都落在图7中的绿色区域空间，因为此时的特定配置所用MPU区编号都要高于那个粗线条配置的区编号0。对于MPU配置而言，重叠区域的MPU配置以更大区编号的配置为准。以图8中64KB的SDRAM配置来看，此时从0xC0000000开始的64KB区域不再适用Strongly Ordered存储属性，而适用Cacheable 、Write Through存储属性。

或许有人会问，既然具体应用时我们会针对所用存储设备做更合适的MPU配置，为什么要事先基于整个4G空间做粗线条配置，对外部存储空间做Strongly Ordered属性的初始配置呢？那个粗线条的MPU初始配置岂不多余？

要解释这个问题，就涉及到另外一个话题，即Cortex M7内核的试探性访问【关于试探性访问，这里不做过多解读，有兴趣查看相关内核手册】。当内核处理器因发生试探性访问去访问一个不存在的存储设备时往往会导致访问死锁，显然这不是我们所希望的。

不过，试探性访问可以被阻止，即当相应存储空间配置为Device或Strongly Ordered属性时，是不会发生试探性访问的。

我们依然以上面提到的64KB的外部SDRAM来看，显然它往往并没有占据整个External Device空间，只是使用了有限的空间。如果说SDRAM所占区域以外的空间的属性不是Device或Strongly Ordered，若访问SDRAM时发生试探性访问跳到SDRAM实际容量以外的区域，此时因无实际存储设备就可能出现死锁之类的异常。为了防止这个问题发生，就有了上面的事先针对4G空间做了粗线条的MPU配置，并特地将整个外部存储设备所对应的空间都配置为Strongly Order属性。

结合下图看看，黄色区域为用户根据实际SDRAM容量更新过的MPU配置，绿色部分为事先配置的Strongly Order属性，以阻止处理器针对绿色区域进行试探性访问。

图9、粗线条初始配置结合用户更新的MPU配置

换句话说，事先针对整个4G空间做MPU配置，正是为了明确那些没有做特定MPU配置的外部存储空间的存储属性，Strongly ordered 属性配置恰好可以很好地防止M7处理器对并不存在实际存储设备的空间进行试探性访问而导致异常。这也就正好解释了开头提到的那句注释“将未定义区域配置为Strongly ordered属性”。

或许有人发现即使不要那段针对4GB空间的MPU初始配置代码，似乎也没遇到啥问题。这也正常。因为你即使外扩了存储单元，并非一定会因为试探性访问导致异常。比方你外扩了32MB的存储单元，未必就一定会要用到最后一个位置，说不定还剩余很多，远不至于用到最后边界而让CPU试探到不存在存储器的空间。但是事先做那段初始配置，对系统是一个很好的未雨绸缪。就好像河边安置防护栏一样，没有，也不至于天天怎么样；有，肯定要安全保险得多。

3. 问题小结

本篇内容主要涉及内核MPU配置方面的东西，重点针对客户的疑问做了些解答，对MPU配置中的子区概念做了较为详细的解读，以供参考。

完整内容请点击“阅读原文”下载原文档。