1. MCU固件OTA升级中的Flash存储空间划分策略在嵌入式系统开发实践中远程固件升级Over-The-Air, OTA已成为工业设备、IoT终端及消费类电子产品的标准能力。然而OTA功能的可靠实现远不止于网络通信与固件传输——其底层依赖于对MCU片内Flash存储器的精细化管理。Flash并非可随机字节写入的RAM其物理特性决定了擦除操作必须以块Block或页Page为单位进行且写入前必须先擦除。这一根本约束直接决定了OTA升级过程中固件镜像如何组织、校验、切换与回滚。若Flash空间划分不合理轻则导致升级失败、系统无法启动重则造成Bootloader损坏、设备变砖。因此Flash划分不是简单的地址分配问题而是涉及系统鲁棒性、升级安全性与资源利用率的核心架构决策。本文聚焦于三种主流的Flash空间组织方式独立型、嵌入型与外挂型。每种方式对应不同的硬件资源约束、安全等级需求与软件复杂度权衡。分析将严格基于MCU Flash物理特性展开不引入平台依赖性描述所有设计逻辑均服务于工程可实现性与现场可靠性。2. 独立型Flash划分隔离引导与应用构建双区安全升级路径2.1 架构定义与核心思想独立型划分的本质是物理隔离在MCU片内Flash中为Bootloader程序单独保留一块固定、不可覆盖的存储区域其余空间则划分为两个逻辑上对等的应用程序区通常称为Firmware A与Firmware B。Bootloader本身不参与应用逻辑仅承担系统初始化、新固件接收、完整性校验、镜像搬运与启动跳转等基础职责。其代码一旦烧录即被锁定运行时不可被OTA过程修改。该架构的工程目标非常明确确保系统永远存在一个已知可靠的启动入口点。即使OTA下载的新固件存在严重缺陷或校验失败Bootloader仍能保持完整系统可进入恢复模式或尝试其他备份策略避免“升级即死亡”的单点故障。2.2 典型工作流程与状态机独立型升级遵循严格的四阶段状态机接收与暂存Bootloader通过UART、USB或网络协议接收新固件二进制流将其完整写入Firmware B区。此过程需持续进行CRC32或SHA-256校验确保数据在传输链路中未被破坏。完整性验证固件写入完成后Bootloader读取Firmware B区全部内容计算其哈希值并与接收时附带的签名或摘要比对。若校验失败则标记B区为无效终止升级流程。镜像搬运与擦除校验成功后Bootloader执行关键操作首先擦除Firmware A区此时系统仍在运行旧A区代码然后将Firmware B区的完整镜像逐页复制至Firmware A区。此步骤必须保证原子性——若搬运中途断电A区处于半擦除/半写入状态Bootloader需具备检测并拒绝启动的能力。启动切换搬运完成后Bootloader更新一个位于Flash固定位置如最后一页的启动标志位例如boot_flag 0xAA55随后复位MCU。复位后Bootloader读取该标志确认应从A区即新固件启动并跳转至其复位向量地址。该流程天然支持回滚机制若新固件启动后检测到严重错误如看门狗超时、关键外设初始化失败可由应用层主动触发回滚将启动标志重置为指向旧固件区下次重启即恢复。2.3 基于TMPM3H6FWFG的实例化设计以东芝TMPM3H6FWFG MCU为例其片内Flash总容量为128KB物理擦除粒度具有两级结构最小擦除单位页Page大小为4KB更大擦除单位块Block大小为32KB。此物理特性对Flash划分构成硬性约束。任何分区边界必须对齐至4KB页边界否则无法独立擦除某一分区。同时为优化擦除时间与磨损均衡分区大小宜为4KB的整数倍且避免跨32KB块边界除非有特殊需求。下表给出了一个工程上合理、兼顾安全与效率的独立型划分方案分区名称起始地址 (Hex)结束地址 (Hex)大小对齐要求主要用途Bootloader0x0000_00000x0000_3FFF16KB4KB存放Bootloader代码与配置数据Firmware A0x0000_40000x0001_FFFF96KB4KB当前运行的应用程序Firmware B0x0002_00000x0003_FFFF128KB?4KB错误超出总容量注原文中“Firmware B128KB”明显与128KB总Flash矛盾属笔误。实际划分必须满足Bootloader_Size Firmware_A_Size Firmware_B_Size ≤ 128KB。修正后的典型划分如下保留足够余量分区名称起始地址 (Hex)结束地址 (Hex)大小对齐要求主要用途Bootloader0x0000_00000x0000_3FFF16KB4KBBootloader主代码Bootloader CFG0x0000_40000x0000_4FFF4KB4KB启动标志、版本号、校验摘要等Firmware A0x0000_50000x0001_CFFF96KB4KB主应用程序区Firmware B0x0001_D0000x0003_FFFF132KB?4KB仍超限需重新计算再次修正128KB 0x20000字节。扣除16KB Bootloader与4KB CFG后剩余108KB0x1B000字节供A/B区共享。常见做法是均分A区54KBB区54KB。最终可行划分分区名称起始地址 (Hex)结束地址 (Hex)大小对齐要求主要用途Bootloader0x0000_00000x0000_3FFF16KB4KBBootloader主代码Bootloader CFG0x0000_40000x0000_4FFF4KB4KB启动标志、版本、校验摘要Firmware A0x0000_50000x0000_EFFF40KB4KB当前运行的应用程序Firmware B0x0000_F0000x0001_8FFF40KB4KB新固件暂存区预留/备用0x0001_90000x0001_FFFF28KB-未来扩展、日志存储或冗余备份此划分严格满足所有分区起始地址均为4KB0x1000对齐Firmware A与B大小相等便于统一搬运逻辑预留约22%空间为未来功能迭代或调试信息存储提供弹性。2.4 关键电路与Bootloader实现要点独立型架构对硬件无特殊要求但对Bootloader代码质量提出高要求向量表重映射MCU复位后默认从0x0000_0000取向量表。Bootloader需在跳转至Firmware A/B前将SCB-VTOR寄存器设置为对应区的起始地址确保中断服务例程ISR能正确响应。Flash编程驱动必须使用MCU厂商提供的标准库如Toshiba TMPM3H系列的Flash_WritePage()、Flash_EraseSector()或直接操作Flash控制器寄存器。严禁在Flash编程期间发生中断故关键段需关闭全局中断。电源监控在擦除/写入Flash前需确认VDD稳定。TMPM3H6FWFG内置BORBrown-Out Reset模块Bootloader应配置其阈值确保在电压跌落时能强制复位避免Flash写入错误。// TMPM3H6FWFG Bootloader中擦除Firmware A区示例伪代码 void EraseFirmwareA(void) { uint32_t sector_addr FIRMWARE_A_START_ADDR; // e.g., 0x00005000 uint32_t sector_size 4096; // 4KB page size // 关闭全局中断防止Flash操作被打断 __disable_irq(); // 检查Flash是否忙 while (FLASH_GetStatus() FLASH_BUSY); // 逐页擦除Firmware A区共10页 for (int i 0; i 10; i) { FLASH_ErasePage(sector_addr i * sector_size); // 等待擦除完成 while (FLASH_GetStatus() FLASH_BUSY); } __enable_irq(); }3. 嵌入型Flash划分Bootloader与Application融合以灵活性换取空间效率3.1 架构定义与适用场景嵌入型划分摒弃了物理隔离将Bootloader功能作为一段可执行代码静态链接并嵌入到应用程序Application镜像内部。整个固件镜像AppBootloader作为一个整体被烧录至单一Flash分区。系统上电后首先执行的是嵌入在App镜像头部的Bootloader代码段其任务是检查是否存在待升级的新固件通常存于外部存储若存在则执行下载与校验成功后直接跳转至新固件的入口地址而非搬运镜像。该模式的核心优势在于极致的空间利用率无需为Bootloader预留独立空间128KB Flash可100%用于应用逻辑。其代价是升级过程的脆弱性——若新固件下载失败或校验错误当前运行的AppBootloader镜像可能已被部分覆盖导致系统无法启动。因此嵌入型适用于以下场景MCU Flash资源极度紧张64KB无法承受独立Bootloader开销升级频率极低且现场具备JTAG/SWD等物理调试接口可接受“变砖后人工刷写”的风险应用逻辑简单Bootloader功能精简如仅支持UART串口升级无复杂网络协议栈。3.2 工作流程与内存布局嵌入型的典型内存布局如下以ARM Cortex-M为例[0x0000_0000] -- Vector Table (Reset Handler points here) | v [0x0000_0000] -- Bootloader Entry Code (e.g., 2KB) [0x0000_0800] -- Application Main Code (Rest of Flash)启动流程MCU复位从0x0000_0000加载向量表执行Reset Handler即Bootloader入口。Bootloader初始化基本外设如SysTick、GPIO、UART检查特定GPIO引脚状态或Flash中某个标志位判断是否进入升级模式。若进入升级模式Bootloader通过UART接收新固件将其写入外部存储器如SPI Flash或片内Flash的指定备份区若空间允许。校验新固件后Bootloader调用SCB-VTOR new_app_vector_table_address然后执行((void (*)(void))new_app_reset_handler)();直接跳转至新固件的复位函数。关键点在于新固件的存储位置不在当前运行的Flash镜像内。它必须位于一个与当前App完全无关的存储区域以避免自覆盖。这引出了两种子模式外置缓存模式新固件暂存于SPI Flash或SD卡。Bootloader仅负责搬运与跳转不管理App区擦除。片内双镜像模式虽无独立Bootloader区但仍将Flash划分为App1与App2两个区。当前App运行时新固件下载至另一区。此模式实为独立型的变体但Bootloader代码随App一起编译故App1与App2的镜像均包含一份Bootloader副本。3.3 工程实践挑战嵌入型最大的工程挑战在于链接脚本Linker Script的精确控制。开发者必须手动指定Bootloader代码段.bootloader的起始地址与长度并确保其后的Application代码段.text紧随其后且向量表位于绝对地址0x0000_0000。一个典型的GNU ld脚本片段如下MEMORY { FLASH (rx) : ORIGIN 0x00000000, LENGTH 128K RAM (rwx) : ORIGIN 0x20000000, LENGTH 32K } SECTIONS { .bootloader : { *(.bootloader) /* 放置Bootloader代码 */ . ALIGN(4); } FLASH .isr_vector : { KEEP(*(.isr_vector)) /* 向量表必须在0x00000000 */ } FLASH AT FLASH .text : { *(.text) /* Application主代码 */ *(.rodata) . ALIGN(4); } FLASH AT FLASH }此外Bootloader跳转代码必须使用__attribute__((naked))声明避免编译器插入函数序言/尾声确保栈指针SP与程序计数器PC被正确设置。4. 外挂型Flash划分突破片内容量限制构建可扩展固件仓库4.1 架构定义与硬件基础当MCU片内Flash容量如TMPM3H6FWFG的128KB无法满足日益增长的固件体积含RTOS、TLS协议栈、图形界面时外挂型划分成为必然选择。其核心思想是将新固件的接收、存储与校验过程完全迁移至外部非易失性存储器片内Flash仅存放最小化的Bootloader与当前运行的应用程序。外部存储器通常选用SPI Flash如Winbond W25Q324MB或I2C EEPROM如AT24C51264KB通过标准总线与MCU连接。该架构将“固件仓库”与“执行空间”解耦带来显著优势无限升级空间外部Flash容量可达数十MB轻松容纳多个固件版本、资源文件甚至微型文件系统FatFS。零片内Flash擦写风险Bootloader与当前App的Flash区域在OTA全程保持只读彻底规避因擦写失败导致的系统崩溃。并行操作能力MCU可在后台通过DMA接收网络固件流并写入SPI Flash同时前台App正常处理业务逻辑提升用户体验。4.2 典型硬件接口与驱动设计以SPI Flash为例其与MCU的典型连接如下MCU PinSPI Flash Pin信号方向说明PA4/CSOutput片选低电平有效PA5SCKOutput时钟PA6MISOInput主机输入从机输出PA7MOSIOutput主机输出从机输入Bootloader需实现完整的SPI Flash驱动包括初始化配置SPI外设时钟、引脚复用、波特率通常≤20MHz、CPOL/CPHA模式W25Q系列为Mode 0。指令发送发送标准指令如0x03(Read Data)、0x02(Page Program)、0x20(Sector Erase)、0x05(Read Status Register)。状态轮询在擦除/写入后持续读取状态寄存器0x05等待BUSY位清零。// 读取SPI Flash状态寄存器阻塞式 uint8_t SpiFlash_ReadStatus(void) { uint8_t cmd 0x05; uint8_t status; HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_RESET); // CS Low HAL_SPI_Transmit(hspi1, cmd, 1, HAL_MAX_DELAY); HAL_SPI_Receive(hspi1, status, 1, HAL_MAX_DELAY); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET); // CS High return status; } // 等待Flash空闲 void SpiFlash_WaitReady(void) { while (SpiFlash_ReadStatus() 0x01); // BUSY bit }4.3 OTA升级流程重构外挂型下的OTA流程发生本质变化接收与写入Bootloader接收网络包解析出固件数据通过SPI接口直接写入外部Flash的指定扇区Sector。此过程无需擦除片内Flash。校验与签名写入完成后Bootloader读回外部Flash数据计算哈希值并与服务器下发的数字签名RSA/ECDSA比对。签名验证是外挂型安全性的基石防止恶意固件注入。镜像激活校验通过后Bootloader不擦除片内App区而是将外部Flash中新固件的起始地址、大小、校验摘要等元数据写入片内Flash的一个专用配置区如0x0000_4000。该配置区需支持单字节更新常采用EEPROM模拟或wear-leveling算法。启动加载系统复位后Bootloader读取配置区获知新固件位于外部Flash的哪个地址。随后它将外部Flash中固件的前几KB含向量表与Reset Handler动态拷贝至片内SRAM并跳转至SRAM中执行。更高级的做法是实现XIPeXecute-In-Place直接从SPI Flash执行代码但这对Flash型号与MCU SPI控制器有严格要求需支持Quad SPI与DTR模式。5. Flash划分决策树基于资源、安全与维护性的综合评估选择何种Flash划分方式绝非技术偏好而是对项目全生命周期成本的审慎权衡。下表总结了三种方式的关键维度对比评估维度独立型嵌入型外挂型片内Flash占用高需预留16-32KB Bootloader极低Bootloader与App共存低仅需Bootloader配置区升级安全性★★★★★物理隔离强回滚★★☆☆☆自覆盖风险高★★★★☆片内零擦写依赖签名升级可靠性★★★★☆双区校验★★☆☆☆无备份失败即停摆★★★★★大容量缓冲断点续传硬件成本无额外BOM无额外BOM SPI Flash芯片≈$0.1-$0.5软件复杂度中需管理多区搬运高链接脚本、向量表重映射高SPI驱动、文件系统、签名验证适用MCU Flash≥64KB64KB且允许JTAG修复任意大小但推荐≥32KB典型应用场景工业PLC、医疗设备、汽车ECU简单传感器节点、玩具、演示板智能家居网关、视频终端、高端IoT决策建议若项目要求车规级可靠性ASIL-B/C或部署于无人值守的远程站点独立型是唯一选择。其双区镜像与物理隔离提供了最坚实的故障屏障。若产品定位为低成本消费电子且固件体积小于32KB嵌入型可快速落地但必须在量产前完成严苛的断电测试在Flash擦写任意时刻断电验证能否恢复。若固件包含大型资源文件如音频、图像、固件差分包或需支持A/B无缝升级用户无感外挂型是技术演进的必经之路。此时SPI Flash的成本已被其带来的产品力提升所覆盖。6. 实践警示超越理论的工程陷阱在真实项目中Flash划分常因忽视底层细节而引发灾难性后果。以下是几个血泪教训6.1 忽视擦除粒度导致的“假成功”某项目采用独立型将Firmware A区划分为48KB但未注意TMPM3H6FWFG的最小擦除单位是4KB页。开发者编写擦除函数时错误地按字节地址调用FLASH_ErasePage(0x00005000)期望擦除单个字节。结果是该函数实际擦除了从0x00005000开始的整个4KB页0x00005000-0x00005FFF而A区的后续页0x00006000等未被擦除。当新固件写入时未擦除页中的旧数据与新数据混合导致程序跑飞。解决方案擦除前必须计算目标地址所属的页基址page_base (address / 4096) * 4096。6.2 启动标志位未保护引发的“启动震荡”另一项目将启动标志位boot_flag存于Flash最后一页。每次升级成功后Bootloader将该页擦除并写入新值。但未考虑Flash页擦除是物理操作若在擦除过程中断电该页将处于全0xFF状态擦除后值。而0xFF恰好被解读为“启动B区”的标志导致系统在A/B区间无限循环重启。解决方案采用双标志位冗余设计。例如定义flag_a 0xAA表示启动A区flag_b 0x55表示启动B区。只有当读取到有效的非0xFF值时才采纳否则默认启动A区。6.3 外挂Flash时钟配置错误某团队选用W25Q801MB进行外挂型升级但MCU的SPI时钟分频系数设置过高导致SCK频率达50MHz远超W25Q80的33MHz规格。初期测试正常但在高温85°C环境下SPI通信开始出现偶发CRC错误固件校验失败。解决方案SPI时钟必须严格遵守器件手册的AC特性表留有20%余量并在高低温箱中进行全温度范围测试。这些案例印证了一个朴素真理固件升级的可靠性不取决于最炫酷的网络协议而根植于对Flash物理特性的敬畏与对每一行底层代码的审慎。