做STM32L071的IAP升级最烦的不是协议而是Flash本身的脾气。我第一版代码写得很“理所当然”应用程序在0x08000000跑着然后调用HAL库直接去擦自己所在bank的页结果一进擦除函数设备当场死机看门狗连喂的机会都没有。查了一圈文档和社区案例才发现这是STM32L071双bank Flash的intra-bank write/erase行为在捣鬼。这个标题看着像芯片手册里一个干巴巴的小节名实际踩过坑的人都知道它背后藏着一整类“Flash自编程”的设计约束。这篇我打算把STM32L071的双bank结构、intra-bank写/擦行为、以及绕过这个限制的几种工程做法一次讲透适合正在做IAP、OTA或者应用自更新的朋友参考。1. STM32L071的双bank Flash架构与地址映射1.1 两个bank怎么分、容量多大STM32L071的常见Flash配置是128KB内部被切成两个独立的bank每个bank 64KB。地址划分非常规整存储区地址范围容量Bank 00x08000000 ~ 0x0800FFFF64KBBank 10x08010000 ~ 0x0801FFFF64KB页大小128字节每个bank有512页。也就是说擦除的最小单位是128字节而bank是独立的擦写调度单元。有一个容易忽略的点不是所有L0系列芯片都有双bank。像STM32L011、L031这些小容量型号Flash只有16KB~32KB是单bank结构。只有L071、L072、L073、L081、L082、L083这些128KB至192KB容量的型号才具备双bank。所以做设计选型时一定要看完整Part Number不能光看系列名就默认有双bank。1.2 RWW能力为什么inter-bank操作这么舒服双bank带来的最大价值就是RWWRead-While-Write也就是“读时写”或者“写时读”。当CPU从Bank 0取指执行同时Flash控制器对Bank 1做编程或擦除两个bank各自用各自的接口互不干扰。这个特性用在IAP上非常舒服。典型的做法是Bootloader放在Bank 0应用程序放在Bank 1。Bootloader在Bank 0里运行需要升级应用时直接擦写Bank 1、把新固件写入Bank 1整个过程CPU一直在Bank 0正常取指执行不存在任何阻塞。这也是为什么很多用L071做产品的人最终选择了“Bootloader App”这种经典架构。不是因为它新潮而是这种架构恰好踩在芯片硬件的能力边界内把intra-bank问题直接绕开了。1.3 和单bank芯片的本质差异单bank芯片没有RWW能力。CPU请求指令、读取数据全都要经过Flash总线而编程/擦除操作一旦启动Flash总线就被擦写逻辑占住读请求全部被挂起。所以单bank芯片做IAP时Flash擦写函数必须搬到RAM里执行没有别的选择。而STM32L071这种双bank芯片理论上可以有“半个Flash在忙、另外半个Flash还能读”的福利。但请注意这个福利只在“擦写目标bank ≠ 代码执行bank”时成立。当你对当前正在执行代码的那个bank发起写/擦芯片的行为立刻退化成单bank状态甚至比单bank更危险。这个退化的本质就是标题里的intra-bank问题。我画个简单的行为对照表方便一眼理解代码从哪里取指擦写目标结果Bank 0Bank 0卡死 / NMI不允许Bank 0Bank 1正常RWW生效Bank 1Bank 0正常RWW生效Bank 1Bank 1卡死 / NMI不允许RAMBank 0 或 Bank 1都正常这张表建议直接贴在工位上。我后来所有Flash操作代码都会先对照这张表确认“我现在在哪取指、我要动哪块”再决定调用方式。2. intra-bank写/擦行为为什么程序会在自己家门前踩空2.1 取指与数据访问的双重阻塞要理解intra-bank为什么卡死先要理解CPU的执行模型。Cortex-M0核心每一个时钟周期都需要取指令如果指令来自Flash那么Flash接口必须持续提供取指数据。当Flash控制器收到一条擦除或编程命令并且操作目标是当前取指的bank时整个bank的存储阵列都进入busy状态。此时不管是取指还是数据读取来到这个bank的读请求都会被无限期挂起直到擦写完成。问题在于擦写流程本身也需要CPU执行代码来启动和轮询。如果CPU执行代码的bank正是被擦写的bank那它就永远等不到擦写完成——因为等指令的核和写Flash的控制器在同一个bank上“死锁”了。这就是“自锁”的本质。更隐蔽的是数据访问。有些朋友把Flash操作函数搬到了RAM心想这总该没事了吧结果还是卡死。为什么因为他们编译的程序里const常量、字符串字面量、甚至编译器生成的跳转表仍然存放在Flash里。擦写Bank 0期间代码里某个printf格式字符串恰好放在Bank 0CPU去读这个字符串读请求一样被挂起。所以RAM执行方案绝不是“把函数丢到RAM”就完事还要保证这个函数及其依赖的数据都不落在目标bank。2.2 从“卡死”到NMI的连锁反应L0系列的Flash控制器对这种情况并不是毫无保护。当它探测到CPU在访问一个正在编程/擦除的bank时会尝试通过NMI不可屏蔽中断来打断CPU避免总线无限期死锁。但这里有个很讽刺的闭环NMI_Handler默认也放在Flash里。如果触发的NMI的handler本身就在被锁定的bank中处理器跳进NMI_Handler后又要从同一个bank取指结果是二次死锁。所以你在现场看到的现象会很分裂有的是复位、有的是“卡死在NMI_Handler”、有的是看门狗超时复位、有的干脆系统无响应。这些表象后面根因都是同一个intra-bank访问。我在早期调试时用调试器看PC指针发现它停在0x0800xxxx的NMI_Handler地址当时还以为是程序跑飞了。后来对照参考手册的NMI生成条件才明白是Flash接口主动拉起了NMI。这一步认知非常关键——不要浪费时间去查栈、查指针先确认是不是动了正在执行的bank。2.3 一个反直觉的细节不是只有“擦自己正在跑的页”才死这里有一个绝大多数新手都会误解的点以为“我擦的页和当前执行的页不是同一页就安全了”。但在同一个bank内部擦写任意一页整片bank的存储阵列都处于busy状态。哪怕你在0x08000000执行去擦0x0800FF00同一个bank最后一页同样死锁。打个比方银行是一个bank一个bank营业的你人在Bank 0的柜台前办业务结果整个Bank 0的营业网点停电了那你在哪张椅子上坐着都不好使。银行网点是整个关门不是只关某一个窗口。这意味着intra-bank写/擦行为约束的是“bank”这个粒度不是“页”这个粒度。判断安全性的唯一标准就是操作目标bank和CPU正在取指的bank是不是同一个。是同一个就有风险不是同一个页的位置无所谓。3. 绕过intra-bank限制的三种实战路径3.1 路径一把Flash操作函数搬进RAM执行这是单bank时代就有的经典做法在L071上同样适用而且处理得当非常可靠。核心原理很简单CPU从RAM取指RAM走的是另一个存储接口Flash擦写时不涉及RAM的读请求所以两条通路不会打架。具体实施分三件事把Flash操作函数放到自定义段、在调用前拷贝到RAM、用函数指针调用。先看函数定义我用寄存器操作写一个页擦除函数并放到.ramfunc段__attribute__((section(.ramfunc), noinline)) void Flash_PageErase_RAM(uint32_t page_addr) { /* 等上一次Flash操作完成 */ while (FLASH-SR FLASH_SR_BSY); /* 如果Flash被锁先解锁 */ if (FLASH-PECR FLASH_PECR_PELOCK) { FLASH-PEKEYR 0x89ABCDEF; FLASH-PEKEYR 0x02030405; } /* 页擦除模式 */ FLASH-PECR | FLASH_PECR_PER; FLASH-AR page_addr; FLASH-PECR | FLASH_PECR_STARTR; /* 等待操作完成 */ while (FLASH-SR FLASH_SR_BSY); /* 清除完成标志和错误标志 */ FLASH-SR | FLASH_SR_EOP | FLASH_SR_WRPERR | FLASH_SR_PGAERR | FLASH_SR_SIZERR | FLASH_SR_OPTVERR; /* 退出擦除模式 */ FLASH-PECR ~FLASH_PECR_PER; }链接脚本里需要把.ramfunc段放到RAM区域并且记录加载地址和运行地址。用GCC工具链时可以在linker script中加.ramfunc : { . ALIGN(4); __ramfunc_flash_start LOADADDR(.ramfunc); __ramfunc_vtor_start .; *(.ramfunc) __ramfunc_vtor_end .; . ALIGN(4); } RAM AT FLASH然后在使用前把这段代码从Flash拷贝到RAMextern uint32_t __ramfunc_flash_start; extern uint32_t __ramfunc_vtor_start; extern uint32_t __ramfunc_vtor_end; void Flash_PageErase(uint32_t page_addr) { /* 拷贝RAM执行函数到RAM */ uint8_t *src (uint8_t *)__ramfunc_flash_start; uint8_t *dst (uint8_t *)__ramfunc_vtor_start; uint32_t len (uint32_t)__ramfunc_vtor_end - (uint32_t)__ramfunc_vtor_start; memcpy(dst, src, len); /* 通过函数指针调用RAM中的函数 */ void (*erase_func)(uint32_t) (void (*)(uint32_t))dst; erase_func(page_addr); }这里有个细节值得提醒Cortex-M0只支持Thumb指令所有RAM函数地址的最低位会被处理器当作Thumb位处理。我们的函数是普通C函数编译出来就是Thumb代码所以直接用函数指针调用没有问题不需要手工设置最低位。函数内还要注意不能引用Flash中的常量。比如不要在擦除函数里放一个查表数组或者printf格式字符串那些数据一旦落在被擦除的bank里一样会卡死。把这个函数做成“自包含”只操作寄存器、栈变量和参数最安全。3.2 路径二双bank A/B分区IAP天然避开intra-bank如果不想和RAM执行方案纠缠可以考虑A/B分区设计。思路是把Bank 0和Bank 1各当一个完整的“固件槽位”系统启动时选择一个槽位执行升级时去擦写另一个槽位。这个方案在L071上可行但有一个要注意的坑L071没有L4系列那种硬件bank swap寄存器。L4可以通过SYSCFG寄存器把两个bank对调L071没有这个能力所以“切换启动”必须用纯软件方式完成。设计大概长这样Bootloader放在Bank 0起始位置或者每个镜像头部都放一段启动引导逻辑。固件头部记录版本号、校验值、长度信息。上电后Bootloader检查升级标志和两个bank的固件头选择有效的那个跳转过去。升级流程在运行时把新镜像写入非当前bank写完后更新标志复位后从新bank启动。A/B分区的好处很明显整个升级过程当前运行bank和写入目标bank始终不同全程RWW根本不会触发intra-bank问题。而且升级失败后可以回滚到旧版本鲁棒性强。代价是固件需要做分区设计两个bank各留多少给镜像、公共数据放哪里、升级标志存哪儿。这些都是在规划阶段就要定好的不能等到代码写完再拍脑袋。3.3 路径三Bootloader在Bank 0、应用在Bank 1的经典RWW组合这是最省心的组合也最推荐大多数产品先采用。思路很简单Bootloader固定在Bank 0应用固定在Bank 1。Bootloader启动后从Bank 1加载应用并跳转应用想升级时设置升级标志并复位Bootloader检查到标志后在Bank 0里执行擦除Bank 1、接收新固件、写入Bank 1完成后跳转。整个过程里Bootloader一直运行在Bank 0擦写目标一直是Bank 1属于标准inter-bank操作完全安全。应用自身不需要做任何Flash擦写只需要提供“复位进入Bootloader升级”的机制。这个方案的局限性在于Bootloader本身很难通过自身来升级。如果Bootloader有严重Bug或者你想更新引导逻辑就得借助外部调试器或RAM执行方案。对多数产品来说Bootloader更新频率极低这个风险可以接受。3.4 三种方案的选择逻辑方案是否需要RAM执行是否需要分区复杂度适合场景RAM执行是否中单镜像自更新代码结构简单A/B双bank否是高OTA要求高、需要回滚BootloaderApp否部分中经典IAP性价比最高我个人建议做量产产品优先考虑方案三如果产品有远程升级需求、且必须要断点续传和高可靠性再上方案二方案一作为临时救急或者单bank芯片的通用手段来掌握。4. L071 Flash操作的关键时序与状态位检查不管用哪种路径最终都要面对Flash控制器本身的规矩。L0系列的Flash操作有几个硬性要求忽略任何一个都会踩坑。4.1 编程最小单位64位double word的对齐要求L0系列Flash编程不是按字节、也不是按字32位写入而是按双字64位为一个编程操作单位。你必须一次写两个连续的32位数据而且起始地址必须8字节对齐。如果地址不对齐FLASH_SR里的PGAERR编程对齐错误会被置位写入失败。写一个双字编程函数仍然放在RAM执行__attribute__((section(.ramfunc), noinline)) void Flash_ProgramDoubleWord_RAM(uint32_t addr, uint64_t data) { uint32_t lo (uint32_t)(data 0xFFFFFFFF); uint32_t hi (uint32_t)(data 32); while (FLASH-SR FLASH_SR_BSY); if (FLASH-PECR FLASH_PECR_PELOCK) { FLASH-PEKEYR 0x89ABCDEF; FLASH-PEKEYR 0x02030405; } /* 进入编程模式 */ FLASH-PECR | FLASH_PECR_PROG; /* 写第一个32位再写第二个32位 */ *(__IO uint32_t *)addr lo; *(__IO uint32_t *)(addr 4) hi; while (FLASH-SR FLASH_SR_BSY); FLASH-SR | FLASH_SR_EOP | FLASH_SR_WRPERR | FLASH_SR_PGAERR | FLASH_SR_SIZERR | FLASH_SR_OPTVERR; /* 退出编程模式 */ FLASH-PECR ~FLASH_PECR_PROG; }写代码时两个32位数据要连续写入中间不要夹杂其他Flash操作。第二个字写入后Flash控制器才会真正触发一次编程周期。如果你只写了一个字就退出PROG模式数据不会完整写入。4.2 页擦除的128字节粒度L071的页大小是128字节擦除地址必须对齐到128字节边界。FLASH_AR寄存器里擦除时低7位会被忽略所以你可以传一个页内任意地址进去但最好还是在应用层强制对齐避免自己都搞糊涂。擦除流程比编程更简单设置PER模式、把页地址写入FLASH_AR、置位STARTR、等BSY清零。注意置位STARTR后硬件会自动管理擦除时序但PER位不会自动清除必须软件复位。忘了清PER下一次操作就可能在错误模式下启动出现莫名其妙的写失败。4.3 FLASH_SR状态位与常见错误定位调试Flash问题时第一步永远是读FLASH_SR。很多“死机”其实不是死机而是错误标志提示了原因但你没看。把常用状态位整理成一个表方便排查状态位含义出现时的处理方向BSYFlash忙轮询等待不忙才能发起新操作EOP编程/擦除完成写1清除记录操作成功WRPERR写保护违规检查WRP页写保护和选项字节PGAERR编程对齐/非法地址错误检查地址是否8字节对齐、Flash地址是否合法SIZERR访问宽度错误检查是否出现非16位/非32位访问OPTVERR选项字节校验错误重新加载选项字节或检查配置有一个坑值得说L0的Flash状态位是“写1清除”。新手容易写成“赋值0清除”结果标志位永远不消失导致后续操作永远等不到正确状态。正确写法是FLASH-SR | FLASH_SR_EOP;这种读改写方式保证只清目标位而不影响其他位。4.4 解锁/上锁的密钥时序L0系列的Flash编程/擦除前必须先通过PEKEYR寄存器解锁。解锁序列是固定的先写0x89ABCDEF再写0x02030405。两个密钥缺一不可顺序也不能反。解锁后FLASH_PECR的PELOCK位变成0才能配置编程/擦除模式。操作结束后要重新上锁推荐写一个无效密钥到PEKEYR比如0xFFFFFFFF把PELOCK置回去。让Flash长时间处于解锁状态等于给意外写入留了一扇门量产产品尤其不该这样。解锁状态是个系统级的保护机制不只是给应用层用的。调试器连接时也可能动Flash如果调试器检测到Flash未解锁会尝试执行解锁序列。所以在调试Flash操作代码时如果发现程序停在FLASH-PEKEYR写入那一行先别急着以为是bug看看是不是密钥值被编译器优化错了。5. 实测中容易翻车的几个细节5.1 编译优化等级对RAM执行方案的影响使用“函数搬移到RAM”方案时遇到最多的翻车点其实是编译器优化。我遇到过一种情况函数加了__attribute__((section(.ramfunc)))也被正确拷贝到RAM了但编译器在函数内自动生成了一个对Flash中常量区的引用结果擦写时访问到目标bank依然卡死。解决办法给Flash操作函数加noinline禁止内联。函数一旦被内联到调用者里它的代码就不一定在.ramfunc段了。尽量把函数写成“纯净函数”只用形参、局部变量、寄存器映射。不要引用外部全局变量和const数组。如果一定要用查表把表也放到RAM里或者放到非目标bank。调试时可以检查编译生成的map文件确认.ramfunc段的大小和位置以及函数内有没有意外引用Flash区域的符号。这个方法特别管用能提前发现问题。5.2 中断向量表与ISR位置最容易被忽略的隐形炸弹很多人验证了“RAM执行没问题”但在系统里跑起来还是偶发死机最后发现是中断惹的祸。Flash擦写期间如果来了一个外部中断CPU会先去向量表取中断向量然后跳到ISR取指令。如果向量表或者ISR本身位于正在擦写的bank那这个中断请求就会触发intra-bank访问直接卡死。处理策略要分场景擦写期间关闭全局中断__disable_irq()这是最省事的做法但要评估中断延迟对系统的影响。如果系统不能长时间关中断就要确保所有可能触发的中断ISR和向量表都位于非目标bank或者ISR搬到RAM执行。使用基于优先级的中断控制只屏蔽会访问目标bank的中断源。使用L071做IAP时我倾向于在真正擦写Flash的那几十到几百毫秒内关全局中断。L0的Flash擦除时间在几十毫秒量级对于大多数通信协议而言这个窗口可以接受但像WiFi模块或者需要持续响应的传感器采集就要仔细评估了。5.3 调试器连接期间的Flash操作行为调试器是Flash操作的“第三者”你永远不会知道它什么时候会插一脚。用ST-Link调试时万一你暂停在断点上而程序刚好完成了擦除、正准备写数据调试器想读Flash、你想写Flash两边同时操作同一个bank行为就不可预期了。这种问题我建议不要浪费时间在调试器里“边暂停边看Flash”。验证Flash时序和IAP流程时尽量脱离调试器跑用串口打印日志、LED状态、或者保存操作结果到RAM里稍后读取。调试器只用来烧录程序和看PC指针不要介入Flash操作的时序验证。5.4 写保护WRP导致的静默失败L0支持页级写保护通过选项字节或运行时的WRP寄存器配置。如果目标页恰好被保护擦写操作不会成功FLASH_SR的WRPERR会被置位。这个错误不一定会让程序卡死但它会“静默失败”——看起来函数执行完了实际上数据没写进去设备运行一段时间后表现诡异。我在一个量产项目里就遇到过旧版本固件设置了写保护新版本IAP代码想更新那一页每次都报成功但重启后还是旧程序。查了半天最后读了FLASH_SR才发现WRPERR一直是1。排查建议Flash操作完成后无论代码多忙都要检查WRPERR和EOP标志。如果目标页有写保护需要先解除保护或选择别的页。量产模式下页面写保护是好事但设计IAP时要明确哪些页允许应用层擦写哪些页是保护区域边界要画清楚。实际项目里的最后一点体会做了快十年的嵌入式固件Flash操作相关的坑见过不少。intra-bank这种问题最折磨人的地方在于它不是编译报错不是逻辑错乱而是运行到某个特定条件下系统“咔嚓”一下死掉看起来毫无规律。但只要理解了bank粒度这个约束很多问题其实是可以一眼识破的代码在哪取指、数据在哪存放、Flash操作指向哪个bank这张三角关系画清楚90%的Flash死机问题都有了解题方向。我现在拿到一个新的单片机做IAP第一件事不是看Demo代码而是看Flash组织架构图有几个bank、页面多大、编程单位是多少、RWW支持到什么程度。这半小时的阅读能省下后面好几天的调试时间。STM32L071是个不错的双bank平台把它的脾气摸透后面做L0系列其他型号也有很强的迁移性。
做STM32L071的IAP升级最烦的不是协议而是Flash本身的脾气。我第一版代码写得很“理所当然”应用程序在0x08000000跑着然后调用HAL库直接去擦自己所在bank的页结果一进擦除函数设备当场死机看门狗连喂的机会都没有。查了一圈文档和社区案例才发现这是STM32L071双bank Flash的intra-bank write/erase行为在捣鬼。这个标题看着像芯片手册里一个干巴巴的小节名实际踩过坑的人都知道它背后藏着一整类“Flash自编程”的设计约束。这篇我打算把STM32L071的双bank结构、intra-bank写/擦行为、以及绕过这个限制的几种工程做法一次讲透适合正在做IAP、OTA或者应用自更新的朋友参考。1. STM32L071的双bank Flash架构与地址映射1.1 两个bank怎么分、容量多大STM32L071的常见Flash配置是128KB内部被切成两个独立的bank每个bank 64KB。地址划分非常规整存储区地址范围容量Bank 00x08000000 ~ 0x0800FFFF64KBBank 10x08010000 ~ 0x0801FFFF64KB页大小128字节每个bank有512页。也就是说擦除的最小单位是128字节而bank是独立的擦写调度单元。有一个容易忽略的点不是所有L0系列芯片都有双bank。像STM32L011、L031这些小容量型号Flash只有16KB~32KB是单bank结构。只有L071、L072、L073、L081、L082、L083这些128KB至192KB容量的型号才具备双bank。所以做设计选型时一定要看完整Part Number不能光看系列名就默认有双bank。1.2 RWW能力为什么inter-bank操作这么舒服双bank带来的最大价值就是RWWRead-While-Write也就是“读时写”或者“写时读”。当CPU从Bank 0取指执行同时Flash控制器对Bank 1做编程或擦除两个bank各自用各自的接口互不干扰。这个特性用在IAP上非常舒服。典型的做法是Bootloader放在Bank 0应用程序放在Bank 1。Bootloader在Bank 0里运行需要升级应用时直接擦写Bank 1、把新固件写入Bank 1整个过程CPU一直在Bank 0正常取指执行不存在任何阻塞。这也是为什么很多用L071做产品的人最终选择了“Bootloader App”这种经典架构。不是因为它新潮而是这种架构恰好踩在芯片硬件的能力边界内把intra-bank问题直接绕开了。1.3 和单bank芯片的本质差异单bank芯片没有RWW能力。CPU请求指令、读取数据全都要经过Flash总线而编程/擦除操作一旦启动Flash总线就被擦写逻辑占住读请求全部被挂起。所以单bank芯片做IAP时Flash擦写函数必须搬到RAM里执行没有别的选择。而STM32L071这种双bank芯片理论上可以有“半个Flash在忙、另外半个Flash还能读”的福利。但请注意这个福利只在“擦写目标bank ≠ 代码执行bank”时成立。当你对当前正在执行代码的那个bank发起写/擦芯片的行为立刻退化成单bank状态甚至比单bank更危险。这个退化的本质就是标题里的intra-bank问题。我画个简单的行为对照表方便一眼理解代码从哪里取指擦写目标结果Bank 0Bank 0卡死 / NMI不允许Bank 0Bank 1正常RWW生效Bank 1Bank 0正常RWW生效Bank 1Bank 1卡死 / NMI不允许RAMBank 0 或 Bank 1都正常这张表建议直接贴在工位上。我后来所有Flash操作代码都会先对照这张表确认“我现在在哪取指、我要动哪块”再决定调用方式。2. intra-bank写/擦行为为什么程序会在自己家门前踩空2.1 取指与数据访问的双重阻塞要理解intra-bank为什么卡死先要理解CPU的执行模型。Cortex-M0核心每一个时钟周期都需要取指令如果指令来自Flash那么Flash接口必须持续提供取指数据。当Flash控制器收到一条擦除或编程命令并且操作目标是当前取指的bank时整个bank的存储阵列都进入busy状态。此时不管是取指还是数据读取来到这个bank的读请求都会被无限期挂起直到擦写完成。问题在于擦写流程本身也需要CPU执行代码来启动和轮询。如果CPU执行代码的bank正是被擦写的bank那它就永远等不到擦写完成——因为等指令的核和写Flash的控制器在同一个bank上“死锁”了。这就是“自锁”的本质。更隐蔽的是数据访问。有些朋友把Flash操作函数搬到了RAM心想这总该没事了吧结果还是卡死。为什么因为他们编译的程序里const常量、字符串字面量、甚至编译器生成的跳转表仍然存放在Flash里。擦写Bank 0期间代码里某个printf格式字符串恰好放在Bank 0CPU去读这个字符串读请求一样被挂起。所以RAM执行方案绝不是“把函数丢到RAM”就完事还要保证这个函数及其依赖的数据都不落在目标bank。2.2 从“卡死”到NMI的连锁反应L0系列的Flash控制器对这种情况并不是毫无保护。当它探测到CPU在访问一个正在编程/擦除的bank时会尝试通过NMI不可屏蔽中断来打断CPU避免总线无限期死锁。但这里有个很讽刺的闭环NMI_Handler默认也放在Flash里。如果触发的NMI的handler本身就在被锁定的bank中处理器跳进NMI_Handler后又要从同一个bank取指结果是二次死锁。所以你在现场看到的现象会很分裂有的是复位、有的是“卡死在NMI_Handler”、有的是看门狗超时复位、有的干脆系统无响应。这些表象后面根因都是同一个intra-bank访问。我在早期调试时用调试器看PC指针发现它停在0x0800xxxx的NMI_Handler地址当时还以为是程序跑飞了。后来对照参考手册的NMI生成条件才明白是Flash接口主动拉起了NMI。这一步认知非常关键——不要浪费时间去查栈、查指针先确认是不是动了正在执行的bank。2.3 一个反直觉的细节不是只有“擦自己正在跑的页”才死这里有一个绝大多数新手都会误解的点以为“我擦的页和当前执行的页不是同一页就安全了”。但在同一个bank内部擦写任意一页整片bank的存储阵列都处于busy状态。哪怕你在0x08000000执行去擦0x0800FF00同一个bank最后一页同样死锁。打个比方银行是一个bank一个bank营业的你人在Bank 0的柜台前办业务结果整个Bank 0的营业网点停电了那你在哪张椅子上坐着都不好使。银行网点是整个关门不是只关某一个窗口。这意味着intra-bank写/擦行为约束的是“bank”这个粒度不是“页”这个粒度。判断安全性的唯一标准就是操作目标bank和CPU正在取指的bank是不是同一个。是同一个就有风险不是同一个页的位置无所谓。3. 绕过intra-bank限制的三种实战路径3.1 路径一把Flash操作函数搬进RAM执行这是单bank时代就有的经典做法在L071上同样适用而且处理得当非常可靠。核心原理很简单CPU从RAM取指RAM走的是另一个存储接口Flash擦写时不涉及RAM的读请求所以两条通路不会打架。具体实施分三件事把Flash操作函数放到自定义段、在调用前拷贝到RAM、用函数指针调用。先看函数定义我用寄存器操作写一个页擦除函数并放到.ramfunc段__attribute__((section(.ramfunc), noinline)) void Flash_PageErase_RAM(uint32_t page_addr) { /* 等上一次Flash操作完成 */ while (FLASH-SR FLASH_SR_BSY); /* 如果Flash被锁先解锁 */ if (FLASH-PECR FLASH_PECR_PELOCK) { FLASH-PEKEYR 0x89ABCDEF; FLASH-PEKEYR 0x02030405; } /* 页擦除模式 */ FLASH-PECR | FLASH_PECR_PER; FLASH-AR page_addr; FLASH-PECR | FLASH_PECR_STARTR; /* 等待操作完成 */ while (FLASH-SR FLASH_SR_BSY); /* 清除完成标志和错误标志 */ FLASH-SR | FLASH_SR_EOP | FLASH_SR_WRPERR | FLASH_SR_PGAERR | FLASH_SR_SIZERR | FLASH_SR_OPTVERR; /* 退出擦除模式 */ FLASH-PECR ~FLASH_PECR_PER; }链接脚本里需要把.ramfunc段放到RAM区域并且记录加载地址和运行地址。用GCC工具链时可以在linker script中加.ramfunc : { . ALIGN(4); __ramfunc_flash_start LOADADDR(.ramfunc); __ramfunc_vtor_start .; *(.ramfunc) __ramfunc_vtor_end .; . ALIGN(4); } RAM AT FLASH然后在使用前把这段代码从Flash拷贝到RAMextern uint32_t __ramfunc_flash_start; extern uint32_t __ramfunc_vtor_start; extern uint32_t __ramfunc_vtor_end; void Flash_PageErase(uint32_t page_addr) { /* 拷贝RAM执行函数到RAM */ uint8_t *src (uint8_t *)__ramfunc_flash_start; uint8_t *dst (uint8_t *)__ramfunc_vtor_start; uint32_t len (uint32_t)__ramfunc_vtor_end - (uint32_t)__ramfunc_vtor_start; memcpy(dst, src, len); /* 通过函数指针调用RAM中的函数 */ void (*erase_func)(uint32_t) (void (*)(uint32_t))dst; erase_func(page_addr); }这里有个细节值得提醒Cortex-M0只支持Thumb指令所有RAM函数地址的最低位会被处理器当作Thumb位处理。我们的函数是普通C函数编译出来就是Thumb代码所以直接用函数指针调用没有问题不需要手工设置最低位。函数内还要注意不能引用Flash中的常量。比如不要在擦除函数里放一个查表数组或者printf格式字符串那些数据一旦落在被擦除的bank里一样会卡死。把这个函数做成“自包含”只操作寄存器、栈变量和参数最安全。3.2 路径二双bank A/B分区IAP天然避开intra-bank如果不想和RAM执行方案纠缠可以考虑A/B分区设计。思路是把Bank 0和Bank 1各当一个完整的“固件槽位”系统启动时选择一个槽位执行升级时去擦写另一个槽位。这个方案在L071上可行但有一个要注意的坑L071没有L4系列那种硬件bank swap寄存器。L4可以通过SYSCFG寄存器把两个bank对调L071没有这个能力所以“切换启动”必须用纯软件方式完成。设计大概长这样Bootloader放在Bank 0起始位置或者每个镜像头部都放一段启动引导逻辑。固件头部记录版本号、校验值、长度信息。上电后Bootloader检查升级标志和两个bank的固件头选择有效的那个跳转过去。升级流程在运行时把新镜像写入非当前bank写完后更新标志复位后从新bank启动。A/B分区的好处很明显整个升级过程当前运行bank和写入目标bank始终不同全程RWW根本不会触发intra-bank问题。而且升级失败后可以回滚到旧版本鲁棒性强。代价是固件需要做分区设计两个bank各留多少给镜像、公共数据放哪里、升级标志存哪儿。这些都是在规划阶段就要定好的不能等到代码写完再拍脑袋。3.3 路径三Bootloader在Bank 0、应用在Bank 1的经典RWW组合这是最省心的组合也最推荐大多数产品先采用。思路很简单Bootloader固定在Bank 0应用固定在Bank 1。Bootloader启动后从Bank 1加载应用并跳转应用想升级时设置升级标志并复位Bootloader检查到标志后在Bank 0里执行擦除Bank 1、接收新固件、写入Bank 1完成后跳转。整个过程里Bootloader一直运行在Bank 0擦写目标一直是Bank 1属于标准inter-bank操作完全安全。应用自身不需要做任何Flash擦写只需要提供“复位进入Bootloader升级”的机制。这个方案的局限性在于Bootloader本身很难通过自身来升级。如果Bootloader有严重Bug或者你想更新引导逻辑就得借助外部调试器或RAM执行方案。对多数产品来说Bootloader更新频率极低这个风险可以接受。3.4 三种方案的选择逻辑方案是否需要RAM执行是否需要分区复杂度适合场景RAM执行是否中单镜像自更新代码结构简单A/B双bank否是高OTA要求高、需要回滚BootloaderApp否部分中经典IAP性价比最高我个人建议做量产产品优先考虑方案三如果产品有远程升级需求、且必须要断点续传和高可靠性再上方案二方案一作为临时救急或者单bank芯片的通用手段来掌握。4. L071 Flash操作的关键时序与状态位检查不管用哪种路径最终都要面对Flash控制器本身的规矩。L0系列的Flash操作有几个硬性要求忽略任何一个都会踩坑。4.1 编程最小单位64位double word的对齐要求L0系列Flash编程不是按字节、也不是按字32位写入而是按双字64位为一个编程操作单位。你必须一次写两个连续的32位数据而且起始地址必须8字节对齐。如果地址不对齐FLASH_SR里的PGAERR编程对齐错误会被置位写入失败。写一个双字编程函数仍然放在RAM执行__attribute__((section(.ramfunc), noinline)) void Flash_ProgramDoubleWord_RAM(uint32_t addr, uint64_t data) { uint32_t lo (uint32_t)(data 0xFFFFFFFF); uint32_t hi (uint32_t)(data 32); while (FLASH-SR FLASH_SR_BSY); if (FLASH-PECR FLASH_PECR_PELOCK) { FLASH-PEKEYR 0x89ABCDEF; FLASH-PEKEYR 0x02030405; } /* 进入编程模式 */ FLASH-PECR | FLASH_PECR_PROG; /* 写第一个32位再写第二个32位 */ *(__IO uint32_t *)addr lo; *(__IO uint32_t *)(addr 4) hi; while (FLASH-SR FLASH_SR_BSY); FLASH-SR | FLASH_SR_EOP | FLASH_SR_WRPERR | FLASH_SR_PGAERR | FLASH_SR_SIZERR | FLASH_SR_OPTVERR; /* 退出编程模式 */ FLASH-PECR ~FLASH_PECR_PROG; }写代码时两个32位数据要连续写入中间不要夹杂其他Flash操作。第二个字写入后Flash控制器才会真正触发一次编程周期。如果你只写了一个字就退出PROG模式数据不会完整写入。4.2 页擦除的128字节粒度L071的页大小是128字节擦除地址必须对齐到128字节边界。FLASH_AR寄存器里擦除时低7位会被忽略所以你可以传一个页内任意地址进去但最好还是在应用层强制对齐避免自己都搞糊涂。擦除流程比编程更简单设置PER模式、把页地址写入FLASH_AR、置位STARTR、等BSY清零。注意置位STARTR后硬件会自动管理擦除时序但PER位不会自动清除必须软件复位。忘了清PER下一次操作就可能在错误模式下启动出现莫名其妙的写失败。4.3 FLASH_SR状态位与常见错误定位调试Flash问题时第一步永远是读FLASH_SR。很多“死机”其实不是死机而是错误标志提示了原因但你没看。把常用状态位整理成一个表方便排查状态位含义出现时的处理方向BSYFlash忙轮询等待不忙才能发起新操作EOP编程/擦除完成写1清除记录操作成功WRPERR写保护违规检查WRP页写保护和选项字节PGAERR编程对齐/非法地址错误检查地址是否8字节对齐、Flash地址是否合法SIZERR访问宽度错误检查是否出现非16位/非32位访问OPTVERR选项字节校验错误重新加载选项字节或检查配置有一个坑值得说L0的Flash状态位是“写1清除”。新手容易写成“赋值0清除”结果标志位永远不消失导致后续操作永远等不到正确状态。正确写法是FLASH-SR | FLASH_SR_EOP;这种读改写方式保证只清目标位而不影响其他位。4.4 解锁/上锁的密钥时序L0系列的Flash编程/擦除前必须先通过PEKEYR寄存器解锁。解锁序列是固定的先写0x89ABCDEF再写0x02030405。两个密钥缺一不可顺序也不能反。解锁后FLASH_PECR的PELOCK位变成0才能配置编程/擦除模式。操作结束后要重新上锁推荐写一个无效密钥到PEKEYR比如0xFFFFFFFF把PELOCK置回去。让Flash长时间处于解锁状态等于给意外写入留了一扇门量产产品尤其不该这样。解锁状态是个系统级的保护机制不只是给应用层用的。调试器连接时也可能动Flash如果调试器检测到Flash未解锁会尝试执行解锁序列。所以在调试Flash操作代码时如果发现程序停在FLASH-PEKEYR写入那一行先别急着以为是bug看看是不是密钥值被编译器优化错了。5. 实测中容易翻车的几个细节5.1 编译优化等级对RAM执行方案的影响使用“函数搬移到RAM”方案时遇到最多的翻车点其实是编译器优化。我遇到过一种情况函数加了__attribute__((section(.ramfunc)))也被正确拷贝到RAM了但编译器在函数内自动生成了一个对Flash中常量区的引用结果擦写时访问到目标bank依然卡死。解决办法给Flash操作函数加noinline禁止内联。函数一旦被内联到调用者里它的代码就不一定在.ramfunc段了。尽量把函数写成“纯净函数”只用形参、局部变量、寄存器映射。不要引用外部全局变量和const数组。如果一定要用查表把表也放到RAM里或者放到非目标bank。调试时可以检查编译生成的map文件确认.ramfunc段的大小和位置以及函数内有没有意外引用Flash区域的符号。这个方法特别管用能提前发现问题。5.2 中断向量表与ISR位置最容易被忽略的隐形炸弹很多人验证了“RAM执行没问题”但在系统里跑起来还是偶发死机最后发现是中断惹的祸。Flash擦写期间如果来了一个外部中断CPU会先去向量表取中断向量然后跳到ISR取指令。如果向量表或者ISR本身位于正在擦写的bank那这个中断请求就会触发intra-bank访问直接卡死。处理策略要分场景擦写期间关闭全局中断__disable_irq()这是最省事的做法但要评估中断延迟对系统的影响。如果系统不能长时间关中断就要确保所有可能触发的中断ISR和向量表都位于非目标bank或者ISR搬到RAM执行。使用基于优先级的中断控制只屏蔽会访问目标bank的中断源。使用L071做IAP时我倾向于在真正擦写Flash的那几十到几百毫秒内关全局中断。L0的Flash擦除时间在几十毫秒量级对于大多数通信协议而言这个窗口可以接受但像WiFi模块或者需要持续响应的传感器采集就要仔细评估了。5.3 调试器连接期间的Flash操作行为调试器是Flash操作的“第三者”你永远不会知道它什么时候会插一脚。用ST-Link调试时万一你暂停在断点上而程序刚好完成了擦除、正准备写数据调试器想读Flash、你想写Flash两边同时操作同一个bank行为就不可预期了。这种问题我建议不要浪费时间在调试器里“边暂停边看Flash”。验证Flash时序和IAP流程时尽量脱离调试器跑用串口打印日志、LED状态、或者保存操作结果到RAM里稍后读取。调试器只用来烧录程序和看PC指针不要介入Flash操作的时序验证。5.4 写保护WRP导致的静默失败L0支持页级写保护通过选项字节或运行时的WRP寄存器配置。如果目标页恰好被保护擦写操作不会成功FLASH_SR的WRPERR会被置位。这个错误不一定会让程序卡死但它会“静默失败”——看起来函数执行完了实际上数据没写进去设备运行一段时间后表现诡异。我在一个量产项目里就遇到过旧版本固件设置了写保护新版本IAP代码想更新那一页每次都报成功但重启后还是旧程序。查了半天最后读了FLASH_SR才发现WRPERR一直是1。排查建议Flash操作完成后无论代码多忙都要检查WRPERR和EOP标志。如果目标页有写保护需要先解除保护或选择别的页。量产模式下页面写保护是好事但设计IAP时要明确哪些页允许应用层擦写哪些页是保护区域边界要画清楚。实际项目里的最后一点体会做了快十年的嵌入式固件Flash操作相关的坑见过不少。intra-bank这种问题最折磨人的地方在于它不是编译报错不是逻辑错乱而是运行到某个特定条件下系统“咔嚓”一下死掉看起来毫无规律。但只要理解了bank粒度这个约束很多问题其实是可以一眼识破的代码在哪取指、数据在哪存放、Flash操作指向哪个bank这张三角关系画清楚90%的Flash死机问题都有了解题方向。我现在拿到一个新的单片机做IAP第一件事不是看Demo代码而是看Flash组织架构图有几个bank、页面多大、编程单位是多少、RWW支持到什么程度。这半小时的阅读能省下后面好几天的调试时间。STM32L071是个不错的双bank平台把它的脾气摸透后面做L0系列其他型号也有很强的迁移性。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
