AUTOSAR OS下MPU子区配置实战：从原理到DavinCi工具

MPU、子区这两个词在LAT1240平台上折磨了我大半个迭代周期。起因不复杂多核MCU上了AUTOSAR OS之后核间通信要共享内存任务栈和全局数据要隔离稍微越界一次轻则数据错乱重则看门狗复位。而这些需求落到最后几乎都要经过DavinCi Configurator里那一张张MPU配置表。老实说一开始我也没太把“子区”当回事觉得MPU嘛一个Region管一段内存不就行了直到手里的Region数量不够用才意识到子区这个机制有多关键。这篇文章我想把MPU子区这件事从头到尾讲清楚子区到底解决了什么问题、底层怎么映射到ARM MPU寄存器、在DavinCi Configurator里该怎么配、以及哪些坑是文档里不会写的。内容不算多但都是我在LAT1240实际项目里踩过、验证过的东西适合正在做AUTOSAR OS内存保护、或者被MPU Region数量逼疯的嵌入式工程师参考。1. 为什么内存保护需要“子区”这种细粒度划分1.1 LAT1240项目里的内存保护需求LAT1240是我们平台上的一颗车规级多核MCU跑的是AUTOSAR OS。这颗芯片上不是只有一个核在跑而是多个Core同时工作Core之间通过共享内存做核间通信。这就带来一个很直接的问题共享缓冲区不能随便让所有代码都写否则一个Core跑飞了另一个Core的通信数据全被冲掉排查起来非常痛苦。我们当时列了一下需要保护的内存对象大概有这几类各个Core的私有任务栈每个任务一个栈不能互相踩。OS内部数据结构比如就绪队列、调度器变量普通应用代码绝对不能碰。核间通信缓冲区多核共享但访问权限各核不同。外设寄存器空间只能由特定驱动访问。全局变量区不同OS Application之间要隔离。如果只看这个清单你是不是觉得给每一块内存配一个MPU Region不就行了问题是ARM的MPU Region数量是有上限的。像Cortex-R5这种比较常见的车规核Region数也就十几个到二十几个而我们要保护的内存段一数就是二三十个起步。更要命的是每个OS Application至少需要代码区、常量区、数据区、栈区四个Region任务一多Region数量根本不够分配。1.2 没有子区时Region数量才是最大的瓶颈我最早做内存保护方案时还没有仔细看子区功能完全是“一个保护对象对应一个Region”的思路。结果在DavinCi Configurator里配置OsApplication的时候Region表列得密密麻麻配置到一半就发现Region编号不够用了。有人可能会说Region数量不够那就减少保护粒度呗把几个任务栈合并到同一个Region里。乍一听好像合理但实际上很危险。任务栈合并后所有栈共享同一个Region的所有权限任何一个任务越界都能访问到另一个任务的栈底。内存保护的目的就是防止这种“越界穿透”如果不区分粒度保护等于形同虚设。这时候我才认真去看MPU的子区Sub-region机制。子区的思路很巧妙MPU硬件允许把一个Region内部再均分成8个更小的块每个块可以独立地决定是否处于“受保护/被禁用”状态。也就是说你只要用掉一个Region就能覆盖8个内存块Region利用率直接翻了8倍。1.3 子区的本质一个Region里的8个独立开关用一个生活化的类比来解释子区。想象你租了一个大仓库仓库管理员只给你一把总钥匙这个仓库可以看作一个Region。子区机制相当于仓库里那8排货架每一排都单独装了一个锁你可以只开放其中几排其他几排禁止任何人进入。货架就是子区而总钥匙就是Region的使能状态。但这里有一个很重要的限制8个子区共享同一个Region的访问属性。什么意思比如你在一个Region里配置了“只读”权限那它内部的8个子区全都是只读的不能做到“前4个子区可读写、后4个子区只读”。子区的灵活性只体现在“使能/禁用”这个维度上不能在同一Region内做不同的权限设置。权限不同的话仍然要拆成多个Region。我之前就吃过这个亏想在一个Region里同时隔离读区和写区配了半天都不对后来查参考手册才发现子区就没有“独立设置权限”的能力。这个认知很重要尤其在做区域划分时先把“哪些区域权限相同但物理地址不连续”归类才能用好子区。2. 子区机制底层原理一个Region如何变成8个子区2.1 SRD位子区使能的“开关”ARM的MPU实现中每个Region的配置寄存器里有一个字段叫SRD全称是Sub-Region Disable。这个字段占8个bit每个bit对应一个子区。名字太有迷惑性了它是“Disable”位不是“Enable”位。具体含义是SRD的bit n 为 0子区 n 正常使能参与MPU访问控制。SRD的bit n 为 1子区 n 被禁用这部分地址区域相当于不归属于当前Region管辖。举个例子如果我想让一个Region内前2个子区有效后6个子区不参与管理那SRD掩码就是0b11111100十六进制写作0xFC。反过来如果想禁用前3个子区、使能后5个掩码就是0b00000111即0x07。这个“0代表使能、1代表禁用”的设计我一开始记反了导致配置出来的效果完全不对。后来给自己总结了一个记忆方式SRD的全称是Disable所以SRD位为1的部分是“被Disable掉”的部分这样就不会弄错了。2.2 地址对齐与子区粒度的硬性约束子区不是随便切的它必须满足几个硬件级的约束。第一Region总大小必须是2的幂次方。比如1KB、2KB、4KB、8KB不能配置一个3KB的RegionMPU不认。第二Region的基地址必须对齐到Region大小。一个4KB的Region基地址最低4KB对齐一个8KB的Region基地址最低8KB对齐。这两个条件不满足Region配置可能被硬件忽略或者产生不可预料的异常行为。第三子区大小由Region大小唯一决定。一个Region被均分成8份所以子区大小 Region大小 / 8。比如Region大小配置为4KB子区就是512B配置为8KB子区就是1KB。这就意味着Region越大子区的粒度就越粗。想精细控制小内存块反而要把Region配小一点。这里有个现实矛盾。有的共享内存块可能只有几百字节而我们希望子区粒度更细那Region大小就要选小。但是Region的总大小又必须覆盖整块需要保护的内存。如果你的共享区是6KB而Region只能配2的幂次方大小那就得选8KB的Region子区粒度变成1KB没法精细保护6KB内的每一段。这种情况下可能需要拆成多个Region或者用子区覆盖一部分、再配合其他机制兜底。2.3 用真实参数算一遍4KB Region拆8个子区我在LAT1240上做的第一个子区实验就是用一颗4KB的共享内存块做测试。Region大小设为4KB基地址选择4KB对齐的0x1000那么内部8个子区的地址范围是子区编号地址范围SRD bit位子区00x1000 - 0x11FFbit0子区10x1200 - 0x13FFbit1子区20x1400 - 0x15FFbit2子区30x1600 - 0x17FFbit3子区40x1800 - 0x19FFbit4子区50x1A00 - 0x1BFFbit5子区60x1C00 - 0x1DFFbit6子区70x1E00 - 0x1FFFbit7如果我想让这个Region只保护前2个子区即0x1000-0x13FF那后6个子区都应该被禁用SRD掩码就是bit6到bit1全为1即0b11111100 0xFC。反过来如果我只需要保护最后4个子区SRD掩码就是bit3到bit0全为10b00001111 0x0F。这样的计算在多核共享场景中特别有用。比如Core0和Core1共用4KB缓冲区前面2KB是Core0的发送区后面2KB是Core1的接收区。每个Core可以配置同一个4KB Region但Core0侧使能前4个子区、禁用后4个子区Core1侧使能后4个子区、禁用前4个子区。这样两个Core看到的是同一个物理区域但MPU权限恰好覆盖到自己关心的那半块。在配置时一定要记住子区掩码是对Region整体而言的不同Core或不同OS Application引用的同一个RegionSRD掩码可以不一样。这一点正是子区机制最灵活的地方。3. Davinci Configurator里配置MPU子区的完整操作3.1 配置前需要准备的三件事在DavinCi Configurator里动手配置之前我建议先把三样东西准备好否则一边点界面一边查资料效率太低。第一内存映射表。把芯片的内存地址空间按用途列一遍包括Flash代码区、RAM数据区、共享内存区、外设寄存器区每一段标清楚起始地址和结束地址。第二Region分配表。结合MPU的Region数量上限把每个Region预分配给某类内存对象标出Region大小、基地址、访问权限、归属的OS Application。这个表是MPU配置的核心配置界面里的每一行基本就是照抄这个表。第三权限矩阵。明确哪些Application能访问哪些内存区是读还是写还是可执行。没有权限矩阵到了配置界面会不知道怎么填Access Permission字段。我当时就是先画了三张表然后才打开DavinCi Configurator整个过程顺畅了很多。如果直接上手点配置一个Region配到一半发现权限不对、地址重叠回头修改的代价很高。3.2 一步步创建MPU内存区域DavinCi Configurator配置OS MPU的大致路径是通过Os模块下的Memory Protection相关页面。新版工具里入口一般是Os - OsApplication选中某个Application后能看到它的Memory Protection配置项。具体菜单名称在不同版本里会有出入但核心配置项是稳定的。我的操作步骤大致是这样的在OsApplication列表里为每个Core创建对应的Application比如OsApp_Core0、OsApp_Core1并设置Trusted/Untrusted属性。受MPU保护的应用通常配成Untrusted。进入指定Application的Memory Region配置页面新增一个MemoryRegion。填写Region名称建议起一个能自解释的名字比如MpuRegion_SharedBuf_Core0。填写Region的起始地址Start Address和大小Size。这里必须严格满足2的幂次方和对齐要求。设置访问权限包括读、写、执行属性以及User/Privileged权限位。如果目标地址区间需要用到子区找到Sub-Region相关的配置字段通常是一个8bit的掩码按上面算好的SRD值填入。这里要提醒一个容易忽略的点在DavinCi里同一个物理内存区可能被多个Application引用比如共享内存。每个Application都要单独建一个MemoryRegion然后各自填不同的SRD掩码。不要指望配置一个Region就被所有App自动共享AUTOSAR OS的内存保护模型是以Application为单位的。3.3 子区使能与SRD掩码的配置逻辑子区掩码在DavinCi里出现的字段名不同版本之间不完全一样。我见过OsMemoryRegion下直接叫SubRegionDisableMask的也见过在底层MCU相关配置模块里出现的类似字段。本质都是填一个8bit的数值。填值的时候有个小技巧。先把二进制的8个bit画出来哪个子区要禁用哪个bit就置1然后整体转成十六进制。比如前4个子区使能、后4个禁用二进制就是0b00001111十六进制0x0F。直接心算很容易把bit位置写反。在我们的项目里配置共享缓冲区时Core0侧的Region掩码填0x0FCore1侧的Region掩码填0xF0形成正好相反的保护范围。这个对称配置看起来清爽逻辑也清楚出现问题的时候一眼就能看出哪一侧配置错了。还有一点DavinCi Configurator里有些高级配置项默认是隐藏的子区掩码这类字段可能不会直接展示。我当时是在工具界面的View菜单里打开了高级配置显示才看到完整的字段列表。如果你在界面上找不到子区相关字段先确认一下高级模式是否已经打开。3.4 生成代码后如何核对SRD值DavinCi的配置最终会生成C代码AUTOSAR OS底层的MPU初始化用的就是这些配置数据。我不会完全信任界面上的数字生成代码后一定会去生成的C文件里核对一遍SRD值。在生成的代码里通常能找到类似Os_RegionConfig的数组每个元素对应一个MemoryRegion配置。里面会有一个字段保存SRD掩码和我们在界面上填的值应该一致。拿3.3节的例子来说Core0侧应该是0x0FCore1侧应该是0xF0。核对完代码之后我还会在调试器里做一次现场确认。程序运行到OS初始化完成、MPU配置生效后通过调试器直接读MPU的Region寄存器看SRD位是否和预期一致。这一步能排除“配置生成了但硬件没生效”的情况。有个小插曲我们有一块内存的Region大小是4KB但调试器显示出来的生效地址范围是8KB排查半天发现是DMA配置把邻接的地址段写乱了误触发了MPU错误。所以我说不要只盯着工具界面代码和硬件寄存器两个层面的核对都能帮你少走很多弯路。4. 子区配置中的四个高频坑4.1 坑一基地址不对齐导致的静默失效子区配置失败最常见的原因不是SRD掩码填错而是Region的基地址没有对齐到Region大小。比如你要配一个8KB的Region基地址填成了0x1000但8KB对齐要求基地址至少能被0x2000整除。0x1000虽然也是对齐的但只是4KB对齐不是8KB对齐。硬件遇到这种不对齐的配置行为通常是静默忽略不报错也不提示。你会在调试中发现某个内存区域的MPU保护完全没有生效数据乱写都不会触发异常。排查半天最后发现是基地址少对齐了一个等级。我推荐的做法是配置前手动算一遍Region大小对应的对齐边界用脚本或者计算器把每个Region的地址除以对应大小能整除再往DavinCi里填。不要依赖目测内存地址这种十六进制数肉眼几乎看不出对齐关系。4.2 坑二Region大小与子区划分的逻辑错位第二个坑是我自己踩过的。我要保护一块6KB的共享内存但Region大小必须是2的幂次方所以选了8KB。8KB的Region拆成8个子区每个子区是1KB而我的6KB共享内存无法被1KB子区均匀覆盖最后一块区域只有部分被保护剩余2KB落到了下一个Region的权限范围内。如果子区粒度不够精细不要硬凑。可以考虑把6KB共享内存拆成“4KB 2KB”两块分别配两个Region或者调整内存布局把共享区规划成4KB或8KB的整数倍使子区可以整齐覆盖。我后来在内存布局阶段就把所有需要保护的块对齐到子区粒度的整数倍避免后期在配置阶段亡羊补牢。4.3 坑三多个Region覆盖时优先级把子区设置“冲掉”MPU允许不同的Region拥有重叠的地址范围。当两个Region重叠时硬件会按照优先级决定哪一个Region的访问权限生效。多数ARM核的规则是Region编号越大优先级越高。这就带来一个隐蔽的问题你以为某个子区已经被禁用了但实际上该地址范围同时被另一个高优先级Region覆盖而且那个Region没有禁用子区于是访问依然被允许。我当时在保护共享缓冲区时给共享区配置了一个Region同时另一个任务栈的Region不小心覆盖了同一段地址。结果栈的Region优先级更高把共享区的子区禁用功能完全架空。排查很久才发现是Region重叠导致优先级冲突。避开这个坑的方法是在Region分配表里明确标注每个Region的地址范围并检查所有Region之间是否存在重叠。如果确实需要重叠那就必须搞清楚硬件优先级规则确保低优先级Region不会覆盖高优先级Region的意图。4.4 坑四任务切换时MPU重配的时序问题AUTOSAR OS在任务切换时可能会根据需要重新加载MPU配置以便当前任务只看到自己有权访问的内存区域。如果子区配置和OS调度器的行为配合不好容易出现两个问题。第一个问题是在任务切换的瞬间MPU配置处于中间状态此时新任务还没有完全切换到自己的Region集而旧任务的Region已经被卸载访问任何内存都可能触发MPU异常。这种情况多发生在我们把Region配置成仅适用于某个任务级别的时候。第二个问题是某些OS内部代码在MPU重配后仍然访问已经被禁用的子区。比如OS的hook函数、中断服务例程中访问了某个共享缓冲区但该缓冲区在当前任务的MPU配置里恰好被禁用就会触发权限错误。我们当时的做法是把OS内部和中断需要访问的共享区域放在一个始终使能的基础Region集中并在子区配置中只禁掉纯应用层不应当访问的部分。这样可以避免调度器内部访问被MPU拦截。5. 实战用MPU子区隔离核间通信缓冲区5.1 需求拆解一个真实的多核共享内存案例LAT1240上有两个Core需要通过共享内存交换消息。共享区物理上是一块连续的SRAM地址范围是0x30000000到0x30000FFF共4KB。两个Core都要访问这块内存但权限要区分Core0可以读写前2KB后2KB只读Core1可以读写后2KB前2KB只读。为什么这么设计因为前2KB主要存放Core0给Core1的控制指令Core1只需要读取和执行后2KB是Core1返回给Core0的状态数据Core0只需要读取。如果两边都能乱写一旦某个Core的代码跑飞整个通信区就毁了。如果用传统方法这个需求至少要两个Region一个覆盖前2KB一个覆盖后2KB而且两个Region的地址范围还不是2的幂次方对齐的。如果通过子区来做配置一个4KB的Region然后通过SRD掩码分别对两个Core做不同的使能设置一个Region就全搞定了。5.2 子区划分表设计我在配置前先画了一张划分表基本按这个表往DavinCi里填配置项Core0侧RegionCore1侧RegionRegion名称MpuRegion_Shared_Core0MpuRegion_Shared_Core1起始地址0x300000000x30000000Region大小4KB4KB子区大小512B512B使能的子区0,1,2,3前2KB4,5,6,7后2KBSRD掩码0xF0禁用bit4-70x0F禁用bit0-3访问权限可读写可读写这里注意每个Core侧配置的SRD掩码都是针对同一个物理Region的但掩码值相反。Core0侧禁用后4个子区所以SRD是0xF0Core1侧禁用前4个子区SRD是0x0F。5.3 配置与验证的关键步骤按照上面的表在DavinCi Configurator里新建两个MemoryRegion一个挂在OsApp_Core0下一个挂在OsApp_Core1下分别填入对应的起始地址、大小、访问权限和SRD掩码。配置完成后生成代码到生成的Os_Cfg相关文件中核对两个Region的SRD字段。然后烧录到LAT1240上在调试器里检查MPU的Region寄存器确认SRD位和预期一致。验证阶段我用了一个很土但很有效的测试方法让Core0的某段代码故意向前2KB和后2KB各写一个特定数据。写前2KB应该正常写后2KB应该触发MPU异常。如果异常如期触发说明Core0侧的MPU配置确实只允许访问前2KB。Core1侧也做同样的反向验证。这种“故意越界”的验证方式建议在项目开发阶段保留在测试代码里不要等到集成测试时才想起来验证MPU行为。MPU一旦配置错了问题往往不会立刻暴露而是在某个极端时序下才出异常到时候排查成本非常高。6. 写在最后子区配置的几点经验6.1 子区是一把“手术刀”不是万能刀用子区能解决Region数量不够的问题但不要迷信子区。它有两个天然限制所有子区共享同一个Region的访问属性和缓存策略Region大小必须是2的幂次方导致子区粒度是固定阶梯的。如果一个场景里需要不同的访问权限或者地址块不是整齐的2的幂次方划分子区就帮不上忙还是要规规矩矩拆多个Region。我的原则是能用子区覆盖的就用子区覆盖不了的果断拆Region别为了省Region数量把配置搞得很复杂最后维护成本反而更高。6.2 我常用的调试三板斧第一板斧在DavinCi生成代码后先静态核对Region配置结构体里的SRD值不急着上板。第二板斧上板后打开调试器在OS启动完、MPU生效后检查MPU寄存器组的实际值重点看SRD位和Region数量是否和预期一致。第三板斧写一个临时的越界测试用例故意访问禁用子区观察是否能触发MPU异常。能触发说明配置有效没触发说明保护形同虚设继续往前查。这三板斧组合用下来MPU配置的调试效率会高很多。以前我只看界面或只看代码碰到配置不生效的问题常常要折腾一两天现在基本半小时内定位。6.3 扩展思考多核场景下的子区规划多核MCU上子区的规划不能只看单个Core的需求还要从全局考虑。比如多个Core都要访问同一块共享内存时建议每个Core的Region配置里SRD掩码保持一致避免不同Core对同一内存块出现不一致的保护视图。此外多核平台常涉及DMA和外设访问。DMA不经过CPU的MPU所以MPU子区保护不了DMA操作。如果共享缓冲区同时被DMA访问还要在DMA控制器侧配置相应的保护策略不要以为MPU配好了就万事大吉。这也是我在LAT1240项目后期才深刻体会到的一点。最后再分享一个小技巧。配置子区掩码时与其用十六进制心算不如直接写二进制注释。在DavinCi的配置描述或生成的代码注释里把SRD掩码写成0b00001111这种形式后来的人一眼就明白哪些子区是使能的。代码是写给人看的配置表也是。这种小习惯在项目迭代久了以后价值非常大。