IAP不是一个新话题但真正要把它做到稳定可靠能踩的坑绝不比开发一个新功能少。很多人第一次接触STM32在线IAP升级都是从一张Bootloader原理图、一段跳转代码开始的结果烧进去要么跑飞要么一进中断就死机调了一整天发现只是向量表偏移没设置对。这篇文章我就围绕STM32在线IAP升级从方案选型、Flash分区、协议设计、代码实现到实测排障把它完整讲清楚。适合正在做Bootloader开发的嵌入式工程师也想给手里的小项目加上远程升级能力却不知道从何下手的开发者。1. 什么是STM32在线IAP升级它到底在解决什么问题1.1 IAP、ISP、OTA三者不能搞混先讲清楚概念。IAP全称是In-Application Programming意思是应用程序在运行过程中自己对自己所在的Flash进行编程。听上去有点绕但本质上是把固件更新能力做成应用的一部分设备出厂前烧一版Bootloader引导程序之后用户通过串口、CAN、以太网甚至无线通道把新固件传给BootloaderBootloader再把固件写到App区最后跳转到App运行。ISP是In-System Programming利用芯片出厂时固化的系统引导程序通过串口、USB或JTAG/SWD把程序烧到Flash里。ISP不需要自己写引导程序但它的升级工具和下载器流程依然依赖外部主机属于“离线烧写”。OTA本来是Over-The-Air指的是通过无线网络升级固件比如Wi-Fi、蓝牙、4G。把OTA的传输通道换成有线串口或CAN本质上就是IAP。所以我经常跟同事说IAP是一种机制OTA是它的一种传输场景。做IAP核心是把“接收固件→写Flash→跳转”这套流程打通至于数据用什么方式传过来反而可以后选。为什么非要折腾IAP三个字省成本。设备装到现场、封进壳子之后还想改程序传统做法是拆机、接下载器、重烧一次两次还行产品量大了谁受得了。IAP让设备在网络可达的地方就能自己更新这才是它最大的价值。1.2 Bootloader App双区架构IAP系统的基本盘IAP系统的软件架构通常分成两个部分Bootloader和App。Bootloader放在Flash起始地址也就是0x08000000芯片上电后CPU从那里开始执行。Bootloader的任务很简单初始化基础外设串口、CAN、定时器等检查要不要升级如果要升级就进入接收和写Flash流程如果不需要就跳转到App首地址。App存放在Flash的其他区域比如0x08008000。App就是你的真正业务程序它编译时要把起始地址改成所在区域同时在运行时把中断向量表重映射到对应位置。这两个工程在开发时是独立的最终烧录时Bootloader一次性烧到Flash开头App可以通过Bootloader升级也可以先用下载器临时放到App区。双区架构有几个明显好处第一Bootloader和App互不干扰App崩了只要Bootloader还健康设备就能恢复第二升级逻辑集中在Bootloader里App侧只需要配合一点代码第三同一块板子可以通过更换App实现不同的功能硬件完全不用动。我个人的建议是哪怕你现在用不到远程升级也尽量在产品开发初期就把Boot和App的分区模型搭好。后期再加Bootloader会遇到App需要挪位置、中断向量表要重设、链接脚本要改一堆东西工作量只会更大。1.3 在线升级该走哪条传输通道在线升级的“在线”体现在传输通道上。项目里最常见的几种通道选型我列个表供参考通道典型速率适用场景注意事项串口UART115200bps调试、现场本地升级实现最简单线缆距离短CAN总线500kbps/1Mbps工业设备、车载设备需要CAN收发器距离远抗干扰强以太网10/100Mbps网关、工控、服务器类设备可通过HTTP/TFTP拉取固件包4G/Wi-Fi视模块而定物联网、远程运维需要模组介入协议较复杂适合OTAUSBFull Speed消费类电子、调试工具需要USB协议栈常用于DFU做项目选通道时不要只看快慢。串口虽然慢但最稳定调试时打日志也方便CAN在工业现场比串口可靠得多抗干扰强以太网适合固化在内部网络的设备配合TFTP协议几乎不用自己设计传输协议。对大多数学习者和中小项目我建议先用串口跑通整个IAP流程后面再换通道因为Bootloader侧的编程逻辑和通道无关换通道只需要改收发函数。2. 升级方案设计Flash分区与固件协议2.1 Flash分区怎么规划才安全Flash分区是IAP设计的第一个关键决策。分区没做好后面所有代码都会别扭。以STM32F103ZET6为例它有512KB的Flash起始地址0x08000000结尾0x0807FFFF。我常用的划分方式Bootloader区域0x08000000 ~ 0x08007FFF占32KBApp区域0x08008000 ~ 0x0807BFFF共480KB参数区域0x0807C000 ~ 0x0807FFFF占16KB用于存放升级标志、固件版本、CRC校验结果等Bootloader为什么不能用满因为后续加功能、升级协议版本都要空间留一点余量总没坏处。F1系列的Flash页大小是1KB其他系列可能不同F4有的是2KB一个扇区所以App起始地址必须按页对齐否则擦写Flash时会出现覆盖Bootloader区域的严重事故。参数区域在IAP系统里很容易被忽略但它的价值很大。升级标志、版本号、校验结果这些数据如果放在App里面每次升级App都要改风险高单独划一块参数区Bootloader启动时先读这里再决定下一步动作整个流程就清晰了。Flash容量小怎么办比如只有64KB的芯片Bootloader占16KBApp只能占不到48KB这时候就别想着A/B备份了。把参数区压到一页App区尽量大回滚方案用“失败后重新升级”而不是“自动回滚旧版”。容量紧张时的取舍优先级是Bootloader稳定性 App可用空间 回滚能力。2.2 自定义固件帧结构在线升级的本质是数据传输而数据在总线上传输必须有协议。很多项目用现成的Ymodem协议简单方便但我想说的是自己定义一套轻量协议往往更贴合项目需求排查问题时也更直观。我常用的一套帧结构长这样帧头(2B) | 命令字(1B) | 包序号(2B) | 数据长度(2B) | 数据段(N B) | CRC16(2B) | 帧尾(2B) 0xAA 0x55 | 0x01 | 0x0001 | 0x0100 | 256字节数据 | 0x3A2B | 0x0D 0x0A命令字定义了升级流程的交互命令字方向含义0x00主机→Boot开始升级附带固件总长度、固件CRC32、版本号0x01主机→Boot数据帧附带一段固件数据和该段序号0x02主机→Boot升级结束Boot确认整体校验0x03Boot→主机应答帧ACK表示成功NAK表示失败并附原因0x04主机→Boot查询状态用于重连场景数据长度字段我觉得设成两字节比较稳妥一字节最多255不够用。数据段大小要结合Flash编程方式定我一般用256字节原因后面说。CRC16只对命令字、包序号、数据长度和数据段做计算帧头和帧尾不参与这样接收端可以先找帧头、再做CRC校验逻辑清晰。这套协议还有一个细节包序号一定不能省略。没有序号一旦某一包在传输中丢失接收端无法通知对端重传哪一包。串口偶尔丢一个字节总线通信偶尔丢一包都是正常现象协议里必须有序号机制兜底。2.3 升级主状态机Bootloader的升级流程不建议用一大坨if-else硬堆最好设计成状态机。我实际项目里的状态枚举大致是这样typedef enum { ST_IDLE, // 空闲等待开始帧 ST_START, // 收到开始帧校验固件信息 ST_DATA, // 正在接收数据帧 ST_FINISH, // 收到结束帧整体校验 ST_ERROR, // 错误状态记录错误码 ST_JUMP // 升级成功跳转App } UpgradeState_t;状态转移的核心逻辑IDLE态收到0x00命令字校验固件总长度是否超过App区容量通过后进入STARTSTART态擦除App区全部页面发送ACK进入DATA态。注意擦除动作放在这里而不是放在第一包数据到来时是为了避免过程中掉电导致部分App区被覆盖但Boot又没收到完整数据DATA态收到0x01按序号写入FlashCRC或者序号不对就回NAK并请求重传DATA态收到0x02Boot把已收到的字节数、CRC32和开始帧里声明的内容对比一致则写入“App有效”标志进入JUMP不一致进入ERRORERROR态会打印错误码并等待主机重新发送开始帧这个状态机看起来简单但实际执行时对边界条件的要求很高超时怎么算、重传多少次、掉电后怎么恢复都要在设计时想清楚。我把每个状态都加了一个超时计时比如DATA态超过500ms没有收到新包就强制回到IDLE态避免设备卡死在升级模式里出不来。3. 实操核心Bootloader与App侧代码实现3.1 Bootloader入口判断要不要升级Bootloader的main函数逻辑是所有IAP工程的起点代码风格大同小异int main(void) { // 基础时钟、串口初始化打开指示灯 SystemClock_Config(); MX_USART2_UART_Init(); // 判断是否需要进入升级模式 if (CheckUpdateFlag() 1) { // 进入升级流程 UpgradeProcess(); } else { // 直接跳转App JumpToApp(); } }CheckUpdateFlag的实现有几种方式。最原始的是检测一个GPIO按键电平按住按键上电就进升级更通用的做法是查参数区的Magic标志字比如某地址存储了0xA5A5A5A5就进升级模式。App在收到“升级指令”时可以先把这个标志写到参数区然后调用软复位等Bootloader起来后一查标志自然就进入升级流程了。这里有个细节升级标志一旦写入就要确保在升级成功或失败的流程里把它清除否则会出现一种情况——用户明明升级完了Bootloader一上电又进升级模式卡在等待主机连接。我遇到过好几次最后发现就是标志没清干净。3.2 Flash擦写与数据接收的实现要点Flash写入是IAP的核心动作代码不复杂但细节多。以F1系列和HAL库为例擦除一个页1KB的典型写法FLASH_EraseInitTypeDef eraseCfg {0}; uint32_t pageError 0; HAL_FLASH_Unlock(); eraseCfg.TypeErase FLASH_TYPEERASE_PAGES; eraseCfg.PageAddress app_addr; eraseCfg.NbPages 1; HAL_FLASHEx_Erase(eraseCfg, pageError); HAL_FLASH_Lock();写入一个半字F1必须按半字16位写入F4可以按字32位或双字64位写入HAL_FLASH_Unlock(); HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, app_addr, (uint16_t)data); HAL_FLASH_Lock();写Flash之前必须确保目标区域已经擦除Flash只能把1写成0不能把0写成1。这就是为什么擦除要在写数据之前整体做完而不是边擦边写。如果上一版固件没擦干净新数据写进去就会出现随机错误App跑起来各种怪问题。数据接收这块我强烈建议给串口加DMA至少用中断接收。Bootloader在擦除Flash的时候CPU是卡住的擦一页虽然只要几十毫秒但如果有串口数据在这个窗口到达查询接收方式就丢了。解决方法是用DMA接收把数据先缓存到RAM里擦除完成后再从缓存写入Flash。如果用的还是查询接收建议把串口缓冲区加大到至少两包的大小并用环形缓冲。3.3 从Bootloader跳转到App的注意事项跳转是所有IAP项目里最容易被问到的部分看网上代码可能十个人有十种写法但核心只有几件事校验App区合法性、关闭中断和外设、设置栈指针、跳转到Reset Handler。我常用的跳转函数#define APP_START_ADDR 0x08008000 typedef void (*pFunction)(void); void JumpToApp(void) { uint32_t sp *(volatile uint32_t *)APP_START_ADDR; uint32_t reset *(volatile uint32_t *)(APP_START_ADDR 4); pFunction appEntry; // 栈指针必须落在RAM范围内Reset Handler必须在Flash范围内 if ((sp 0xFFF00000) ! 0x20000000) { // 非法App区停在Bootloader等待重新升级 while (1); } // 关闭全局中断 __disable_irq(); // 复位外设避免将Bootloader的外设状态带到App里 HAL_RCC_DeInit(); SysTick-CTRL 0; SysTick-LOAD 0; SysTick-VAL 0; // 设置App的栈顶指针 __set_MSP(sp); // 取App的Reset Handler地址并跳转 appEntry (pFunction)reset; appEntry(); while (1); }这段代码有几个点要解释清楚。为什么跳转前要关中断因为中断向量表默认还指向Bootloader区域跳转瞬间如果来了一个中断CPU会从Bootloader的向量表里取中断服务函数地址但此时栈指针已经切到App的栈了栈上下文对不上极容易死机。更安全的方法是先关所有外设中断并清掉NVIC里pending的中断标志。为什么HAL_RCC_DeInit()Bootloader初始化过串口、定时器等外设跳转后App会重新初始化这些外设。如果外设的时钟配置还停留在Bootloader的状态App初始化时可能读到错误的状态寄存器导致配置混乱。这条我在实际项目里验证过很多“跳转到App后能跑但串口打印乱码”的诡异问题根源就在外设时钟没复位。为什么那行if ((sp 0xFFF00000) ! 0x20000000)这是App合法性的第一个检查。如果App区是空的或者数据不对跳转进去就是死机。检查时只判断高位是否需要落在RAM范围内是因为不同的STM32型号RAM大小不同但片内RAM的基地址都是0x20000000用这个判断足以过滤掉大量非法地址。3.4 App侧必须做的三件事VTOR、编译地址、固件标志App侧的代码改动比很多人想象的要少但漏掉任何一个都会出问题。第一件事中断向量表重映射。Cortex-M3/M4内核里有一个VTOR寄存器专门存放当前使用的中断向量表基地址。芯片默认值是0x08000000也就是Flash基地址。App被链接到0x08008000之后它的中断服务函数向量表也跟着到了0x08008000但CPU还傻乎乎地按默认地址取向量于是一触发中断就取到了Bootloader代码区的地址跑飞了。解决办法是在App的main函数开头加上一行int main(void) { // 必须在HAL_Init之前设置否则初始化过程一旦发生中断就会出问题 SCB-VTOR 0x08008000; HAL_Init(); ... }注意地址的低几位必须是0VTOR要求128字节对齐你的App起始地址只要是页对齐的天然满足要求。第二件事编译地址。App的链接脚本或IDE的ROM起始地址必须改成0x08008000。Keil里在Options for Target的IROM1里把Start改成0x08008000Size改成0x00078000对应480KB如果用STM32CubeIDE需要在链接脚本里修改FLASH的ORIGIN和LENGTH。这一步漏掉的话编译出来的固件向量表还链在0x08000000即使VTOR设置了向量表本身放的位置也不对App的中断依然会乱。第三件事固件标志。App在正常运行之后可以把参数区里的“App有效”标志写掉表示新固件已经稳定运行。有些方案还会在App启动后通过串口上报自己的版本号让Bootloader或上位机确认当前运行的固件版本方便排查。4. 可靠性设计校验、回滚、掉电保护4.1 CRC校验与固件完整性固件在传输过程中可能被干扰、被截断所以完整性校验不能只靠数据帧的CRC16必须有整体校验。我通常在协议的开始帧里带上整个固件文件的CRC32Bootloader收完所有数据帧后对写入Flash的App区从头到尾算一个CRC32两个值相同才允许跳转。HAL库里可以直接用硬件CRC外设uint32_t crc32_calc(uint32_t *data, uint32_t len) { __HAL_RCC_CRC_CLK_ENABLE(); HAL_CRC_Init(hcrc); return HAL_CRC_Calculate(hcrc, data, len); }但要注意不同平台对CRC32的初始值、位序、结果异或等参数定义可能不同上位机计算固件CRC的算法必须和单片机侧保持一致否则两边算出来的结果永远对不上。我自己踩过这个坑最后老老实实把上位机和Bootloader的CRC算法统一成同样的参数才解决。4.2 回滚策略对比升级最怕的是新固件有Bug写入成功了、也能跳转但跑起来就死机。这时候如果Bootloader没有回滚机制设备就彻底变成砖了。业界常见的两种回滚策略各有取舍。A/B升级是最内涵的方案Flash里放两个App区A区跑旧固件新固件写入B区校验通过后再更新启动标志下次启动运行B区。如果B区运行不稳定由Bootloader或App把标志切回A区。这个方案最稳但代价是Flash容量直接翻倍只适合大容量芯片比如F4/F7/H7系列。小容量芯片比如只有128KB甚至64KB更适合做“故障重刷”方案App区只有一份升级失败后Bootloader不跳转停留在等待接收固件的状态上位机可以重新发送固件包。代价是设备在修复前处于不可用状态但至少不会变砖现场维护人员拿着升级工具重新刷一遍即可。回滚方案的另一个细节是版本号策略升级前先记录旧固件版本升级完成后如果App侧检测到自身运行异常可以在参数区标记回滚请求。这属于较高级的设计常规项目可以先不做。我建议第一步先把A/B或故障重刷的框架搭好再考虑自动回滚。4.3 掉电保护参数标志与写入顺序升级过程中掉电是最糟糕的场景处理不好设备会白屏、死机甚至损坏Flash。保护方案的核心是“写入顺序”。我习惯在参数区维护这样的标志#define APP_VALID_MAGIC 0xA5A5A5A5 // App是健康的 #define APP_INVALID_MAGIC 0xAAAAAAAA // App不可用/正在升级 #define UPDATE_REQUEST_MAGIC 0x5A5A5A5A // 请求进入升级模式升级流程是这样的收到开始帧先写UPDATE_REQUEST_MAGIC表示要进入升级流程擦除App区逐包写入新固件全部写入完成且CRC32整体校验通过再写APP_VALID_MAGICBootloader下一次启动发现APP_VALID_MAGIC有效直接跳转App如果在“逐包写入”阶段掉电启动时Bootloader看到的App区无效或CRC不对不会跳转而是停留在等待升级的状态。因为升级标志和App有效性标志是分步更新的App区数据不完整时有效标志不会被写入安全边界就清晰了。另外一个容易忽略的点写标志位置不要固定一个地址建议放在参数区末尾一个单独的页里。如果标志和App的末尾数据在同一个页App区重新擦除时会连带把标志也擦掉那就麻烦了。5. 实测中的常见问题与排查技巧5.1 跳转后卡死或跑飞这类问题排在IAP故障第一位现象是Bootloader那行跳转执行完设备就卡死了。排查顺序我一般按下面这个来先查App起始地址的前8个字节前4字节是初始栈指针必须落在RAM地址范围0x20000000开头后4字节是Reset Handler地址必须落在Flash范围。打印这两个值基本能排除App区为空、烧录地址错误、链接脚本没改的问题。再查跳转前的中断处理。SysTick在Bootloader里被初始化过如果跳转时不关闭SysTickApp启动时又会初始化一次SysTick容易出问题。记得把SysTick的CTRL、LOAD、VAL全部清零同时调用__disable_irq()关闭全局中断。最后查App侧的VTOR。很多App代码是在HAL_Init之后才设置VTOR这其实存在风险窗口。我的建议是App的main第一行就写SCB-VTOR然后才是HAL_Init。我还遇到过一种特殊情况跳转前Bootloader把串口中断挂在NVIC里没清跳转后App初始化串口时一使能中断CPU立刻进入一个中断服务函数而那个函数地址是Bootloader的遗留值直接HardFault。解决办法是在跳转前调用HAL_NVIC_DisableAllIRQs()并把NVIC的pending位清掉。5.2 升级中断、Flash擦写失败升级到一半断连最常见的原因是串口缓冲溢出。Bootloader一边擦Flash一边用查询方式收串口擦除期间进来的数据全丢了。我在3.2里已经提过这里再强调一次用DMA接收或者把串口接收中断优先级调高让数据先落到RAM缓冲区擦写完成后再处理。Flash写入失败则优先检查三件事有没有先调用HAL_FLASH_Unlock()目标地址是不是页对齐的App区容量是不是不够了。F1的页是1KBF4的低密度扇区有的只有16KB不同芯片差异很大写之前一定要查参考手册里的Flash内存映射表。另一个隐蔽问题芯片开了读保护RDP等级为1或2Flash写保护生效时擦除和编程都会被拒绝。这种情况在量产板上比较常见通过SWD重新设RDP等级才能恢复。如果项目有量产烧录步骤一定要在烧录流程里把读保护状态统一规划好。5.3 升级完成后App功能异常能跳转、能跑但外设不正常十有八九是外设状态被Bootloader污染了。典型现象是App启动后串口打印乱码、GPIO电平不对。原因就是跳转前没有复位外设Bootloader把串口波特率改过、把某个GPIO配置成了输出App重新初始化时配置寄存器里还残留着之前的状态。处理手段就是HAL_RCC_DeInit()把所有外设时钟关掉再把SysTick归零。这里有个细节要注意HAL_RCC_DeInit会影响Flash预取缓冲和时钟树跳转后App的SystemClock_Config会重新配置这没问题。但如果JumpToApp里在HAL_RCC_DeInit之后又调用任何HAL库函数那些函数会因为它内部依赖HAL状态而出现异常所以跳转函数的最后一段尽量只做裸寄存器操作。还有一类问题出在App本身App里用了某个外设中断但没有初始化对应的NVIC使能或者中断优先级分组和Bootloader不一致。升级后死机不一定都是Flash的问题有时候就是两个工程的中断配置互相打架。开发时建议把Boot和App的中断优先级分组设为同一个值比如都是HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4)。6. 实测中的常见问题速查表故障现象可能原因排查方法跳转后死机App首地址数据非法打印栈指针和Reset Handler地址检查是否在合法范围跳转后死机中断向量表偏移未设置App main第一行设置SCB-VTOR确认地址等于App起始地址跳转后死机跳转前中断未关闭干净__disable_irq() 清NVIC pending SysTick归零升级中途断连串口缓冲溢出启用DMA接收或加大环形缓冲Flash写入失败Flash未解锁HAL_FLASH_Unlock()后再操作Flash写入失败地址未按页/扇区对齐查阅参考手册确认页大小Flash写入失败读保护开启检查RDP等级量产时统一规划App能跑但功能异常外设状态被Boot污染跳转前HAL_RCC_DeInit复位所有外设重复进入升级模式升级标志未清除升级成功或失败流程里清除标志CRC校验总失败上位机和设备算法不一致统一CRC参数初始值、位序、输出异或这张表我建议直接打印出来贴在工位旁边很多问题其实看一眼就知道方向了。7. 最后再分享几点个人经验做IAP项目这几年我最大的体会是让系统跑起来只需要半天让它稳定跑一年才是真正的难点。代码里那些看起来不起眼的细节比如跳转前关中断、App区合法性检查、升级标志的写入顺序才是防住线上事故的关键屏障。这里补充三个我习惯用的小技巧算是压箱底的东西。第一在Bootloader和App两条分支里都留一个串口打印的入口。Bootloader启动时打印自己的版本和“upgrade mode”或“app mode”状态App启动时打印自己的版本。这样设备到手插上串口一看日志就知道它停在哪一步排查效率能翻倍。第二升级固件建议用bin文件而不要用hex文件。hex是Intel格式的文本文件包含地址信息和校验段Bootloader解析起来要额外处理分段、字节数、地址对齐等问题复杂度高。bin文件就是纯代码数据从起始地址开始连续排列Bootloader按顺序写Flash就行简单直接。生成bin文件的办法是在IDE里配置一个后处理命令比如Keil的fromelf命令网上资料一搜就有。第三给每个固件包加一个版本字段放在开始帧里。Bootloader可以检查新版本和当前版本是否一致一致就直接拒绝升级。这个功能看起来小但在现场批量维护时特别有用省得运维人员一遍遍刷同一个版本还看不出效果。IAP这套东西看起来是几段代码的拼凑但实际牵扯到芯片架构、编译器、协议、存储布局多个层面。这篇文章讲的是我踩过的坑和验证过的方案如果你正准备做集成建议先拿一块开发板把串口IAP从Boot到App完整跑通再去考虑CAN、以太网、OTA的改造。基础链路稳了剩下的都是锦上添花。
