尧图网站建设 
做嵌入式这几年我最大的感受是很多系统跑到半夜才复现的灵异故障最后排查下来都是内存踩踏。数组越界、栈溢出、野指针改写关键变量——在没有内存保护机制的时候MCU基本上是在裸奔状态里替你扛着所有bug。后来真正开始系统性地使用STM32里的MPUMemory Protection Unit内存保护单元才发现这东西不只是给航空航天或者汽车级项目准备的它在普通工控、物联网产品上同样能大幅提升系统的可维护性。这篇应用笔记我打算把STM32系列Cortex-M内核上的MPU从原理到实战完整捋一遍。包括MPU到底是什么、Region怎么配、权限怎么设、子区域怎么用再说说我在FreeRTOS任务栈保护、Bootloader隔离、外设寄存器保护这几个真实场景里的落地经验最后整理一份常见问题排查表。文章适合两类人一类是被内存踩踏坑到想从机制层面解决问题的嵌入式工程师另一类是刚接触MPU、想搞明白这个外设该在哪些项目里用起来的新手。不管你用的是F4、F7还是H7只要内核是Cortex-M3以上这套逻辑基本都是通用的。1. 先搞明白 MPU 到底是干什么的为什么这么重要1.1 没有内存保护时的 MCU 有多脆弱我先讲一个自己踩过的真实例子。之前做了一块STM32F407的主控板跑FreeRTOS系统运行几个小时偶尔会出现奇怪现象串口数据错乱、某个全局变量莫名被改、任务执行顺序不受控。一开始怀疑电源纹波怀疑外部干扰折腾了大半个月最后用软件排查才发现是某个任务里的局部数组越界把相邻的另一块内存给踩了。问题的根源在于MCU在没有内存保护机制时程序对内存的访问是没有任何边界的。你用C语言写一个数组下标越界写一个悬空指针在PC上可能立刻段错误但在MCU上不会。CPU根本不知道哪块内存属于谁只要地址总线上给出的地址能命中物理存储它就照单全收。于是越界写入的数据并不会当场报错而是静默地改写了别的变量、别的任务栈甚至是外设寄存器。这种bug最难查因为表象和根因往往隔着好几层等你找到根因现场早已经被破坏得面目全非。1.2 MPU 的本质一套内核级门禁规则MPU就是为这个问题设计的。它挂在Cortex-M内核内部由ARM架构统一提供不是ST为了卖芯片特意加的外设。它的工作方式可以类比成小区门禁程序运行时有特权模式内核、中断服务、RTOS内核代码通常跑在特权模式和用户模式普通任务一般跑在用户模式MPU就是根据当前模式来决定你能不能访问某块区域以及进去了能做什么事。关键点在于MPU的判断是纯硬件逻辑在每次内存访问的流水线阶段就完成匹配和权限校验配置好之后不会像软件Hook那样拖慢执行速度。只有访问真正违规时CPU才会触犯MemManage Fault异常把控制权交给异常处理函数。这意味着你可以把MPU长期打开当作系统的一道常驻防线而不用担心它带来明显的性能开销。我在多个项目里的体会是MPU最大的价值不在于防黑客而在于防自己。它能让你在程序刚越界的瞬间就停下来而不是等错误在内存里扩散了几个小时之后才爆发。对于中大型固件、RTOS多任务系统、OTA升级场景这个能力几乎是刚需。1.3 不同 STM32 内核的 MPU 能力差异STM32系列里Cortex-M3、M4、M7这些内核都内置MPU但入门级的Cortex-M0/M0没有选型的时候要留意。即使同样是带MPU的内核能力也有细微差别内核最大Region数备注Cortex-M38基础功能齐全Cortex-M48与M3基本一致Cortex-M716Region更多与Cache系统强关联Cortex-M7的MPU和M4有个重要差异M7的L1 CacheI-Cache和D-Cache的缓存策略是跟着MPU的Region属性走的。也就是说在H7系列上如果MPU配置不当可能不仅影响内存保护还会影响Cache行为甚至导致DMA和CPU之间的数据不一致。这一点后面实操部分会重点讲。如果你想确认手里的芯片到底支持几个Region可以直接读MPU-TYPE寄存器它的低8位表示硬件支持的Region数量。我通常会在初始化代码里把这个值打印出来方便在开发板上核对。2. MPU 的核心概念Region、子区域与权限属性2.1 Region连续地址的独立保护单位MPU的管理粒度是Region也就是一段连续的地址范围。配置一个Region需要三个关键参数起始地址、大小、访问权限。Region的大小有严格要求必须是2的整数次幂最小32字节最大可以到4GB。对应的SIZE字段值为 log2(大小) - 1。比如32字节SIZE 41KBSIZE 94KBSIZE 11512KBSIZE 18同时Region的基地址必须按大小对齐。比如你配置一个4KB的Region基地址必须是4KB的整数倍。0x20000000可以0x20000100就不行硬件的RBAR寄存器会直接忽略低位的对齐位行为不是你预期的。一段连续地址为什么要单独划成一个Region因为实际工程里的内存布局本来就是分块的Flash代码区、SRAM数据区、外设寄存器区、DMA缓冲区每块的访问需求不一样。代码区要只读可执行栈区要读写但用户态不能碰外设寄存器区最好只让特权模式访问。Region就是把这些差异化需求翻译成硬件规则的方式。2.2 子区域屏蔽多出来的空间可以精确扣掉每个Region可以被均匀分成8个子区域通过RASR寄存器里的SRD字段来控制每一位对应一个子区域置1表示禁用这个子区域。子区域屏蔽是MPU非常实用的功能它解决了一个很常见的矛盾地址空间里的保护对象往往不是整齐的2的幂次大小而MPU Region又要求按2的幂次对齐。举个例子。我有一块任务栈从0x20001000开始大小是2KB但我的数据区从0x20001800开始。如果我把2KB配成一个Region正好和栈重叠没有多余空间需要裁掉。但如果栈的实际使用区间不正好贴合Region大小我就需要调整策略。有一种常见做法是把Region扩大到4KB覆盖0x20001000到0x20002000然后把高2KB的4个子区域禁掉这样高位那部分地址虽然被Region覆盖但访问会被拒绝。只要子区域粒度够用就能用更大的Region去做精细裁剪从而节省Region槽位。2.3 AP 权限位与 TEX/C/B/S 属性位AP字段控制访问权限常用取值如下AP值特权模式用户模式0不可访问不可访问5只读只读6读写不可访问7读写只读实际项目里6用得最多比如栈区和关键数据区配成特权读写、用户不可访问代码区配成5只读防止程序跑飞后改写Flash里的代码。这里有个反直觉的点MPU的权限规则在特权模式和用户模式之间是有差别的但RTOS任务通常运行在用户模式还是特权模式取决于你给任务配置的CONTROL寄存器。如果你所有任务都在特权模式用户态的不可访问限制就形同虚设——所以要用好MPU最好配合非特权模式使用这也是很多RTOS的常见配置。TEX、C、B、S这四个位决定缓存和写缓冲策略。S代表ShareableC代表CacheableB代表Bufferable。在Cortex-M4上如果不涉及DMA和Cache保持默认值问题不大但在Cortex-M7上MPU的Region属性直接决定某块内存是否被D-Cache缓存、是write-back还是write-through配置错了会出现数据不同步的诡异问题。2.4 对齐规则最容易踩的那个坑关于对齐我多说两句因为它真的是踩坑重灾区。MPU要求基地址按Region大小对齐这个规则和很多外设DMA的要求类似。但不少人会为了省一个Region把两个本不相干的地址段强行合并成一个Region而这两段地址往往压根没有按2的幂次对齐于是Region配出来之后系统一跑到某个地址就触发MemManage Fault。我自己的习惯是每配一个Region之前先用address % size 0验算一遍。地址段如果太零碎宁可多用几个Region也不强行合并。Cortex-M4/M3只有8个Region看起来不多但实际项目里仔细规划通常够用。Region槽位是宝贵的资源它的规划应该和内存布局同步进行而不是等代码写完了再回头补。3. 从寄存器到 HAL 库一步步把 MPU 配起来3.1 动手之前必须先确认的三件事在实际写MPU配置代码之前有三件事建议先确认否则后面排查起来会很被动。第一确认芯片内核。M3/M4/M7才有MPUM0/M0没有。如果芯片不带MPU配置代码编译都会报错因为寄存器定义里根本没有MPU这个外设。第二确认自己的中断和异常向量表已经有了MemManage Fault处理函数。MPU违规会触发MemManage Fault如果这个异常向量没有定义系统会直接进HardFault甚至复位不利于排查。在使用CMSIS的工程里启动文件一般会自动把MemManage_Handler链接到一个弱定义但你要么在调试时把断点放在HardFault_Handler里要么自己实现MemManage_Handler。第三准备一个可以停在异常处理函数里的调试环境。头几次配置MPU几乎必然遇到一开MPU就进HardFault的情况。如果断点能停在异常现场直接看内核寄存器和CFSR定位会非常快。3.2 寄存器级完整配置示例Bootloader 与 SRAM 隔离我以STM32H743为例写一个比较典型的寄存器级配置。目标是把Bootloader所在Flash区域配成特权只读、用户可执行把SRAM配成特权读写、用户不可访问。这套配置在很多需要做OTA隔离的项目里可以直接用。#include stm32h7xx.h static void MPU_Config_Bootloader(void) { /* 1. 先关闭MPU配置过程不能被中断 */ MPU-CTRL 0U; __DSB(); __ISB(); /* 2. Region 0: Flash 0x08000000512KB特权只读用户只读可执行 */ MPU-RNR 0U; MPU-RBAR 0x08000000U; /* * SIZE字段: 512KB - log2(512*1024) - 1 18 * AP: 5 - 特权只读、用户只读 * XN: 0 - 可执行 * TEX0, C1, B0, S0 */ uint32_t rasr (18U MPU_RASR_SIZE_Pos) /* 大小 512KB */ | (5U MPU_RASR_AP_Pos) /* 只读 */ | MPU_RASR_C_Msk | MPU_RASR_ENABLE_Msk; MPU-RASR rasr; __DSB(); __ISB(); /* 3. Region 1: SRAM 0x20000000512KB特权读写用户不可访问 */ MPU-RNR 1U; MPU-RBAR 0x20000000U; rasr (18U MPU_RASR_SIZE_Pos) /* 大小 512KB */ | (6U MPU_RASR_AP_Pos) /* 特权读写 */ | MPU_RASR_ENABLE_Msk; MPU-RASR rasr; __DSB(); __ISB(); /* 4. 使能MPU特权模式下未命中Region的访问默认放行 */ MPU-CTRL MPU_CTRL_ENABLE_Msk | MPU_CTRL_PRIVDEFENA_Msk; __DSB(); __ISB(); }代码里每个寄存器写完后都加了DSB和ISB这件事很多人会忽略。原因在于MPU配置寄存器属于系统控制空间CPU在执行后续指令时不一定能立刻感知到这些寄存器的最新值。如果不加屏障指令可能出现配置完等于没配的情况尤其当你紧接着就去访问被保护的内存区域时。所以我的习惯是写完RNR/RBAR/RASR之后各加一次DSB全部配完使能MPU后再加一次DSB和ISB。AP字段的数值记不住没关系但要知道大概含义方便对着寄存器调试。5表示特权只读、用户只读6表示特权读写、用户不可访问7表示特权读写、用户只读。每种组合都有对应的使用场景配的时候要想清楚当前模式下的合法访问路径。3.3 用 HAL 库快速配置同一套方案如果你用CubeMX或者HAL库开发MPU配置会像填表一样直观。同样上面的需求用HAL库写出来是下面这样#include stm32h7xx_hal.h void MPU_Config_With_HAL(void) { MPU_Region_InitTypeDef MPU_InitStruct {0}; HAL_MPU_Disable(); /* Flash区域 0x08000000 512KB特权只读用户只读 */ MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.Number MPU_REGION_NUMBER0; MPU_InitStruct.BaseAddress 0x08000000; MPU_InitStruct.Size MPU_REGION_SIZE_512KB; MPU_InitStruct.SubRegionDisable 0x00; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL0; MPU_InitStruct.AccessPermission MPU_REGION_PRIV_RO_URO; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_ENABLE; MPU_InitStruct.IsShareable MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable MPU_ACCESS_CACHEABLE; MPU_InitStruct.IsBufferable MPU_ACCESS_NOT_BUFFERABLE; HAL_MPU_ConfigRegion(MPU_InitStruct); /* SRAM区域 0x20000000 512KB特权读写用户不可访问 */ MPU_InitStruct.Number MPU_REGION_NUMBER1; MPU_InitStruct.BaseAddress 0x20000000; MPU_InitStruct.AccessPermission MPU_REGION_PRIV_RW; HAL_MPU_ConfigRegion(MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT); }HAL库的好处是封装了一堆寄存器操作代码读起来像配置表可维护性高。但缺点也很明显不同系列芯片里的枚举名可能略有差异比如MPU_REGION_PRIV_RO_URO在某个头文件里可能不长这样编译不会报错但运行行为可能不对。我在用HAL库配完MPU之后一定会用调试器读一遍MPU-RBAR和MPU-RASR确认硬件寄存器里的实际值和预期一致。这里要注意HAL_MPU_Enable的第二个参数MPU_PRIVILEGED_DEFAULT对应PRIVDEFENA位。置1后特权模式下访问没有被任何Region覆盖的地址默认放行不置1的话任何未覆盖的地址在特权模式下都会被拒绝访问。新手第一次配MPU最容易挂在这一步MPU使能后系统立刻死在启动早期因为VectorTable、栈、外设区全都还没配置Region。所以开发初期我建议把PRIVDEFENA置1等整体跑通了再按需收紧。3.4 优先级、异常使能与屏障指令的配合要让MPU违规能清晰暴露出来还需要打开MemManage Fault。默认情况下MemManage Fault如果未使能违规会上溢成HardFault虽然也能停住但信息可读性差很多。使能代码如下SCB-SHCSR | SCB_SHCSR_MEMFAULTENA_Msk;配置顺序建议是先使能MemManage Fault再使能MPU。如果反过来MPU先开而MemManage异常向量还没准备好一个微不足道的违规就会直接进HardFault调试时不容易分清是哪一步触发的。另外MemManage Fault本身是可配置优先级的中断级异常。如果在某个高优先级中断里访问了违规地址触发的是MemManage异常此时处理函数里不要做复杂操作。我习惯的做法是在MemManage_Handler里保存现场、记录当前PC和SP、设置一个全局错误标志然后进入安全状态或软复位。这样即使故障发生在中断上下文也能留下足够的现场信息用于事后分析。4. 实战场景三个我验证过的保护方案4.1 FreeRTOS 任务栈硬保护把栈溢出掐在发生点跑FreeRTOS最常见的隐性bug就是任务栈溢出。FreeRTOS自带两种溢出检测一种是在上下文切换时检查栈指针是否超出栈顶一种是往任务栈底填哨兵值定期检查。这两种方法都有局限要么依赖调度器及时检查要么过一段时间才能发现而且都只能告诉你好像溢出了没法告诉你具体是哪条指令、在哪个瞬间踩出去的。我用MPU做硬保护之后体验完全不一样。思路是给每个任务栈单独配一个RegionRegion大小按2的幂次对齐。比如任务栈实际大小为2KB我可以把Region配成4KB覆盖从栈顶向下的一段空间然后把多余的高位子区域禁掉让Region边界正好贴合栈的警戒线。一旦任务栈溢出向高地址方向增长就立刻触发MemManage FaultCPU在违规写入发生的那条指令处停下来现场保存完整。从工程实现上这套方案需要结合任务创建钩子为每个任务分配独立的Region编号。Cortex-M4只有8个Region如果任务数量太多可以不加区分地给所有任务栈统一配一个栈区Region——虽然没法定位到具体任务但至少能在溢出发生时立刻暴露问题比让系统继续带病运行强太多。我的经验是在开发调试阶段MPU栈保护能帮你把栈大小估算得特别准平均能省下不少RAM。4.2 Bootloader 与 App 隔离防止应用写坏引导区做过OTA的朋友都有这种经历App运行过程中如果误写了Bootloader区哪怕只是改了代码区里的一个字节都可能让整个设备变砖。这个问题用MPU解决非常优雅。做法是把Bootloader所在的Flash区域配成特权只读把App区域配成可读可写可执行。App正常运行时Bootloader区域不可写就算程序跑飞、指针被改到Flash地址越界写入也只会触发MemManage Fault而不会真正擦写引导区。等系统真正进入升级流程时再由Bootloader临时把区域权限调整回可写状态完成升级后再恢复。这个场景下需要注意一个细节很多芯片的Flash是分Bank的MPU的Region大小必须按2的幂次对齐如果Bootloader的Flash区域大小不是2的幂次就要结合实际情况裁掉不需要保护的子区域。同时中断向量表所在区域一定要保证可读可执行否则一旦触发中断CPU取中断向量时就可能被MPU拦下产生一连串连锁故障。4.3 外设寄存器与关键数据只读保护MCU系统里外设寄存器区通常占据0x40000000附近的一大块地址。一旦程序跑飞随便敲几个字很可能就把某个外设寄存器改了比如修改了时钟分频器、关了中断控制器、把某个GPIO口配置成错误模式外设状态变得完全不可控。把整个外设区配置成特权可读写、用户不可访问可以让普通任务的bug没法直接修改外设寄存器只有内核和特权代码才能操作硬件。关键数据的只读保护也类似。比如你有一张查表数据或者校准参数放在内部Flash里运行时不该被修改把这块区域配成只读。如果程序里有Bug往只读区域写入就会立刻触发MemManage Fault而不是默默地把Flash改坏。对现场维护来说这种出错立刻暴露的机制远比出错后继续运行、最后神秘复位要好排查。5. 常见问题与排查技巧实录5.1 配置了像没配置违规访问毫无反应遇到过好几次这种情况代码明明写了MPU配置但运行起来违规访问却没有任何反应。排查思路其实很固定。先看MPU-CTRL里的ENABLE位是不是1再看Region的ENABLE位是不是1最后确认AP权限是不是设置成了你想要的组合。如果这几项都对再看MemManage Fault有没有使能。没使能的情况下违规会变成HardFault如果你没在HardFault里打断点程序可能直接复位了看起来就像“没配置”一样。还有一个容易忽略的点很多RTOS在启动后会把当前任务切到用户模式非特权模式。如果你在特权模式下测试违规访问而配置里写的是用户不可访问那么特权模式访问是合法的自然不触发异常。所以测试时要确认当前到底跑在什么模式下不能想当然。5.2 一开 MPU 就 HardFault 的三种高频原因这个问题我几乎每次在客户现场都会遇到原因通常逃不出下面三种。第一PRIVDEFENA没置位。MPU开启后整个地址空间在特权模式下默认不可访问而你的程序初始化和中断向量访问都需要这些地址自然一跑就死。这种问题现象最猛解决办法也最简单使能MPU时把MPU_CTRL_PRIVDEFENA_Msk加上。第二Cortex-M7平台上Cache和MPU属性不匹配。如果你开了D-Cache但SRAM区域的Region属性没有配Cacheable数据访问行为就会变得奇怪尤其是DMA和CPU共用缓冲区时。我处理过好几个H7项目最后都是把共享内存的Region属性设为Non-cacheable或者显式做Cache Clean Invalidate问题才消失。第三漏配了中断控制器和外设寄存器区域。中断一来CPU要去取中断向量、访问NVIC和外设寄存器如果这些地址没有被任何Region覆盖且PRIVDEFENA没开就会被拒之门外导致连带故障。解决的办法是要么让PRIVDEFENA兜底要么把所有中断和外设可能访问的地址全部配上Region。我的调试套路是先把PRIVDEFENA置1让系统能跑起来然后逐个把需要保护的区域加进去每加一个就验证一次而不是一口气把8个Region全配完。这样一旦出问题能很快定位到是哪个Region的配置触发了故障。5.3 Region 不够用合并、裁剪、借用 backgroundCortex-M3/M4只有8个RegionM7 STM32 MPU内存保护实战：从原理到FreeRTOS任务栈保护
做嵌入式这几年我最大的感受是很多系统跑到半夜才复现的灵异故障最后排查下来都是内存踩踏。数组越界、栈溢出、野指针改写关键变量——在没有内存保护机制的时候MCU基本上是在裸奔状态里替你扛着所有bug。后来真正开始系统性地使用STM32里的MPUMemory Protection Unit内存保护单元才发现这东西不只是给航空航天或者汽车级项目准备的它在普通工控、物联网产品上同样能大幅提升系统的可维护性。这篇应用笔记我打算把STM32系列Cortex-M内核上的MPU从原理到实战完整捋一遍。包括MPU到底是什么、Region怎么配、权限怎么设、子区域怎么用再说说我在FreeRTOS任务栈保护、Bootloader隔离、外设寄存器保护这几个真实场景里的落地经验最后整理一份常见问题排查表。文章适合两类人一类是被内存踩踏坑到想从机制层面解决问题的嵌入式工程师另一类是刚接触MPU、想搞明白这个外设该在哪些项目里用起来的新手。不管你用的是F4、F7还是H7只要内核是Cortex-M3以上这套逻辑基本都是通用的。1. 先搞明白 MPU 到底是干什么的为什么这么重要1.1 没有内存保护时的 MCU 有多脆弱我先讲一个自己踩过的真实例子。之前做了一块STM32F407的主控板跑FreeRTOS系统运行几个小时偶尔会出现奇怪现象串口数据错乱、某个全局变量莫名被改、任务执行顺序不受控。一开始怀疑电源纹波怀疑外部干扰折腾了大半个月最后用软件排查才发现是某个任务里的局部数组越界把相邻的另一块内存给踩了。问题的根源在于MCU在没有内存保护机制时程序对内存的访问是没有任何边界的。你用C语言写一个数组下标越界写一个悬空指针在PC上可能立刻段错误但在MCU上不会。CPU根本不知道哪块内存属于谁只要地址总线上给出的地址能命中物理存储它就照单全收。于是越界写入的数据并不会当场报错而是静默地改写了别的变量、别的任务栈甚至是外设寄存器。这种bug最难查因为表象和根因往往隔着好几层等你找到根因现场早已经被破坏得面目全非。1.2 MPU 的本质一套内核级门禁规则MPU就是为这个问题设计的。它挂在Cortex-M内核内部由ARM架构统一提供不是ST为了卖芯片特意加的外设。它的工作方式可以类比成小区门禁程序运行时有特权模式内核、中断服务、RTOS内核代码通常跑在特权模式和用户模式普通任务一般跑在用户模式MPU就是根据当前模式来决定你能不能访问某块区域以及进去了能做什么事。关键点在于MPU的判断是纯硬件逻辑在每次内存访问的流水线阶段就完成匹配和权限校验配置好之后不会像软件Hook那样拖慢执行速度。只有访问真正违规时CPU才会触犯MemManage Fault异常把控制权交给异常处理函数。这意味着你可以把MPU长期打开当作系统的一道常驻防线而不用担心它带来明显的性能开销。我在多个项目里的体会是MPU最大的价值不在于防黑客而在于防自己。它能让你在程序刚越界的瞬间就停下来而不是等错误在内存里扩散了几个小时之后才爆发。对于中大型固件、RTOS多任务系统、OTA升级场景这个能力几乎是刚需。1.3 不同 STM32 内核的 MPU 能力差异STM32系列里Cortex-M3、M4、M7这些内核都内置MPU但入门级的Cortex-M0/M0没有选型的时候要留意。即使同样是带MPU的内核能力也有细微差别内核最大Region数备注Cortex-M38基础功能齐全Cortex-M48与M3基本一致Cortex-M716Region更多与Cache系统强关联Cortex-M7的MPU和M4有个重要差异M7的L1 CacheI-Cache和D-Cache的缓存策略是跟着MPU的Region属性走的。也就是说在H7系列上如果MPU配置不当可能不仅影响内存保护还会影响Cache行为甚至导致DMA和CPU之间的数据不一致。这一点后面实操部分会重点讲。如果你想确认手里的芯片到底支持几个Region可以直接读MPU-TYPE寄存器它的低8位表示硬件支持的Region数量。我通常会在初始化代码里把这个值打印出来方便在开发板上核对。2. MPU 的核心概念Region、子区域与权限属性2.1 Region连续地址的独立保护单位MPU的管理粒度是Region也就是一段连续的地址范围。配置一个Region需要三个关键参数起始地址、大小、访问权限。Region的大小有严格要求必须是2的整数次幂最小32字节最大可以到4GB。对应的SIZE字段值为 log2(大小) - 1。比如32字节SIZE 41KBSIZE 94KBSIZE 11512KBSIZE 18同时Region的基地址必须按大小对齐。比如你配置一个4KB的Region基地址必须是4KB的整数倍。0x20000000可以0x20000100就不行硬件的RBAR寄存器会直接忽略低位的对齐位行为不是你预期的。一段连续地址为什么要单独划成一个Region因为实际工程里的内存布局本来就是分块的Flash代码区、SRAM数据区、外设寄存器区、DMA缓冲区每块的访问需求不一样。代码区要只读可执行栈区要读写但用户态不能碰外设寄存器区最好只让特权模式访问。Region就是把这些差异化需求翻译成硬件规则的方式。2.2 子区域屏蔽多出来的空间可以精确扣掉每个Region可以被均匀分成8个子区域通过RASR寄存器里的SRD字段来控制每一位对应一个子区域置1表示禁用这个子区域。子区域屏蔽是MPU非常实用的功能它解决了一个很常见的矛盾地址空间里的保护对象往往不是整齐的2的幂次大小而MPU Region又要求按2的幂次对齐。举个例子。我有一块任务栈从0x20001000开始大小是2KB但我的数据区从0x20001800开始。如果我把2KB配成一个Region正好和栈重叠没有多余空间需要裁掉。但如果栈的实际使用区间不正好贴合Region大小我就需要调整策略。有一种常见做法是把Region扩大到4KB覆盖0x20001000到0x20002000然后把高2KB的4个子区域禁掉这样高位那部分地址虽然被Region覆盖但访问会被拒绝。只要子区域粒度够用就能用更大的Region去做精细裁剪从而节省Region槽位。2.3 AP 权限位与 TEX/C/B/S 属性位AP字段控制访问权限常用取值如下AP值特权模式用户模式0不可访问不可访问5只读只读6读写不可访问7读写只读实际项目里6用得最多比如栈区和关键数据区配成特权读写、用户不可访问代码区配成5只读防止程序跑飞后改写Flash里的代码。这里有个反直觉的点MPU的权限规则在特权模式和用户模式之间是有差别的但RTOS任务通常运行在用户模式还是特权模式取决于你给任务配置的CONTROL寄存器。如果你所有任务都在特权模式用户态的不可访问限制就形同虚设——所以要用好MPU最好配合非特权模式使用这也是很多RTOS的常见配置。TEX、C、B、S这四个位决定缓存和写缓冲策略。S代表ShareableC代表CacheableB代表Bufferable。在Cortex-M4上如果不涉及DMA和Cache保持默认值问题不大但在Cortex-M7上MPU的Region属性直接决定某块内存是否被D-Cache缓存、是write-back还是write-through配置错了会出现数据不同步的诡异问题。2.4 对齐规则最容易踩的那个坑关于对齐我多说两句因为它真的是踩坑重灾区。MPU要求基地址按Region大小对齐这个规则和很多外设DMA的要求类似。但不少人会为了省一个Region把两个本不相干的地址段强行合并成一个Region而这两段地址往往压根没有按2的幂次对齐于是Region配出来之后系统一跑到某个地址就触发MemManage Fault。我自己的习惯是每配一个Region之前先用address % size 0验算一遍。地址段如果太零碎宁可多用几个Region也不强行合并。Cortex-M4/M3只有8个Region看起来不多但实际项目里仔细规划通常够用。Region槽位是宝贵的资源它的规划应该和内存布局同步进行而不是等代码写完了再回头补。3. 从寄存器到 HAL 库一步步把 MPU 配起来3.1 动手之前必须先确认的三件事在实际写MPU配置代码之前有三件事建议先确认否则后面排查起来会很被动。第一确认芯片内核。M3/M4/M7才有MPUM0/M0没有。如果芯片不带MPU配置代码编译都会报错因为寄存器定义里根本没有MPU这个外设。第二确认自己的中断和异常向量表已经有了MemManage Fault处理函数。MPU违规会触发MemManage Fault如果这个异常向量没有定义系统会直接进HardFault甚至复位不利于排查。在使用CMSIS的工程里启动文件一般会自动把MemManage_Handler链接到一个弱定义但你要么在调试时把断点放在HardFault_Handler里要么自己实现MemManage_Handler。第三准备一个可以停在异常处理函数里的调试环境。头几次配置MPU几乎必然遇到一开MPU就进HardFault的情况。如果断点能停在异常现场直接看内核寄存器和CFSR定位会非常快。3.2 寄存器级完整配置示例Bootloader 与 SRAM 隔离我以STM32H743为例写一个比较典型的寄存器级配置。目标是把Bootloader所在Flash区域配成特权只读、用户可执行把SRAM配成特权读写、用户不可访问。这套配置在很多需要做OTA隔离的项目里可以直接用。#include stm32h7xx.h static void MPU_Config_Bootloader(void) { /* 1. 先关闭MPU配置过程不能被中断 */ MPU-CTRL 0U; __DSB(); __ISB(); /* 2. Region 0: Flash 0x08000000512KB特权只读用户只读可执行 */ MPU-RNR 0U; MPU-RBAR 0x08000000U; /* * SIZE字段: 512KB - log2(512*1024) - 1 18 * AP: 5 - 特权只读、用户只读 * XN: 0 - 可执行 * TEX0, C1, B0, S0 */ uint32_t rasr (18U MPU_RASR_SIZE_Pos) /* 大小 512KB */ | (5U MPU_RASR_AP_Pos) /* 只读 */ | MPU_RASR_C_Msk | MPU_RASR_ENABLE_Msk; MPU-RASR rasr; __DSB(); __ISB(); /* 3. Region 1: SRAM 0x20000000512KB特权读写用户不可访问 */ MPU-RNR 1U; MPU-RBAR 0x20000000U; rasr (18U MPU_RASR_SIZE_Pos) /* 大小 512KB */ | (6U MPU_RASR_AP_Pos) /* 特权读写 */ | MPU_RASR_ENABLE_Msk; MPU-RASR rasr; __DSB(); __ISB(); /* 4. 使能MPU特权模式下未命中Region的访问默认放行 */ MPU-CTRL MPU_CTRL_ENABLE_Msk | MPU_CTRL_PRIVDEFENA_Msk; __DSB(); __ISB(); }代码里每个寄存器写完后都加了DSB和ISB这件事很多人会忽略。原因在于MPU配置寄存器属于系统控制空间CPU在执行后续指令时不一定能立刻感知到这些寄存器的最新值。如果不加屏障指令可能出现配置完等于没配的情况尤其当你紧接着就去访问被保护的内存区域时。所以我的习惯是写完RNR/RBAR/RASR之后各加一次DSB全部配完使能MPU后再加一次DSB和ISB。AP字段的数值记不住没关系但要知道大概含义方便对着寄存器调试。5表示特权只读、用户只读6表示特权读写、用户不可访问7表示特权读写、用户只读。每种组合都有对应的使用场景配的时候要想清楚当前模式下的合法访问路径。3.3 用 HAL 库快速配置同一套方案如果你用CubeMX或者HAL库开发MPU配置会像填表一样直观。同样上面的需求用HAL库写出来是下面这样#include stm32h7xx_hal.h void MPU_Config_With_HAL(void) { MPU_Region_InitTypeDef MPU_InitStruct {0}; HAL_MPU_Disable(); /* Flash区域 0x08000000 512KB特权只读用户只读 */ MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.Number MPU_REGION_NUMBER0; MPU_InitStruct.BaseAddress 0x08000000; MPU_InitStruct.Size MPU_REGION_SIZE_512KB; MPU_InitStruct.SubRegionDisable 0x00; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL0; MPU_InitStruct.AccessPermission MPU_REGION_PRIV_RO_URO; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_ENABLE; MPU_InitStruct.IsShareable MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable MPU_ACCESS_CACHEABLE; MPU_InitStruct.IsBufferable MPU_ACCESS_NOT_BUFFERABLE; HAL_MPU_ConfigRegion(MPU_InitStruct); /* SRAM区域 0x20000000 512KB特权读写用户不可访问 */ MPU_InitStruct.Number MPU_REGION_NUMBER1; MPU_InitStruct.BaseAddress 0x20000000; MPU_InitStruct.AccessPermission MPU_REGION_PRIV_RW; HAL_MPU_ConfigRegion(MPU_InitStruct); HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT); }HAL库的好处是封装了一堆寄存器操作代码读起来像配置表可维护性高。但缺点也很明显不同系列芯片里的枚举名可能略有差异比如MPU_REGION_PRIV_RO_URO在某个头文件里可能不长这样编译不会报错但运行行为可能不对。我在用HAL库配完MPU之后一定会用调试器读一遍MPU-RBAR和MPU-RASR确认硬件寄存器里的实际值和预期一致。这里要注意HAL_MPU_Enable的第二个参数MPU_PRIVILEGED_DEFAULT对应PRIVDEFENA位。置1后特权模式下访问没有被任何Region覆盖的地址默认放行不置1的话任何未覆盖的地址在特权模式下都会被拒绝访问。新手第一次配MPU最容易挂在这一步MPU使能后系统立刻死在启动早期因为VectorTable、栈、外设区全都还没配置Region。所以开发初期我建议把PRIVDEFENA置1等整体跑通了再按需收紧。3.4 优先级、异常使能与屏障指令的配合要让MPU违规能清晰暴露出来还需要打开MemManage Fault。默认情况下MemManage Fault如果未使能违规会上溢成HardFault虽然也能停住但信息可读性差很多。使能代码如下SCB-SHCSR | SCB_SHCSR_MEMFAULTENA_Msk;配置顺序建议是先使能MemManage Fault再使能MPU。如果反过来MPU先开而MemManage异常向量还没准备好一个微不足道的违规就会直接进HardFault调试时不容易分清是哪一步触发的。另外MemManage Fault本身是可配置优先级的中断级异常。如果在某个高优先级中断里访问了违规地址触发的是MemManage异常此时处理函数里不要做复杂操作。我习惯的做法是在MemManage_Handler里保存现场、记录当前PC和SP、设置一个全局错误标志然后进入安全状态或软复位。这样即使故障发生在中断上下文也能留下足够的现场信息用于事后分析。4. 实战场景三个我验证过的保护方案4.1 FreeRTOS 任务栈硬保护把栈溢出掐在发生点跑FreeRTOS最常见的隐性bug就是任务栈溢出。FreeRTOS自带两种溢出检测一种是在上下文切换时检查栈指针是否超出栈顶一种是往任务栈底填哨兵值定期检查。这两种方法都有局限要么依赖调度器及时检查要么过一段时间才能发现而且都只能告诉你好像溢出了没法告诉你具体是哪条指令、在哪个瞬间踩出去的。我用MPU做硬保护之后体验完全不一样。思路是给每个任务栈单独配一个RegionRegion大小按2的幂次对齐。比如任务栈实际大小为2KB我可以把Region配成4KB覆盖从栈顶向下的一段空间然后把多余的高位子区域禁掉让Region边界正好贴合栈的警戒线。一旦任务栈溢出向高地址方向增长就立刻触发MemManage FaultCPU在违规写入发生的那条指令处停下来现场保存完整。从工程实现上这套方案需要结合任务创建钩子为每个任务分配独立的Region编号。Cortex-M4只有8个Region如果任务数量太多可以不加区分地给所有任务栈统一配一个栈区Region——虽然没法定位到具体任务但至少能在溢出发生时立刻暴露问题比让系统继续带病运行强太多。我的经验是在开发调试阶段MPU栈保护能帮你把栈大小估算得特别准平均能省下不少RAM。4.2 Bootloader 与 App 隔离防止应用写坏引导区做过OTA的朋友都有这种经历App运行过程中如果误写了Bootloader区哪怕只是改了代码区里的一个字节都可能让整个设备变砖。这个问题用MPU解决非常优雅。做法是把Bootloader所在的Flash区域配成特权只读把App区域配成可读可写可执行。App正常运行时Bootloader区域不可写就算程序跑飞、指针被改到Flash地址越界写入也只会触发MemManage Fault而不会真正擦写引导区。等系统真正进入升级流程时再由Bootloader临时把区域权限调整回可写状态完成升级后再恢复。这个场景下需要注意一个细节很多芯片的Flash是分Bank的MPU的Region大小必须按2的幂次对齐如果Bootloader的Flash区域大小不是2的幂次就要结合实际情况裁掉不需要保护的子区域。同时中断向量表所在区域一定要保证可读可执行否则一旦触发中断CPU取中断向量时就可能被MPU拦下产生一连串连锁故障。4.3 外设寄存器与关键数据只读保护MCU系统里外设寄存器区通常占据0x40000000附近的一大块地址。一旦程序跑飞随便敲几个字很可能就把某个外设寄存器改了比如修改了时钟分频器、关了中断控制器、把某个GPIO口配置成错误模式外设状态变得完全不可控。把整个外设区配置成特权可读写、用户不可访问可以让普通任务的bug没法直接修改外设寄存器只有内核和特权代码才能操作硬件。关键数据的只读保护也类似。比如你有一张查表数据或者校准参数放在内部Flash里运行时不该被修改把这块区域配成只读。如果程序里有Bug往只读区域写入就会立刻触发MemManage Fault而不是默默地把Flash改坏。对现场维护来说这种出错立刻暴露的机制远比出错后继续运行、最后神秘复位要好排查。5. 常见问题与排查技巧实录5.1 配置了像没配置违规访问毫无反应遇到过好几次这种情况代码明明写了MPU配置但运行起来违规访问却没有任何反应。排查思路其实很固定。先看MPU-CTRL里的ENABLE位是不是1再看Region的ENABLE位是不是1最后确认AP权限是不是设置成了你想要的组合。如果这几项都对再看MemManage Fault有没有使能。没使能的情况下违规会变成HardFault如果你没在HardFault里打断点程序可能直接复位了看起来就像“没配置”一样。还有一个容易忽略的点很多RTOS在启动后会把当前任务切到用户模式非特权模式。如果你在特权模式下测试违规访问而配置里写的是用户不可访问那么特权模式访问是合法的自然不触发异常。所以测试时要确认当前到底跑在什么模式下不能想当然。5.2 一开 MPU 就 HardFault 的三种高频原因这个问题我几乎每次在客户现场都会遇到原因通常逃不出下面三种。第一PRIVDEFENA没置位。MPU开启后整个地址空间在特权模式下默认不可访问而你的程序初始化和中断向量访问都需要这些地址自然一跑就死。这种问题现象最猛解决办法也最简单使能MPU时把MPU_CTRL_PRIVDEFENA_Msk加上。第二Cortex-M7平台上Cache和MPU属性不匹配。如果你开了D-Cache但SRAM区域的Region属性没有配Cacheable数据访问行为就会变得奇怪尤其是DMA和CPU共用缓冲区时。我处理过好几个H7项目最后都是把共享内存的Region属性设为Non-cacheable或者显式做Cache Clean Invalidate问题才消失。第三漏配了中断控制器和外设寄存器区域。中断一来CPU要去取中断向量、访问NVIC和外设寄存器如果这些地址没有被任何Region覆盖且PRIVDEFENA没开就会被拒之门外导致连带故障。解决的办法是要么让PRIVDEFENA兜底要么把所有中断和外设可能访问的地址全部配上Region。我的调试套路是先把PRIVDEFENA置1让系统能跑起来然后逐个把需要保护的区域加进去每加一个就验证一次而不是一口气把8个Region全配完。这样一旦出问题能很快定位到是哪个Region的配置触发了故障。5.3 Region 不够用合并、裁剪、借用 backgroundCortex-M3/M4只有8个RegionM7