做嵌入式开发的人十有八九都要碰一次IAP升级。我上次处理的一批工控板卡客户想更新算法参数用串口ISP刷到一半因为现场线缆接触不良加上上位机发包太急几十台里有十几台烧死在半路返厂拆壳用仿真器救回来的场景我现在都记得。那次之后我把整套STM32 IAP固件升级方案重写了一遍重点就是串口环形队列接收模式和一套能自愈的升级链路从此再没出现过升级变砖的情况。这篇文章把这些东西完整写出来为什么Boot和App必须分开布局环形队列怎么设计升级帧协议怎么定Flash擦写和跳转的关键代码以及升级现场最容易翻车的几个点。适合正在给STM32产品做串口升级或者想把自己的Bootloader做得更可靠的工程师参考。1. 为什么IAP引导程序不能只靠官方Demo一次现场升级返修引出的问题1.1 一台运行中的设备为什么升级失败会变成砖很多人觉得IAP就是照着厂商例程把上位机固件发下来、擦一下Flash、跳转一下就完了。但真到产线或客户现场事情没那么简单。串口是字节流没有消息边界接收方如果等攒满一包再解析缓冲区稍小就会溢出擦除Flash需要时间擦除期间如果还在继续收数据旧的接收代码如果没有缓冲机制新数据一样会被丢弃升级过程只要掉一次电或者串口线被碰一下App区域已经擦掉一半设备自然就起不来了。那次现场返修本质上是接收层没有做数据兜底。官方Demo基本是简单数组存满就处理上位机稍一发快中断里来不及处理RXNE标志还没清下一个字节就挤进来了丢帧就开始了。丢一帧顶多重传但如果丢帧后还在继续擦Flash、写Flash那就不是“这包重来”的问题而是整个升级流程被拉到一个不正确的状态。1.2 IAP与ISP的本质区别升级入口必须自己做主ISP是系统编程很多STM32出厂自带ROM里的引导程序可以通过串口或USB DFU下载固件但它有几个硬限制一是会占用专用引脚或需要特定启动模式二是升级过程完全依赖厂商boot逻辑没法做加密、断点续传、版本回滚。而IAP是应用内编程引导代码是自己写在Flash最前面的Boot区App区放业务代码两个程序独立编译。Boot区接收并校验固件完整后跳转到App运行。换句话说ISP是“用别人的通道”IAP是“自己修一条专属通道”。产品交到用户手上之后升级通道、协议、备份策略、异常恢复都必须是自己的这样才能在升级失败时把损失控制住。每次升级前先确认当前App还能不能跑升级中需要能断点续传升级失败后需要让设备自动回到Boot等重试这些都是ISP做不到的。1.3 自定升级链路的核心目标我给自己定的目标很明确升级失败不致命、通信断点能续传、掉电后自然恢复。围绕这三点才推导出后面的分区设计、环形队列、帧校验、双区写入这些方案。如果只是“能下载一个bin文件进去”方案可以很简陋但如果把它当成一个交付给客户的工程特性就必须考虑完整生命周期包括固件写坏了怎么救、升级过程被干扰怎么恢复、上位机断线后设备该怎么表现。这也是我这篇文章标题里强调“处理超强”的原因所谓超强不是接收代码写得多么炫而是整个升级流程在各种异常条件下都不会把设备搞死。下面的内容全部围绕这套目标展开。2. Flash分区与Boot/App分离设计先把内存地图画清楚2.1 一张分区表搞定三类关键区域做IAP第一件事不是写代码而是把Flash分区定下来。STM32的Flash起始地址是0x08000000但IAP方案必须把这块物理空间切成几个逻辑区域。我这里以一个512KB Flash的芯片为例实际项目按你的芯片容量和App大小调整区域名称起始地址大小用途Boot区0x0800000064KBIAP引导程序、串口升级协议、Flash擦写与跳转逻辑App区0x08010000320KB业务固件用户主程序下载缓存区0x08060000128KB上位机发来的新固件临时存放参数区0x0807E0008KB升级标志、App版本、App长度、CRC校验值Boot区放引导程序它负责和上位机通信、接收固件包、校验完整后把固件写入App区最后跳转。App区是业务代码它平时正常跑不参与升级逻辑。下载缓存区是整个方案里最关键的一环上位机发来的数据先写入这里等收完、验完CRC才去擦除App区并把新固件从缓存区复制到App区。这样即使写App过程中断电Boot区还能从缓存区把App重新刷回来设备永远不会因为“擦了一半”而彻底变砖。参数区存升级状态和校验信息。比如升级是否开始过、App区是否有效、最后的CRC是多少。每次上电Boot先查参数区再决定是直接跳App还是继续上一次升级或者等待新固件。2.2 App工程如何编译到偏移地址这三处必须同时改Boot和App不是一个工程是两个独立编译工程。App工程编译出来的代码必须知道自己未来会运行在0x08010000这个地址而不能从0x08000000开始。否则Boot跳转到App时整个程序的入口地址、中断向量位置全部对不上。第一处是IDE的ROM起始地址设置。用Keil的话在Target选项里的IROM1里把Start改成App的起始地址比如0x08010000Size改成App区大小0x50000用IAR的话在Linker配置里覆盖默认ROM范围用GCC加link script的话把Flash区域的ORIGIN改成0x08010000LENGTH改成0x50000。第二处是中断向量表。STM32上电默认从Flash最底部0x08000000取向量表App运行在0x08010000必须让CPU知道新的向量表在哪。后面专门说。第三处是Boot跳转时读地址的方式。App的起始地址处放的是初始栈指针偏移4字节处放的是复位中断函数地址。Boot跳转时要按这个布局去取App编译时不用额外处理只要链接地址对了这两个值自然存在bin文件头。2.3 中断向量表重定向App启动的第一道坎Cortex-M内核默认在0x00000000处取向量表而App的向量表在0x08010000。如果跳转后不重定向任何一个中断触发都会跳到错误地址结果不是HardFault就是整个系统卡死。F4及之后的芯片通常有VTOR寄存器直接写偏移即可#define APP_BASE_ADDR 0x08010000 void RedirectVectorTable(void) { SCB-VTOR APP_BASE_ADDR; }注意VTOR的值需要对齐到向量表大小边界一般是0x200的倍数0x08010000符合要求。如果你用的是F1系列或者老的库有些型号没有VTOR就需要把向量表搬到SRAM再用NVIC_SetVectorTable设置偏移我一般直接用官方库提供的方式原理是一样的。关键是跳转前必须完成重定向否则App启动后第一个定时器中断就会让你头疼很久。3. 串口环形队列接收模块让中断像快递柜一样只存取、不纠缠3.1 简单数组为什么扛不住连续发送IAP升级时上位机通常以115200波特率连续发包每秒约11520字节。也就是说每两个字节之间大约87微秒。如果主循环正在做一些耗时操作比如擦除Flash要几毫秒甚至几十毫秒期间串口会堆进来几十个字节。用最简单的单字节数组做缓冲第2个字节到达时缓冲区已被第1个字节占满新字节直接把旧数据覆盖掉。处理不好就是满屏校验失败。如果主循环的处理逻辑是“收完一整包校验CRC”那么缓冲区的容量至少得覆盖一包数据加上擦除Flash期间的积压量。更干净的做法是串口中断里只做一件非常快速的事情把收到的字节丢进环形队列然后立刻退出。所有协议解析、校验、写Flash都在主循环里做。3.2 环形队列结构体与初始化代码环形队列本质上是一个数组配上两个指针写入指针head和读取指针tail。每写一个字节head加1每读一个字节tail加1。当head追上tail说明队列空当tail追上head说明队列满。为了效率我习惯把缓冲区大小定义成2的幂这样取余操作可以用位与运算替换。#define RBUF_SIZE 2048 #define RBUF_MASK (RBUF_SIZE - 1) typedef struct { volatile uint8_t data[RBUF_SIZE]; volatile uint16_t head; volatile uint16_t tail; volatile uint32_t overflow_cnt; } RingBuf_t; void RB_Init(RingBuf_t *rb) { rb-head 0; rb-tail 0; rb-overflow_cnt 0; }volatile关键字绝对不能省。head和tail一个在中断里写一个在主循环里写如果不加volatile编译器优化后主循环可能读到一个被缓存的值判断就全乱了。写一个字节的函数如下uint8_t RB_Push(RingBuf_t *rb, uint8_t ch) { uint16_t next (rb-head 1) RBUF_MASK; if (next rb-tail) { rb-overflow_cnt; return 0; } rb-data[rb-head] ch; rb-head next; return 1; }这个写法是有意不覆盖旧数据的。对于IAP这种对完整性要求极高的场景宁可丢新数据也不应该把已经收好的数据破坏掉。丢了之后上位机有重传机制但如果旧数据被覆盖整个队列的数据可能全乱。读一个字节的函数uint8_t RB_Pop(RingBuf_t *rb, uint8_t *ch) { if (rb-head rb-tail) { return 0; } *ch rb-data[rb-tail]; rb-tail (rb-tail 1) RBUF_MASK; return 1; } uint16_t RB_Count(RingBuf_t *rb) { return (rb-head - rb-tail) RBUF_MASK; }3.3 串口中断里只放数据主循环里再分析串口中断处理函数里不要做协议解析不要判断帧头帧尾更不要写Flash。中断里做这些事一方面会拖长中断处理时间另一方面会把协议状态机搞得很复杂。我的做法是中断里只做一件事void USART1_IRQHandler(void) { uint8_t ch; if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { ch (uint8_t)USART_ReceiveData(USART1); RB_Push(g_rxRing, ch); } }主循环里再不断从队列取字节喂给帧解析状态机。串口中断到帧解析之间数据被环形队列完全解耦。主循环就算去擦Flash、去算CRC串口来的数据也都能暂存在队列里不会丢。我用115200波特率做过压力测试上位机连续发数据队列容量2048字节主循环还有几百个微秒的解包时间队列占用率基本不超过一半。只有在Flash擦除期间队列才会明显上涨但2048字节的余量足够覆盖单次擦除时间。3.4 环形队列的溢出保护与并发注意点环形队列的溢出保护在上面的RB_Push里已经有了满了就返回0并记到overflow_cnt。调试时如果发现overflow_cnt非零说明主循环处理速度确实跟不上就需要扩容或者优化解析逻辑。正式产品里我还会在Boot里预留一个寄存器变量升级开始前清零升级结束后打印出来方便远程诊断。主循环读取时要稍微注意并发问题。虽然RB_Pop在单核Cortex-M上不会被打断但编译器优化和中断写入head之间仍然存在理论上的竞态。稳妥的做法是读之前做一次保护uint8_t RB_PopSafe(RingBuf_t *rb, uint8_t *ch) { uint16_t head; uint16_t tail; uint8_t data_item; uint8_t ret 0; __disable_irq(); head rb-head; tail rb-tail; __enable_irq(); if (head ! tail) { data_item rb-data[tail]; tail (tail 1) RBUF_MASK; __disable_irq(); rb-tail tail; __enable_irq(); *ch data_item; ret 1; } return ret; }如果对实时性要求很高也可以用临界区替代关全局中断原理一样。总之中断上下文和主循环上下文对同一个队列操作时不要理所当然地认为“就改一个指针不会出问题”。4. 升级协议帧格式与状态机解析给字节流画出一条边界4.1 帧格式设计我从帧头到CRC字段都做了什么串口是纯字节流如果没有协议边界收端根本不知道哪几个字节属于同一包。我的IAP协议帧格式如下字段长度说明帧头2字节0xAA 0x55命令1字节握手、开始、数据、结束、查询状态等包序号2字节大端序用于重传和去重数据长度2字节当前帧数据区长度最大1024数据区N字节固件内容或命令参数CRC324字节对帧头之后、CRC之前的所有字节做校验帧头用两个字节而不是一个是为了降低误同步概率。0xAA 0x55在二进制里是10101010 01010101连续两个字节都匹配才认为进入帧解析误判率低很多。包序号非常关键。升级嘛几千包数据网络再稳定也可能偶发丢包。有了序号设备就能告诉上位机“你刚才那包我没收到”或者“我收到了重复包我也认了”。数据长度放2字节是为了支持最大64KB的分包但实际我一般限制单帧数据区最大256字节理由后面讲。CRC32选用标准多项式0xEDB88320查表法实现计算很快。注意CRC覆盖范围要把帧头排除、CRC本身排除否则自己校验自己逻辑上就是错的。4.2 字节流解析状态机的骨架代码状态机是串口解析的标准做法每收到一个字节根据当前状态决定下一步。我常用的状态定义#define ST_IDLE 0 #define ST_HEAD2 1 #define ST_CMD 2 #define ST_SEQ 3 #define ST_LEN 4 #define ST_DATA 5 #define ST_CRC 6解析主流程void UartParseByte(uint8_t ch) { static uint8_t state ST_IDLE; static uint8_t cmd; static uint16_t seq; static uint16_t len; static uint16_t idx; static uint32_t raw_crc; switch (state) { case ST_IDLE: if (ch 0xAA) state ST_HEAD2; break; case ST_HEAD2: if (ch 0x55) state ST_CMD; else state ST_IDLE; break; case ST_CMD: cmd ch; seq 0; len 0; idx 0; raw_crc 0; state ST_SEQ; break; case ST_SEQ: seq (seq 8) | ch; if (state ST_SEQ) state ST_LEN; break; case ST_LEN: len (len 8) | ch; if (state ST_LEN) state ST_DATA; else state ST_SEQ; break; default: break; } }真实工程里我会把SEQ和LEN都改成接收完两个字节再切状态上面这个写法只是示意。状态机的好处是解析逻辑和串口速率无关来一个字节处理一个字节不会因为一帧太长而卡住。收到完整一帧后先本地计算CRC比对raw_crc字段再根据命令字分发。CRC不一致就回复NACK让上位机按序号重传这一包。4.3 应答、重传与重复包处理通信不能只看收得稳帧解析出来后设备的操作分为三类对握手命令回复设备型号和当前固件版本对数据命令校验CRC成功写Flash缓存区并回复ACK失败回复NACK对结束命令做整包CRC复核然后执行App区刷新和跳转。上位机侧的核心逻辑是“发一包等ACK”。默认超时200ms超时未收到就重发当前包。如果设备收到的是重复包序号设备不需要重写Flash只需要再回复一次ACK让上位机能继续往前走。这个处理很微妙重复包来了就重写一次也没错但会浪费擦写时间和Flash寿命直接忽略又会让上位机一直重试。所以判断序号是否大于当前已写入序号大于才写小于等于就直接ACK。上位机发完所有数据包后必须发送结束帧。设备收到结束帧后才对下载缓存区的数据做整体CRC校验。这个整体CRC在升级开始帧里就已经告诉设备了等于双保险单帧CRC保证链路传输没有丢包总CRC保证整份固件没有完整性风险。4.4 波特率与升级耗时的工程测算115200波特率8N1格式有效数据速率约11520字节/秒。假设每帧数据区256字节帧总开销11字节单帧267字节那么每秒大约能发43帧传输1MB固件约91秒加上握手、写Flash、校验总时间约2分钟以内。这个速度对绝大多数OTA场景足够。如果把单帧数据区改成1024字节帧数变少重传粒度变大单帧出错重传的代价也更大。把单帧数据区改成32字节则帧数太多帧头开销占比高传输效率下降。我实测下来256字节是嵌入式串口IAP比较均衡的选择也方便和Flash的编程最小单位对齐。如果产品允许也可以把波特率提到460800甚至1M。但我在工控现场吃过线缆接触不良的亏传输速度越快波形质量要求越高。115200在双绞屏蔽线上可以做到很长的线缆和很强的抗干扰所以我的默认方案不追求极限速度追求稳定。5. Flash擦写与App跳转实现最关键代码的写法与边界5.1 Flash解锁、擦除、写入三个操作各有各的禁忌STM32的Flash有严格的保护机制操作前必须解锁操作完必须重新上锁。解锁序列、擦除单位、编程宽度因型号而异。F1系列的页大小通常1KB或2KB编程宽度是half wordF4系列则一个扇区可能64KB甚至128KB编程宽度是32位字。动手前一定要查对应型号的参考手册和数据手册这里最容易翻车。常规流程如下void Flash_ProgramBytes(uint32_t addr, uint8_t *buf, uint32_t len) { uint32_t i; uint16_t half; FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_BSY | FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); for (i 0; i len; i 2) { half buf[i] | ((uint16_t)buf[i 1] 8); if (FLASH_ProgramHalfWord(addr i, half) ! FLASH_COMPLETE) { break; } } FLASH_Lock(); }注意一个关键点Flash只要有“写1变0”的能力没有“写0变1”的能力。只有当Flash单元处于擦除后的0xFF状态才能写入期望的数值。所以在写之前目标扇区必须预先擦除。擦除和写入是两个独立操作不能指望一个Program函数自动完成擦除。擦除还有一个特性擦除是整个页或整个扇区一起做的不能只擦某几个字节。所以修改固件时只要App区内容有变化就需要整页擦除再重写。这也正是升级时必须把新固件先缓存到下载区的原因之一。5.2 用下载区缓存固件写App前先做完整性校验我的升级流程是这样编排的上位机握手设备回复当前版本。上位机发送升级开始帧设备记录目标长度和总CRC。上位机逐包发送固件数据设备逐包写入下载缓存区。上位机发送升级结束帧设备对下载缓存区做总CRC复核。CRC通过后擦除App区把下载缓存区数据复制到App区。复制完成后对App区做读回比对或者CRC校验。设置“App有效”标志跳转App。这套流程里App区永远是最后才动的。哪怕升级到第3000包突然断电下载缓存区里可能只有3000包的残数据但App区还是完好的旧版。设备重新上电后Boot发现升级没有完成可以等上位机重新连接后继续或者直接跳转到旧App让设备继续工作。如果贪图省流直接把上位机数据包写进App区中途断电就会出现“旧固件被擦了一半新固件还没写完”的恐怖状态。这也是很多设备升级变砖的根源。5.3 从Boot跳转到App栈顶校验与中断关断顺序跳转函数是Boot的最后一步代码如下#define APP_BASE_ADDR 0x08010000 typedef void (*AppFunc_t)(void); void Boot_JumpToApp(void) { uint32_t app_msp; uint32_t app_reset; __disable_irq(); /* App起始地址前4字节是初始栈指针偏移4字节是复位函数地址 */ app_msp *(volatile uint32_t *)APP_BASE_ADDR; app_reset *(volatile uint32_t *)(APP_BASE_ADDR 4); /* 简单边界校验栈指针应在SRAM区间复位地址应在Flash区间 */ if ((app_msp 0x2FF00000) ! 0x20000000) { return; } if ((app_reset 0x2FF00000) ! 0x08000000) { return; } /* 重定向中断向量表 */ SCB-VTOR APP_BASE_ADDR; /* 设置主栈指针然后跳转 */ __set_MSP(app_msp); ((AppFunc_t)app_reset)(); }跳转前关中断是必须的。如果在Boot阶段串口中断还在跑或者某个定时器中断已经pending一旦跳进AppApp里还没有完成外设初始化中断一来就按半初始化状态的寄存器执行很容易触发HardFault。所以我习惯在跳转前把所有外设中断都关闭等App初始化完毕后由App自己重新打开需要的中断。边界校验同样重要。栈指针前三位应该在0x20000000附近复位地址前三位应该在0x08000000附近。这个校验能挡住“App区全是0xFF”或“App区被误写入文件头”等低级错误。5.4 跳转前的最后检查清单我自己每次跳转前都会过一遍清单[ ] 下载缓存区总CRC已经通过App区数据完整。[ ] App区复制完成后已经读回比对没有字节错位。[ ] 全局中断已关闭PendSV、SysTick和所有外设中断都处于关闭状态。[ ] 串口DMA如果开了也要关掉并清理标志避免跳转后DMA还在向内存搬运数据。[ ] 片上外设的时钟状态已恢复到App可接受的范围。这个清单的本质是把Boot“收拾干净”别让上一个程序的影子影响下一个程序的运行。6. 异常恢复与实测经验把升级做成一个闭环6.1 看门狗与升级超时机制设备永远有退路IAP升级时最怕的不是数据发错而是整个流程卡死。上位机崩溃、串口断开、后台调度异常都可能让设备停在某个状态不动作。因此Boot阶段必须开启独立看门狗IWDG并且只在“完整处理完一帧并正常回复ACK”后才喂狗。如果超过预设时间没有收到任何合法帧看门狗就会复位设备Boot重新启动回到等待升级的初始状态。喂狗的时机非常讲究。不要在串口中断里喂狗因为如果主循环已经卡死但串口还在收数据中断喂狗会把设备伪装成活着的状态实际系统早就没有推进力了。一定要在主循环处理完一帧之后的末尾喂确保“协议处理进度”在真正推进。有了看门狗和超时重传整个升级流程就有了兜底上位机发不出数据设备自己复位重来上位机一直乱发设备状态机始终不匹配就不动用户手动断电设备回到Boot等下一次升级或者跑旧App。6.2 升级状态保存与变量区管理我习惯在参数区固定地址保存一组“升级状态”数据。包括魔数比如0xA5A5F00F用于判断参数是否有效。当前升级状态IDLE、RECEIVING、VERIFYING、READY_TO_JUMP。已接收包序号用于断点续传时上位机快速定位。App区有效标志上次App运行是否正常退出。App长度、总CRC用于校验和版本管理。设备每次上电Boot先读参数区。如果App有效标志正常就快速跳转App如果App有效标志异常说明之前App崩溃或升级失败Boot就等待上位机重新刷机不跳转。这个机制能把很多软故障变成现场可恢复的升级任务。参数区写入也有讲究。参数区一般很小写入次数受Flash寿命限制不能每个包都写。我的做法是在升级开始帧收到后才写一次“RECEIVING”结束帧CRC通过后再写一次“READY_TO_JUMP”。中间几万包数据不写参数区只在RAM里维护标志直到事务结束才落Flash。6.3 三个让我印象深刻的翻车现场和修法第一个情况是上位机发包太快设备环形队列溢出。当时我统计overflow_cnt发现每几千包就会丢一两次设备这边没有及时重发请求上位机还在傻乎乎往下发最后CRC不过。修法有两个层面协议层加ACK/NACK和重传机制应用层把每包之间的延时从5ms提到20ms。实测下来丢包率直接降到零。第二个情况是擦除App扇区时串口中断持续涌入数据。因为当时用的还是直接把App区作为写入目标的方案擦除期间主循环没法处理队列队列深度一度涨到接近容量上限。后来改成缓存区方案后这个问题从根上消失了——所有数据都在进入缓存区时收完了擦App区时已经不需要再接收新数据。第三个情况最隐蔽跳转后App跑几秒就HardFault。排查了很久才发现是中断向量表重定向的地址没有按0x200对齐SCB-VTOR写入了一个非法的对齐值导致中断向量表映射错乱。这个坑容易忽略一定要查参考手册里对VTOR位字段的说明并按向量表的对齐要求取值。最后说一个我的个人习惯不管IAP做得多么稳我始终保留SWD/JTAG调试接口。万一Boot区本身被刷坏或者整个Flash被锁死没有编程器谁都救不了。升级代码越稳越要保持这条后门。另外上位机和下位机最好共用同一份协议头文件帧头、命令字、CRC算法都做成宏两边各写各的校验算法是最容易出低级问题的我见过不止一次因为CRC初始值不同导致整包被拒。先把这些细节钉死剩下的就交给时间和现场了。
做嵌入式开发的人十有八九都要碰一次IAP升级。我上次处理的一批工控板卡客户想更新算法参数用串口ISP刷到一半因为现场线缆接触不良加上上位机发包太急几十台里有十几台烧死在半路返厂拆壳用仿真器救回来的场景我现在都记得。那次之后我把整套STM32 IAP固件升级方案重写了一遍重点就是串口环形队列接收模式和一套能自愈的升级链路从此再没出现过升级变砖的情况。这篇文章把这些东西完整写出来为什么Boot和App必须分开布局环形队列怎么设计升级帧协议怎么定Flash擦写和跳转的关键代码以及升级现场最容易翻车的几个点。适合正在给STM32产品做串口升级或者想把自己的Bootloader做得更可靠的工程师参考。1. 为什么IAP引导程序不能只靠官方Demo一次现场升级返修引出的问题1.1 一台运行中的设备为什么升级失败会变成砖很多人觉得IAP就是照着厂商例程把上位机固件发下来、擦一下Flash、跳转一下就完了。但真到产线或客户现场事情没那么简单。串口是字节流没有消息边界接收方如果等攒满一包再解析缓冲区稍小就会溢出擦除Flash需要时间擦除期间如果还在继续收数据旧的接收代码如果没有缓冲机制新数据一样会被丢弃升级过程只要掉一次电或者串口线被碰一下App区域已经擦掉一半设备自然就起不来了。那次现场返修本质上是接收层没有做数据兜底。官方Demo基本是简单数组存满就处理上位机稍一发快中断里来不及处理RXNE标志还没清下一个字节就挤进来了丢帧就开始了。丢一帧顶多重传但如果丢帧后还在继续擦Flash、写Flash那就不是“这包重来”的问题而是整个升级流程被拉到一个不正确的状态。1.2 IAP与ISP的本质区别升级入口必须自己做主ISP是系统编程很多STM32出厂自带ROM里的引导程序可以通过串口或USB DFU下载固件但它有几个硬限制一是会占用专用引脚或需要特定启动模式二是升级过程完全依赖厂商boot逻辑没法做加密、断点续传、版本回滚。而IAP是应用内编程引导代码是自己写在Flash最前面的Boot区App区放业务代码两个程序独立编译。Boot区接收并校验固件完整后跳转到App运行。换句话说ISP是“用别人的通道”IAP是“自己修一条专属通道”。产品交到用户手上之后升级通道、协议、备份策略、异常恢复都必须是自己的这样才能在升级失败时把损失控制住。每次升级前先确认当前App还能不能跑升级中需要能断点续传升级失败后需要让设备自动回到Boot等重试这些都是ISP做不到的。1.3 自定升级链路的核心目标我给自己定的目标很明确升级失败不致命、通信断点能续传、掉电后自然恢复。围绕这三点才推导出后面的分区设计、环形队列、帧校验、双区写入这些方案。如果只是“能下载一个bin文件进去”方案可以很简陋但如果把它当成一个交付给客户的工程特性就必须考虑完整生命周期包括固件写坏了怎么救、升级过程被干扰怎么恢复、上位机断线后设备该怎么表现。这也是我这篇文章标题里强调“处理超强”的原因所谓超强不是接收代码写得多么炫而是整个升级流程在各种异常条件下都不会把设备搞死。下面的内容全部围绕这套目标展开。2. Flash分区与Boot/App分离设计先把内存地图画清楚2.1 一张分区表搞定三类关键区域做IAP第一件事不是写代码而是把Flash分区定下来。STM32的Flash起始地址是0x08000000但IAP方案必须把这块物理空间切成几个逻辑区域。我这里以一个512KB Flash的芯片为例实际项目按你的芯片容量和App大小调整区域名称起始地址大小用途Boot区0x0800000064KBIAP引导程序、串口升级协议、Flash擦写与跳转逻辑App区0x08010000320KB业务固件用户主程序下载缓存区0x08060000128KB上位机发来的新固件临时存放参数区0x0807E0008KB升级标志、App版本、App长度、CRC校验值Boot区放引导程序它负责和上位机通信、接收固件包、校验完整后把固件写入App区最后跳转。App区是业务代码它平时正常跑不参与升级逻辑。下载缓存区是整个方案里最关键的一环上位机发来的数据先写入这里等收完、验完CRC才去擦除App区并把新固件从缓存区复制到App区。这样即使写App过程中断电Boot区还能从缓存区把App重新刷回来设备永远不会因为“擦了一半”而彻底变砖。参数区存升级状态和校验信息。比如升级是否开始过、App区是否有效、最后的CRC是多少。每次上电Boot先查参数区再决定是直接跳App还是继续上一次升级或者等待新固件。2.2 App工程如何编译到偏移地址这三处必须同时改Boot和App不是一个工程是两个独立编译工程。App工程编译出来的代码必须知道自己未来会运行在0x08010000这个地址而不能从0x08000000开始。否则Boot跳转到App时整个程序的入口地址、中断向量位置全部对不上。第一处是IDE的ROM起始地址设置。用Keil的话在Target选项里的IROM1里把Start改成App的起始地址比如0x08010000Size改成App区大小0x50000用IAR的话在Linker配置里覆盖默认ROM范围用GCC加link script的话把Flash区域的ORIGIN改成0x08010000LENGTH改成0x50000。第二处是中断向量表。STM32上电默认从Flash最底部0x08000000取向量表App运行在0x08010000必须让CPU知道新的向量表在哪。后面专门说。第三处是Boot跳转时读地址的方式。App的起始地址处放的是初始栈指针偏移4字节处放的是复位中断函数地址。Boot跳转时要按这个布局去取App编译时不用额外处理只要链接地址对了这两个值自然存在bin文件头。2.3 中断向量表重定向App启动的第一道坎Cortex-M内核默认在0x00000000处取向量表而App的向量表在0x08010000。如果跳转后不重定向任何一个中断触发都会跳到错误地址结果不是HardFault就是整个系统卡死。F4及之后的芯片通常有VTOR寄存器直接写偏移即可#define APP_BASE_ADDR 0x08010000 void RedirectVectorTable(void) { SCB-VTOR APP_BASE_ADDR; }注意VTOR的值需要对齐到向量表大小边界一般是0x200的倍数0x08010000符合要求。如果你用的是F1系列或者老的库有些型号没有VTOR就需要把向量表搬到SRAM再用NVIC_SetVectorTable设置偏移我一般直接用官方库提供的方式原理是一样的。关键是跳转前必须完成重定向否则App启动后第一个定时器中断就会让你头疼很久。3. 串口环形队列接收模块让中断像快递柜一样只存取、不纠缠3.1 简单数组为什么扛不住连续发送IAP升级时上位机通常以115200波特率连续发包每秒约11520字节。也就是说每两个字节之间大约87微秒。如果主循环正在做一些耗时操作比如擦除Flash要几毫秒甚至几十毫秒期间串口会堆进来几十个字节。用最简单的单字节数组做缓冲第2个字节到达时缓冲区已被第1个字节占满新字节直接把旧数据覆盖掉。处理不好就是满屏校验失败。如果主循环的处理逻辑是“收完一整包校验CRC”那么缓冲区的容量至少得覆盖一包数据加上擦除Flash期间的积压量。更干净的做法是串口中断里只做一件非常快速的事情把收到的字节丢进环形队列然后立刻退出。所有协议解析、校验、写Flash都在主循环里做。3.2 环形队列结构体与初始化代码环形队列本质上是一个数组配上两个指针写入指针head和读取指针tail。每写一个字节head加1每读一个字节tail加1。当head追上tail说明队列空当tail追上head说明队列满。为了效率我习惯把缓冲区大小定义成2的幂这样取余操作可以用位与运算替换。#define RBUF_SIZE 2048 #define RBUF_MASK (RBUF_SIZE - 1) typedef struct { volatile uint8_t data[RBUF_SIZE]; volatile uint16_t head; volatile uint16_t tail; volatile uint32_t overflow_cnt; } RingBuf_t; void RB_Init(RingBuf_t *rb) { rb-head 0; rb-tail 0; rb-overflow_cnt 0; }volatile关键字绝对不能省。head和tail一个在中断里写一个在主循环里写如果不加volatile编译器优化后主循环可能读到一个被缓存的值判断就全乱了。写一个字节的函数如下uint8_t RB_Push(RingBuf_t *rb, uint8_t ch) { uint16_t next (rb-head 1) RBUF_MASK; if (next rb-tail) { rb-overflow_cnt; return 0; } rb-data[rb-head] ch; rb-head next; return 1; }这个写法是有意不覆盖旧数据的。对于IAP这种对完整性要求极高的场景宁可丢新数据也不应该把已经收好的数据破坏掉。丢了之后上位机有重传机制但如果旧数据被覆盖整个队列的数据可能全乱。读一个字节的函数uint8_t RB_Pop(RingBuf_t *rb, uint8_t *ch) { if (rb-head rb-tail) { return 0; } *ch rb-data[rb-tail]; rb-tail (rb-tail 1) RBUF_MASK; return 1; } uint16_t RB_Count(RingBuf_t *rb) { return (rb-head - rb-tail) RBUF_MASK; }3.3 串口中断里只放数据主循环里再分析串口中断处理函数里不要做协议解析不要判断帧头帧尾更不要写Flash。中断里做这些事一方面会拖长中断处理时间另一方面会把协议状态机搞得很复杂。我的做法是中断里只做一件事void USART1_IRQHandler(void) { uint8_t ch; if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { ch (uint8_t)USART_ReceiveData(USART1); RB_Push(g_rxRing, ch); } }主循环里再不断从队列取字节喂给帧解析状态机。串口中断到帧解析之间数据被环形队列完全解耦。主循环就算去擦Flash、去算CRC串口来的数据也都能暂存在队列里不会丢。我用115200波特率做过压力测试上位机连续发数据队列容量2048字节主循环还有几百个微秒的解包时间队列占用率基本不超过一半。只有在Flash擦除期间队列才会明显上涨但2048字节的余量足够覆盖单次擦除时间。3.4 环形队列的溢出保护与并发注意点环形队列的溢出保护在上面的RB_Push里已经有了满了就返回0并记到overflow_cnt。调试时如果发现overflow_cnt非零说明主循环处理速度确实跟不上就需要扩容或者优化解析逻辑。正式产品里我还会在Boot里预留一个寄存器变量升级开始前清零升级结束后打印出来方便远程诊断。主循环读取时要稍微注意并发问题。虽然RB_Pop在单核Cortex-M上不会被打断但编译器优化和中断写入head之间仍然存在理论上的竞态。稳妥的做法是读之前做一次保护uint8_t RB_PopSafe(RingBuf_t *rb, uint8_t *ch) { uint16_t head; uint16_t tail; uint8_t data_item; uint8_t ret 0; __disable_irq(); head rb-head; tail rb-tail; __enable_irq(); if (head ! tail) { data_item rb-data[tail]; tail (tail 1) RBUF_MASK; __disable_irq(); rb-tail tail; __enable_irq(); *ch data_item; ret 1; } return ret; }如果对实时性要求很高也可以用临界区替代关全局中断原理一样。总之中断上下文和主循环上下文对同一个队列操作时不要理所当然地认为“就改一个指针不会出问题”。4. 升级协议帧格式与状态机解析给字节流画出一条边界4.1 帧格式设计我从帧头到CRC字段都做了什么串口是纯字节流如果没有协议边界收端根本不知道哪几个字节属于同一包。我的IAP协议帧格式如下字段长度说明帧头2字节0xAA 0x55命令1字节握手、开始、数据、结束、查询状态等包序号2字节大端序用于重传和去重数据长度2字节当前帧数据区长度最大1024数据区N字节固件内容或命令参数CRC324字节对帧头之后、CRC之前的所有字节做校验帧头用两个字节而不是一个是为了降低误同步概率。0xAA 0x55在二进制里是10101010 01010101连续两个字节都匹配才认为进入帧解析误判率低很多。包序号非常关键。升级嘛几千包数据网络再稳定也可能偶发丢包。有了序号设备就能告诉上位机“你刚才那包我没收到”或者“我收到了重复包我也认了”。数据长度放2字节是为了支持最大64KB的分包但实际我一般限制单帧数据区最大256字节理由后面讲。CRC32选用标准多项式0xEDB88320查表法实现计算很快。注意CRC覆盖范围要把帧头排除、CRC本身排除否则自己校验自己逻辑上就是错的。4.2 字节流解析状态机的骨架代码状态机是串口解析的标准做法每收到一个字节根据当前状态决定下一步。我常用的状态定义#define ST_IDLE 0 #define ST_HEAD2 1 #define ST_CMD 2 #define ST_SEQ 3 #define ST_LEN 4 #define ST_DATA 5 #define ST_CRC 6解析主流程void UartParseByte(uint8_t ch) { static uint8_t state ST_IDLE; static uint8_t cmd; static uint16_t seq; static uint16_t len; static uint16_t idx; static uint32_t raw_crc; switch (state) { case ST_IDLE: if (ch 0xAA) state ST_HEAD2; break; case ST_HEAD2: if (ch 0x55) state ST_CMD; else state ST_IDLE; break; case ST_CMD: cmd ch; seq 0; len 0; idx 0; raw_crc 0; state ST_SEQ; break; case ST_SEQ: seq (seq 8) | ch; if (state ST_SEQ) state ST_LEN; break; case ST_LEN: len (len 8) | ch; if (state ST_LEN) state ST_DATA; else state ST_SEQ; break; default: break; } }真实工程里我会把SEQ和LEN都改成接收完两个字节再切状态上面这个写法只是示意。状态机的好处是解析逻辑和串口速率无关来一个字节处理一个字节不会因为一帧太长而卡住。收到完整一帧后先本地计算CRC比对raw_crc字段再根据命令字分发。CRC不一致就回复NACK让上位机按序号重传这一包。4.3 应答、重传与重复包处理通信不能只看收得稳帧解析出来后设备的操作分为三类对握手命令回复设备型号和当前固件版本对数据命令校验CRC成功写Flash缓存区并回复ACK失败回复NACK对结束命令做整包CRC复核然后执行App区刷新和跳转。上位机侧的核心逻辑是“发一包等ACK”。默认超时200ms超时未收到就重发当前包。如果设备收到的是重复包序号设备不需要重写Flash只需要再回复一次ACK让上位机能继续往前走。这个处理很微妙重复包来了就重写一次也没错但会浪费擦写时间和Flash寿命直接忽略又会让上位机一直重试。所以判断序号是否大于当前已写入序号大于才写小于等于就直接ACK。上位机发完所有数据包后必须发送结束帧。设备收到结束帧后才对下载缓存区的数据做整体CRC校验。这个整体CRC在升级开始帧里就已经告诉设备了等于双保险单帧CRC保证链路传输没有丢包总CRC保证整份固件没有完整性风险。4.4 波特率与升级耗时的工程测算115200波特率8N1格式有效数据速率约11520字节/秒。假设每帧数据区256字节帧总开销11字节单帧267字节那么每秒大约能发43帧传输1MB固件约91秒加上握手、写Flash、校验总时间约2分钟以内。这个速度对绝大多数OTA场景足够。如果把单帧数据区改成1024字节帧数变少重传粒度变大单帧出错重传的代价也更大。把单帧数据区改成32字节则帧数太多帧头开销占比高传输效率下降。我实测下来256字节是嵌入式串口IAP比较均衡的选择也方便和Flash的编程最小单位对齐。如果产品允许也可以把波特率提到460800甚至1M。但我在工控现场吃过线缆接触不良的亏传输速度越快波形质量要求越高。115200在双绞屏蔽线上可以做到很长的线缆和很强的抗干扰所以我的默认方案不追求极限速度追求稳定。5. Flash擦写与App跳转实现最关键代码的写法与边界5.1 Flash解锁、擦除、写入三个操作各有各的禁忌STM32的Flash有严格的保护机制操作前必须解锁操作完必须重新上锁。解锁序列、擦除单位、编程宽度因型号而异。F1系列的页大小通常1KB或2KB编程宽度是half wordF4系列则一个扇区可能64KB甚至128KB编程宽度是32位字。动手前一定要查对应型号的参考手册和数据手册这里最容易翻车。常规流程如下void Flash_ProgramBytes(uint32_t addr, uint8_t *buf, uint32_t len) { uint32_t i; uint16_t half; FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_BSY | FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); for (i 0; i len; i 2) { half buf[i] | ((uint16_t)buf[i 1] 8); if (FLASH_ProgramHalfWord(addr i, half) ! FLASH_COMPLETE) { break; } } FLASH_Lock(); }注意一个关键点Flash只要有“写1变0”的能力没有“写0变1”的能力。只有当Flash单元处于擦除后的0xFF状态才能写入期望的数值。所以在写之前目标扇区必须预先擦除。擦除和写入是两个独立操作不能指望一个Program函数自动完成擦除。擦除还有一个特性擦除是整个页或整个扇区一起做的不能只擦某几个字节。所以修改固件时只要App区内容有变化就需要整页擦除再重写。这也正是升级时必须把新固件先缓存到下载区的原因之一。5.2 用下载区缓存固件写App前先做完整性校验我的升级流程是这样编排的上位机握手设备回复当前版本。上位机发送升级开始帧设备记录目标长度和总CRC。上位机逐包发送固件数据设备逐包写入下载缓存区。上位机发送升级结束帧设备对下载缓存区做总CRC复核。CRC通过后擦除App区把下载缓存区数据复制到App区。复制完成后对App区做读回比对或者CRC校验。设置“App有效”标志跳转App。这套流程里App区永远是最后才动的。哪怕升级到第3000包突然断电下载缓存区里可能只有3000包的残数据但App区还是完好的旧版。设备重新上电后Boot发现升级没有完成可以等上位机重新连接后继续或者直接跳转到旧App让设备继续工作。如果贪图省流直接把上位机数据包写进App区中途断电就会出现“旧固件被擦了一半新固件还没写完”的恐怖状态。这也是很多设备升级变砖的根源。5.3 从Boot跳转到App栈顶校验与中断关断顺序跳转函数是Boot的最后一步代码如下#define APP_BASE_ADDR 0x08010000 typedef void (*AppFunc_t)(void); void Boot_JumpToApp(void) { uint32_t app_msp; uint32_t app_reset; __disable_irq(); /* App起始地址前4字节是初始栈指针偏移4字节是复位函数地址 */ app_msp *(volatile uint32_t *)APP_BASE_ADDR; app_reset *(volatile uint32_t *)(APP_BASE_ADDR 4); /* 简单边界校验栈指针应在SRAM区间复位地址应在Flash区间 */ if ((app_msp 0x2FF00000) ! 0x20000000) { return; } if ((app_reset 0x2FF00000) ! 0x08000000) { return; } /* 重定向中断向量表 */ SCB-VTOR APP_BASE_ADDR; /* 设置主栈指针然后跳转 */ __set_MSP(app_msp); ((AppFunc_t)app_reset)(); }跳转前关中断是必须的。如果在Boot阶段串口中断还在跑或者某个定时器中断已经pending一旦跳进AppApp里还没有完成外设初始化中断一来就按半初始化状态的寄存器执行很容易触发HardFault。所以我习惯在跳转前把所有外设中断都关闭等App初始化完毕后由App自己重新打开需要的中断。边界校验同样重要。栈指针前三位应该在0x20000000附近复位地址前三位应该在0x08000000附近。这个校验能挡住“App区全是0xFF”或“App区被误写入文件头”等低级错误。5.4 跳转前的最后检查清单我自己每次跳转前都会过一遍清单[ ] 下载缓存区总CRC已经通过App区数据完整。[ ] App区复制完成后已经读回比对没有字节错位。[ ] 全局中断已关闭PendSV、SysTick和所有外设中断都处于关闭状态。[ ] 串口DMA如果开了也要关掉并清理标志避免跳转后DMA还在向内存搬运数据。[ ] 片上外设的时钟状态已恢复到App可接受的范围。这个清单的本质是把Boot“收拾干净”别让上一个程序的影子影响下一个程序的运行。6. 异常恢复与实测经验把升级做成一个闭环6.1 看门狗与升级超时机制设备永远有退路IAP升级时最怕的不是数据发错而是整个流程卡死。上位机崩溃、串口断开、后台调度异常都可能让设备停在某个状态不动作。因此Boot阶段必须开启独立看门狗IWDG并且只在“完整处理完一帧并正常回复ACK”后才喂狗。如果超过预设时间没有收到任何合法帧看门狗就会复位设备Boot重新启动回到等待升级的初始状态。喂狗的时机非常讲究。不要在串口中断里喂狗因为如果主循环已经卡死但串口还在收数据中断喂狗会把设备伪装成活着的状态实际系统早就没有推进力了。一定要在主循环处理完一帧之后的末尾喂确保“协议处理进度”在真正推进。有了看门狗和超时重传整个升级流程就有了兜底上位机发不出数据设备自己复位重来上位机一直乱发设备状态机始终不匹配就不动用户手动断电设备回到Boot等下一次升级或者跑旧App。6.2 升级状态保存与变量区管理我习惯在参数区固定地址保存一组“升级状态”数据。包括魔数比如0xA5A5F00F用于判断参数是否有效。当前升级状态IDLE、RECEIVING、VERIFYING、READY_TO_JUMP。已接收包序号用于断点续传时上位机快速定位。App区有效标志上次App运行是否正常退出。App长度、总CRC用于校验和版本管理。设备每次上电Boot先读参数区。如果App有效标志正常就快速跳转App如果App有效标志异常说明之前App崩溃或升级失败Boot就等待上位机重新刷机不跳转。这个机制能把很多软故障变成现场可恢复的升级任务。参数区写入也有讲究。参数区一般很小写入次数受Flash寿命限制不能每个包都写。我的做法是在升级开始帧收到后才写一次“RECEIVING”结束帧CRC通过后再写一次“READY_TO_JUMP”。中间几万包数据不写参数区只在RAM里维护标志直到事务结束才落Flash。6.3 三个让我印象深刻的翻车现场和修法第一个情况是上位机发包太快设备环形队列溢出。当时我统计overflow_cnt发现每几千包就会丢一两次设备这边没有及时重发请求上位机还在傻乎乎往下发最后CRC不过。修法有两个层面协议层加ACK/NACK和重传机制应用层把每包之间的延时从5ms提到20ms。实测下来丢包率直接降到零。第二个情况是擦除App扇区时串口中断持续涌入数据。因为当时用的还是直接把App区作为写入目标的方案擦除期间主循环没法处理队列队列深度一度涨到接近容量上限。后来改成缓存区方案后这个问题从根上消失了——所有数据都在进入缓存区时收完了擦App区时已经不需要再接收新数据。第三个情况最隐蔽跳转后App跑几秒就HardFault。排查了很久才发现是中断向量表重定向的地址没有按0x200对齐SCB-VTOR写入了一个非法的对齐值导致中断向量表映射错乱。这个坑容易忽略一定要查参考手册里对VTOR位字段的说明并按向量表的对齐要求取值。最后说一个我的个人习惯不管IAP做得多么稳我始终保留SWD/JTAG调试接口。万一Boot区本身被刷坏或者整个Flash被锁死没有编程器谁都救不了。升级代码越稳越要保持这条后门。另外上位机和下位机最好共用同一份协议头文件帧头、命令字、CRC算法都做成宏两边各写各的校验算法是最容易出低级问题的我见过不止一次因为CRC初始值不同导致整包被拒。先把这些细节钉死剩下的就交给时间和现场了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
