做嵌入式这几年，我最大的感受是：很多系统跑到半夜才复现的"灵异故障"，最后排查下来都是内存踩踏。数组越界、栈溢出、野指针改写关键变量——在没有内存保护机制的时候，MCU基本上是在裸奔状态里替你扛着所有bug。后来真正开始系统性地使用STM32里的MPU（Memory 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-M3 | 8 | 基础功能齐全 |
| Cortex-M4 | 8 | 与M3基本一致 |
| Cortex-M7 | 16 | Region更多，与Cache系统强关联 |
Cortex-M7的MPU和M4有个重要差异：M7的L1 Cache（I-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 = 4
- 1KB，SIZE = 9
- 4KB，SIZE = 11
- 512KB，SIZE = 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代表Shareable，C代表Cacheable，B代表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才有MPU，M0/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 0x08000000，512KB，特权只读，用户只读，可执行 */ MPU->RNR = 0U; MPU->RBAR = 0x08000000U; /* * SIZE字段: 512KB -> log2(512*1024) - 1 = 18 * AP: 5 -> 特权只读、用户只读 * XN: 0 -> 可执行 * TEX=0, C=1, B=0, S=0 */ 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 0x20000000，512KB，特权读写，用户不可访问 */ 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做硬保护之后，体验完全不一样。思路是给每个任务栈单独配一个Region，Region大小按2的幂次对齐。比如任务栈实际大小为2KB，我可以把Region配成4KB，覆盖从栈顶向下的一段空间，然后把多余的高位子区域禁掉，让Region边界正好贴合栈的警戒线。一旦任务栈溢出向高地址方向增长，就立刻触发MemManage Fault，CPU在违规写入发生的那条指令处停下来，现场保存完整。
从工程实现上，这套方案需要结合任务创建钩子，为每个任务分配独立的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 不够用？合并、裁剪、借用 background
Cortex-M3/M4只有8个Region，M7
