1. 升级失败不是一个问题而是一串问题单片机 BootLoader 升级程序失败是嵌入式一线最难缠的一类故障之一。它难的地方不在于技术有多深而在于失败现象高度雷同串口那头告诉你传输完成设备重启之后还是老固件或者版本号变了设备却卡死在启动阶段连调试口都不响应。我做过好几个带现场升级能力的项目前后修过几十次这类问题最后的结论是BootLoader 升级失败几乎从来不是单一 bug而是一条链路上若干个小疏漏叠加出来的结果。这篇文章面向的读者很明确正在给 32 位 MCU 做 IAP 升级、已经被升级完不跑或者概率性失败磨过几轮的嵌入式工程师以及准备给产品加远程升级功能想提前避开坑的人。文中会覆盖分区规划、向量表偏移、跳转前的状态清理、Flash 擦写对齐、协议重传、校验与断电保护这几块尽量把每一步为什么这么做讲透代码和参数都能直接拿去改。先说一句可能不太中听的话大部分人第一次遇到升级失败第一反应是怀疑通信协议第二反应是怀疑 Flash 写坏了而实际统计下来真正死在跳转环节的最多。原因很简单——写数据这一步有返回值、有校验、有日志出错立刻能看见跳转这一步只是一句函数指针调用成功了没人夸失败了也不给你任何提示只能看到一个 HardFault 或者一片死寂。1.1 一次完整升级链路上的七个失败点把一次升级拆开看从上位机点开始到设备跑起新程序中间至少经过七个可能出问题的节点握手与进入升级模式设备没有正确识别升级指令或者在跑 APP 时无法跳回 BootLoader。擦除Flash 写保护没解除、擦除粒度算错、擦除超时被看门狗打断。数据接收分包丢失、缓冲区溢出、超时判定过严。写入地址越界、未按页对齐、跨页写入被硬件拒绝。校验CRC 算法两端不一致、长度字段算错、校验范围包含未写入区域。标志位与版本号写入写了但没同步或者写在了会被误判的位置。跳转与启动栈指针、向量表、中断状态、外设残留任何一项不对都会让新程序启动了但没完全启动。这七步里前六步出问题通常会有明确的返回码或者日志第七步出问题则完全静默。所以我在排查时有个固定顺序先证明数据真的写进去了再证明跳转逻辑是对的最后才去怀疑通信层。顺序反了你会在串口助手上耗掉一整天。提示不要一上来就抓包看波形。先做一次只写不跳的测试——把镜像完整写进去不跳转直接用调试器把 Flash 读回来和源文件逐字节比对。这一步能把大半问题直接排除掉。1.2 先分清楚写不进去和写进去跑不起来这两种现象的排查路径完全不同但表现经常被混为一谈。判断方法很朴素升级完成后用调试器连上去从 APP 起始地址读 64 个字节。如果读出来全是0xFF说明压根没写进去问题在擦除、写保护、地址计算或者通信。如果读出来是有效数据但前两个字栈顶值和复位入口明显不像代码比如0x00000000、0xFFFFFFFF、0x20000000之类的怪值说明写入偏了位置或者镜像本身不是给这个地址编译的。如果前两个字正常程序还是跑不起来问题在跳转或者 APP 自身的初始化。我遇到过最典型的一次客户反馈升级成功但设备没反应。读回比对发现 APP 起始地址的数据完全正确栈顶值也合理但跳过去就 HardFault。最后定位到 BootLoader 里有个定时器中断没关跳转后中断照常触发而中断向量表还指向 BootLoader 区域的函数地址那个函数里用到的静态变量在 APP 的链接视图里是另一个地址——一脚踩空。1.3 我的第一个教训别急着改代码先确认现象能被复现早期我吃过一个很亏的教训。某批次设备现场升级成功率大概七成剩下三成失败。我当时正在改协议的超时参数改了两版都没好转反而把自己绕进去了。后来老老实实做了一件事把失败的那批设备留在实验室连续升级 50 次记录每次失败发生在第几个包。结果很清晰——失败全部集中在擦除阶段之后的头两个包。原因最后查明擦除一页 Flash 需要几十毫秒这段时间内 CPU 从 Flash 取指会被硬件暂停串口接收中断响应被拉长上位机正好在这个窗口内连发了两包第二包溢出丢失而我的协议没有重传机制。擦除期间取指停顿这件事很多资料只是一笔带过但它是概率性升级失败的头部原因之一。所以第一条经验故障必须能稳定复现才有资格进入调试阶段。概率性问题先想办法提高复现率——比如缩短包间隔、降低波特率、加大镜像体积、反复循环升级把 30% 的失败率拉到 100%问题往往自己就浮出来了。2. 分区与跳转九成的升级成功但不运行出在这里如果只能保留一个章节我会保留这一章。BootLoader 升级的所有工程事故里跳转相关问题占比最高而它偏偏是最不容易通过日志发现的部分。这一章按地址规划、向量表、跳转清场、APP 侧配合四块来讲每块都给具体数字和代码。2.1 分区规划与链接脚本的硬对应先说地址。假设手上是一颗 256KB Flash、20KB RAM 的 32 位 MCUFlash 起始0x08000000SRAM 起始0x20000000。我习惯这样切区域起始地址大小说明BootLoader0x0800000032KB含向量表、升级协议、Flash 驱动升级标志区0x080078002KB独立一页存版本号与升级请求标志APP0x08008000224KB用户程序向量表偏移0x8000参数备份区0x0803F0004KB断电续传记录、CRC 结果、旧版本号几个关键点必须讲清楚。第一BootLoader 的结束地址要和 APP 起始地址严格对齐到一个擦除页的边界。上面 32KB 正好是 16 个 2KB 页干净。如果算出来是 30KBAPP 从0x08007800起步那标志区就没地方放了硬塞进去就会和 BootLoader 的代码段打架。规划时宁可给 BootLoader 多留 2KB 余量也别让它贴着边界。第二APP 的大小必须小于分配空间而且要留出安全余量。我一般要求编译产物不超过分配大小的 85%剩余空间给后续加功能。超出的话链接器会直接报错比运行到一半写飞掉好得多。第三链接脚本必须改不改就是白干。以常见的 GCC 链接脚本为例FLASH 的 ORIGIN 要从0x08000000改成0x08008000LENGTH 改成224K。同时把向量表段放到最前面MEMORY { FLASH (rx) : ORIGIN 0x08008000, LENGTH 224K RAM (rwx) : ORIGIN 0x20000000, LENGTH 20K }商用 IDE 里对应的是 IROM1 的起始地址和大小的修改本质一样。这里有个容易被忽略的细节改完链接脚本要全量重新编译不能只增量编译。我就见过因为增量编译导致部分目标文件还是按旧地址链接最后烧进去的程序前半段是对的一调用某个库函数就跳到 BootLoader 的地址空间去。第四分区表要写成宏且 BootLoader 和 APP 共用一份头文件。地址这种东西散落在两个工程里早晚会不一致。#define APP_BASE_ADDR (0x08008000UL) #define APP_MAX_SIZE (224UL * 1024UL) #define FLAG_PAGE_ADDR (0x08007800UL) #define PARAM_PAGE_ADDR (0x0803F000UL)2.2 向量表偏移与栈指针跳转前必须核对的两个字APP 镜像的前两个字是有强约定的第一个是初始栈顶值MSP 初值第二个是复位入口地址。跳转的本质就是把这两个值分别塞进栈指针寄存器和程序计数器。所以在跳之前必须先做合法性检查。这一步我见过太多人省略结果就是镜像损坏或者写偏位置时程序直接飞进随机地址调试器一挂上去看到的是unknown address什么都查不出来。typedef void (*app_entry_t)(void); static int app_image_check(uint32_t base) { uint32_t sp *(volatile uint32_t *)(base); uint32_t pc *(volatile uint32_t *)(base 4); /* 栈顶必须落在 SRAM 范围内且 4 字节对齐 */ if (sp RAM_BASE || sp (RAM_BASE RAM_SIZE)) { return -1; } if (sp 0x3U) { return -2; } /* 复位入口必须落在 APP 区域内且最低位为 1Thumb */ if (pc APP_BASE_ADDR || pc (APP_BASE_ADDR APP_MAX_SIZE)) { return -3; } if ((pc 0x1U) 0U) { return -4; } return 0; }这段代码的价值在于把跳过去跑飞转化成跳之前就返回错误码。当app_image_check返回 -1你就知道是镜像没写进去返回 -3说明写入地址偏了或者镜像不是给这个基址编译的。比跳过去之后抓 HardFault 高效太多。然后是向量表偏移。Cortex-M 内核的向量表默认从0x00000000映射具体实现上通常会把 Flash 起始重新映射到 0 地址。APP 不在起始地址所以它的向量表必须重定位。内核提供一个向量表偏移寄存器写进去的是相对于 0 地址的偏移量#define SCB_VTOR (*(volatile uint32_t *)0xE000ED08UL) SCB_VTOR APP_BASE_ADDR; /* 因为 0 地址映射到 Flash 起始偏移即基址 */这一句通常放在 APP 的SystemInit或者main的最前面。注意是 APP 侧要写不是 BootLoader 侧写。很多人搞反了在 BootLoader 里写 VTOR然后跳转APP 一进SystemInit又给改回去了或者干脆没改中断全跑到 BootLoader 的向量表里去。我在 BootLoader 跳转前也会写一次算是双保险但真正起作用的必须是 APP 自己那一句。2.3 跳转前的清场清单中断、外设、看门狗、时钟这是我最想强调的一节。跳转不是简单的函数调用它是把 CPU 的控制权整个交出去而 BootLoader 留下的遗产会跟着进 APP。必须关的东西按重要性排全局中断跳转前__disable_irq()等 APP 初始化完自己开。别在 BootLoader 里开完再跳。SysTick计数器、重装载值、使能位全部清零。SysTick 是内核级外设不随外设复位残留的中断标志会在 APP 里立刻触发。NVIC 使能与挂起位把所有中断的使能位和挂起位清掉防止历史挂起位在 APP 开中断的瞬间集体响应。外设本身串口、定时器、DMA、ADC该复位的复位该关时钟的关时钟。残留的串口接收中断一旦在 APP 里没注册处理函数就会跳到默认处理函数里死循环。看门狗这个是隐形杀手下一小节单独说。static void jump_cleanup(void) { __disable_irq(); /* 清 SysTick */ *(volatile uint32_t *)0xE000E010UL 0; /* CTRL */ *(volatile uint32_t *)0xE000E014UL 0; /* LOAD */ *(volatile uint32_t *)0xE000E018UL 0; /* VAL */ /* 清所有 NVIC 使能位与挂起位 */ for (uint32_t i 0; i 8; i) { *(volatile uint32_t *)(0xE000E180UL i * 4) 0xFFFFFFFFUL; /* ICER */ *(volatile uint32_t *)(0xE000E280UL i * 4) 0xFFFFFFFFUL; /* ICPR */ } /* 外设复位调用芯片库里的 DeInit 或直接操作复位寄存器 */ /* 不同厂商实现不同目标是把 BootLoader 用到的外设回到上电状态 */ }看门狗这一块要单独说。很多芯片的看门狗一旦由软件启动就只能靠复位关掉软件写保护位是无效的。这意味着如果 BootLoader 开了狗跳进 APP 之后狗还在跑APP 的初始化如果超过狗的超时时间比如要读外部存储、要等传感器就绪设备就会周期性复位。表现是设备一直在启动但永远启动不完。反过来如果 BootLoader 不开狗、APP 开狗那在 BootLoader 阶段尤其是擦除 Flash 这种耗时操作就没有保护一旦卡死设备就变砖。我的做法是BootLoader 开狗且超时时间设成擦除一页 Flash 最大耗时的 3 倍以上APP 的main里第一件事就是重新配置狗的周期并开始喂狗。两边都必须知道狗的存在这条约定写进文档。注意擦除整片或者擦除大块区域时要按页擦、每页之间喂一次狗别一口气擦完再喂。整片擦除 256KB 在某些芯片上要 1 到 2 秒狗超时设 500ms 的话必挂。2.4 APP 侧也要配合改很多人只改了一半BootLoader 写好了、地址算对了、跳转代码也干净APP 侧如果没配合照样起不来。APP 侧要改的地方有三处缺一不可。第一处是链接脚本或 IDE 的 IROM 起始地址前面说过了。第二处是向量表偏移寄存器也说过。第三处是启动文件里的向量表定义位置这个最隐蔽。有些启动文件里向量表段的放置是绝对定位的比如__attribute__((section(.isr_vector))) const void *vector_table[] { ... };.isr_vector段在链接脚本里如果被放在 FLASH 的起始处那它会自动跟着 ORIGIN 走没问题。但如果有的工程用了绝对地址定位那改了 ORIGIN 它也不动向量表还在0x08000000APP 运行时中断全乱。改完地址之后务必 dump 一下生成的 bin 文件确认前 8 个字节符合预期。另外还有两个小点APP 编译产物的格式。升级传输的必须是纯二进制 bin不是带地址信息的 hex 或者 elf。如果误传了 hex 文件Flash 里会写进去一堆 ASCII 字符读回来前两个字根本不是合法栈顶值app_image_check会直接返回 -1。APP 里的中断处理函数一定要和启动文件里的向量表数量对应。用了多少中断向量表就得铺多少项中间不能有缺项否则某个中断触发时会跳到 0 地址。3. Flash 写入与协议实现稳定性藏在这些细节里数据能收、能写、能校验是升级成功的前半程。这一块的问题特点是偶发而且经常跟硬件状态相关所以细节格外重要。3.1 擦除与写入的粒度对齐Flash 有三个物理特性必须尊重违反了就是数据损坏一是擦除的最小单位是页不是字节。大多数 32 位 MCU 的页大小在 1KB 到 4KB 之间具体查手册。写数据之前目标区域必须处于已擦除状态全0xFF不能直接覆盖写。有些人为了省时间跳过擦除直接写写进去的数据按位与的结果是旧数据和新数据的交集读回来一半是错的而 CRC 校验如果只校验最后一个包还发现不了。二是写入通常要求按字或按半字对齐。比如某些芯片支持 32 位编程那写入地址必须是 4 的倍数写入长度也必须是 4 的倍数。镜像长度如果不是 4 的整数倍最后几个字节要补齐到0xFF。这个补齐操作必须在上位机算 CRC 之前做否则两端 CRC 永远对不上。三是写入不能跨页。从这个页的末尾写到下一个页的开头很多控制器会直接拒绝或者报错。所以写函数里必须做边界判断static int flash_write(uint32_t addr, const uint8_t *buf, uint32_t len) { uint32_t page_end (addr ~(PAGE_SIZE - 1U)) PAGE_SIZE; while (len 0U) { uint32_t chunk page_end - addr; if (chunk len) { chunk len; } if (flash_program(addr, buf, chunk) ! 0) { return -1; } addr chunk; buf chunk; len - chunk; page_end PAGE_SIZE; } return 0; }另外写之前要检查目标页是否已经擦过。如果同一页重复擦写寿命消耗得很快。我一般在上位机侧就做好分包对齐让每个包都落在同一页内BootLoader 侧再做一层保护。提示如果芯片有数据 Flash 或 EEPROM 模拟区把升级标志、版本号、断点记录放那里别和代码区抢同一块空间。这些数据写得频繁混在代码区里一旦误擦就是灾难。3.2 分包、应答与超时重传协议层最常见的问题是只管发、不管收。上位机按照固定节奏往下灌数据BootLoader 收多少算多少中间丢一包就全盘皆输。一个够用的升级协议至少要有这几个字段字段长度说明帧头2B固定同步字防止错位序号2B从 0 递增用于检测丢包和重复包地址4B目标写入地址避免依赖隐式偏移长度2B本帧有效数据长度数据N B建议 512 到 1024 字节校验2B本帧 CRC16判断本帧是否完整帧尾1B固定结束符设备端收到一帧后先校验帧校验再看序号。序号等于期望值就处理处理成功后回 ACK序号小于期望值说明是重传直接回 ACK 但不重复写序号大于期望值说明中间丢了回 NAK 要求重发。switch (frame.seq - ctx-expect_seq) { case 0: /* 正常 */ ret handle_data(frame); ctx-expect_seq; send_ack(frame.seq); break; case (uint16_t)-1: /* 重复帧幂等处理 */ send_ack(frame.seq); break; default: /* 序号跳跃请求重传 */ send_nak(ctx-expect_seq); break; }重传次数我一般设 5 次超过就整个升级失败从头开始。别设太大现场环境差的时候无限重传只会让升级过程看起来一直在跑但其实永远完不成。超时时间怎么定有个简单的算法单帧数据量除以有效波特率得到理论传输时间再乘以 3 到 5 倍作为超时阈值。比如 1024 字节数据115200 波特率下 8N1 每字节约 86.8 微秒理论 89 毫秒超时设 400 毫秒比较稳妥。但要注意如果这段时间里设备正在擦 Flash响应会明显变慢所以擦除操作要么放到单独的控制帧里同步完成要么把超时放宽到 1 秒。3.3 校验与升级标志的写入顺序校验这件事我见过两种典型错误。第一种是两端算法不一致。上位机用标准 CRC32 多项式0x04C11DB7设备端用了0xEDB88320的反射版本但初始值和结果异或没对齐。最后算出来的值永远差一个固定偏移看着像差不多的样子实际全错。解决办法很简单在 PC 端和 MCU 端各写一个测试用例输入同样的 16 个字节输出必须完全相等。这一步花五分钟能省两天。标准 CRC32 的查表版本或者位运算版本都可以位运算版本代码短static uint32_t crc32_calc(const uint8_t *p, uint32_t len) { uint32_t crc 0xFFFFFFFFUL; while (len--) { crc ^ *p; for (uint8_t i 0; i 8U; i) { uint32_t mask (uint32_t)(-(int32_t)(crc 1U)); crc (crc 1) ^ (0xEDB88320UL mask); } } return ~crc; }第二种是校验范围不对。有些实现只校验最后一个包或者校验时把没写入的区域还是0xFF也包含进去了导致同样的镜像每次算出来都不一样。正确做法是按镜像的实际长度算 CRC长度字段由上一位机在升级开始时一次性下发并锁定。然后是最关键的一步标志位的写入顺序。正确的顺序是镜像全部写完 → 读回比对或整包 CRC 校验 → 全部通过 → 最后写升级成功标志含版本号、镜像长度、CRC 值→ 复位。绝对不要先写标志再写数据。如果中途掉电标志已经写了BootLoader 一看标志有效就去跳转跳进去是半截空程序连恢复的机会都没有。反过来先写数据后写标志中途掉电时标志无效BootLoader 继续停在升级模式或者跑旧程序设备至少是活的。标志本身也要做保护存两份一份存原值一份存反码读的时候两份比对只有互为反码才认为有效。这样能挡住写一半的情况。typedef struct { uint32_t magic; /* 固定值如 0x5A5AA5A5 */ uint32_t version; uint32_t image_len; uint32_t image_crc; } upgrade_flag_t; /* 写入时先写 A再写 BB 存魔数的反码 */3.4 掉电与断点续传现场升级最怕的就是中途断电。设备在客户手里电源拔掉、电池耗尽、开关误碰都可能发生。要解决这个问题靠的不是祈祷不要掉电而是设计上的冗余。思路一A/B 双区。把 APP 空间一分为二正常运行 A 区升级时往 B 区写写完校验通过后改标志指向 B 区。这样无论在哪一步掉电至少有一个完整的镜像可用。代价是可用空间减半224KB 的 APP 区变成两个 112KB功能多的产品可能不够用。思路二单区加回滚。只有一个 APP 区时无法避免擦除后断电这个窗口。但可以缩小窗口擦除前保留下旧镜像的 CRC 和一个升级中标记如果上电后发现标记是升级中而镜像 CRC 不对就进入升级模式等上位机重连绝不去跳转。这个方案救不回旧程序但能保证设备不变成完全无响应的砖头。思路三断点续传。每写完 N 页比如 8 页就把当前偏移和已写区域的 CRC 记到参数区。重新连接时上位机先读这个记录从断点继续传。这套机制实现成本不低但对那些通信链路很差、升级动辄十几分钟的场景很有价值。我做过的一个项目现场设备在地下室无线信号很弱传输 128KB 平均要断 3 次。加了断点续传之后升级成功率从六成提到九成八。代价是参数区每次擦写都要做磨损均衡代码量增加了大概两百行。4. 六类高频故障现场复盘前面讲的是应然这一节讲实然。以下六个故障我都真实遇到过现象和原因各不相同但排查思路可以互相借鉴。4.1 跳转瞬间 HardFault现象BootLoader 打印开始跳转随后设备死掉调试器连上去 PC 值指向0xFFFFFFFE或者某个莫名其妙的函数。这类问题九成出在两点栈指针非法或者栈指针合法但太小。前者用app_image_check能挡掉。后者更隐蔽——镜像本身是好的但它编译时假设的 RAM 布局和 BootLoader 用掉的 RAM 重叠了。比如 BootLoader 用了 RAM 的后 4KB 做接收缓冲APP 的链接脚本里 RAM 是完整的 20KBAPP 一启动就把栈放到了那块缓冲区的正中间BootLoader 还没来得及释放数据互相覆盖。解法很直接在链接脚本里为 BootLoader 保留的 RAM 做显式扣减或者在 BootLoader 跳转前把自己用的大缓冲区清空、栈回退到最顶端。我倾向于前者因为后者依赖运行时状态容易忘。4.2 首次运行正常、复位后死机这个现象特别能忽悠人。升级完成、跳转、程序跑起来了、功能全对你以为成功了。然后手动复位设备不启动了。原因通常是向量表偏移那一句写在main函数里而不是写在启动阶段。第一次跳转时 BootLoader 已经把向量表偏移寄存器设好了APP 里的那句写不写都无所谓。但复位之后芯片从 Flash 起始的 BootLoader 重新启动BootLoader 又跳转这次如果 BootLoader 没重设偏移有些实现是在初始化里设一次就完事跳转前不重设APP 的向量表位置就是错的。所以那条规矩要重复一遍向量表偏移要在 APP 的最早期设置且 BootLoader 在每次跳转前都要重设一次。两边都设宁可冗余。4.3 升级到一半断电变砖前面讲过设计层面的解法这里说排查层面。设备变砖之后第一件事是确认它到底能不能进升级模式。很多 BootLoader 的进入条件是上电后 500ms 内收到特定指令这个窗口太窄现场根本来不及。我的做法是只要检测到升级中标记存在且镜像校验不通过就无条件停在升级模式等 60 秒期间不断发送心跳。这样即使上位机断开了重新连上也能接上。60 秒之后如果还没人理再尝试跳转一次多半会失败然后死循环等狗复位至少不是彻底黑屏。4.4 校验通过但功能异常这个最迷惑人。CRC 对得上镜像完整程序也能跑但某个功能就是不对比如读出来的传感器数据全是零或者通信接口不响应。排查下来通常是升级没有真正覆盖旧数据。比如新镜像只有 100KB旧镜像有 150KB擦除时只擦了 100KB 对应的页后面 50KB 的旧代码还在。如果新镜像的某个数据段恰好落在后面那部分区域程序读到的就是旧数据。表现就是某些配置项还是老值。解法擦除范围必须按新镜像长度向上取整到页来算如果新镜像比旧镜像短还要额外擦掉尾部。更稳妥的做法是每次升级前把整个 APP 区全擦一遍代价是时间长一点但能杜绝所有残留。4.5 概率性升级失败现象是十次里成功七八次失败的那几次现象还不完全一样。这类问题一定要先做数据统计记录每次失败的包序号、失败时的电压、失败前的操作。我做的一次统计结果是失败全部发生在设备电池电压低于 3.3V 时。原因Flash 擦写对供电电压有硬性要求手册上写的最低编程电压是 2.7V但那是理想条件。实际在 2.7V 附近擦写失败率明显上升。加上擦除瞬间电流突增电池内阻大的时候电压会瞬间跌下去。解法是三条一起上升级前检查电压低于阈值直接拒绝升级并提示擦写期间关闭大电流外设屏幕背光、无线发射每次擦写后读回校验失败就重试重试三次仍失败则整体失败。4.6 带着调试器能跑断开就跑不了调试器连着的时候一切正常拔掉之后设备就卡住。这类问题的根因基本都在调试器掩盖了某些时序或者状态。我遇到的两个具体例子一个是 BootLoader 里用了printf重定向到串口而串口在跳转前没关APP 里也没初始化串口结果 APP 第一次调用打印就卡在等待发送完成标志上。调试器连着的时候因为断点停在那里反而没走到那一步。另一个是低功耗相关的调机器连着的时候芯片不会进入深度睡眠调试模式下睡眠被禁止断开之后进入睡眠唤醒源没配置对一睡不醒。这类问题没有通用解法只能靠逐步注释法定位。通用原则是调试器只是一个观察者它不应该改变程序的执行路径。如果改变了说明代码里存在依赖调试状态的逻辑比如未初始化变量、未关闭的外设、未配置的时钟。5. 分层排查法与速查表前面讲了太多具体案例容易让人记住细节忘了方法。这一节把排查流程整理成可执行的东西遇到新问题直接照着走。5.1 四层定位法我把升级问题分成四层从下往上查每层的验证手段不同层级关注点验证手段典型现象硬件层供电、复位、引脚示波器看电压、看复位波形随机失败、失败率与电压相关通信层波特率、丢包、超时抓包、统计重传次数特定包号失败、偶发超时存储层擦除、写入、校验读回逐字节比对数据错、部分区域是0xFF执行层向量表、栈指针、中断单步调试、断点跳转后跑飞、复位后死机排查顺序建议自上而下地排除而不是自下而上地猜测。先确认硬件没问题换一块板子、换一个电源再确认通信层数据完整打印每一包的序号和 CRC再看存储层读回比对最后才动执行层。顺序反了容易在低层问题上打转。5.2 最小验证读回比对与打点法有两个手段我认为是必须掌握的基本功。读回比对升级完成后不跳转用调试器或者 BootLoader 自带的功能把 APP 区域的内容整体读出来和源 bin 文件做二进制比对。Windows 下用fc /bLinux 下用cmp -l或者写个小脚本几行代码搞定。只要有一个字节不同就说明写入有问题执行层根本不用看了。打点法在 BootLoader 的每个关键节点进入升级模式、擦除完成、收完第一包、收到最后一包、校验通过、准备跳转、跳转前一刻通过串口或者一个空闲 IO 打一个标记。跳转失败的时候看最后一个标记停在哪儿就知道死在哪一步。用 IO 翻转配合示波器比串口打印更可靠因为串口本身也可能出问题。#define MARK(n) do { \ GPIOA-ODR (GPIOA-ODR ~(0xFUL 4)) | (((n) 0xFUL) 4); \ } while (0) MARK(1); /* 进入升级模式 */ erase_app_area(); MARK(2); /* 擦除完成 */ ... MARK(9); /* 即将跳转 */ jump_to_app(APP_BASE_ADDR);四个 IO 口能打出 16 个状态配合逻辑分析仪一次升级的时间轴清清楚楚。这招我在没有任何日志输出的裸机环境里用得最多。5.3 常见问题速查表把前面散落的结论集中一下方便直接对号入座。现象最可能原因优先检查项跳转后立刻 HardFault栈顶值非法读 APP 起始 8 字节检查是否在 RAM 范围内跳转后无响应无 HardFault全局中断未开或时钟未配APP 的SystemInit是否执行复位后死机首次正常向量表偏移未重设BootLoader 跳转前是否写 VTOR中断全乱、进错函数向量表位置错误启动文件里的向量表段位置读回数据部分为0xFF擦除范围不足或写入越界擦除长度是否按新镜像长度计算前 4 字节正确后续错乱传输协议丢包未重传加大超时开启重传校验值总是差一点CRC 参数不一致两端跑同一组测试向量升级中随机失败擦除期间丢包或电压不足擦除时暂停发送检查供电升级完第一次能跑断电再上电变砖升级标志写入顺序错误是否先写数据后写标志整片擦除时间超预期未按页擦、未喂狗分页擦除并在页间喂狗6. 把升级做成一件长期可靠的事代码跑通只是起点。真正难的是让这套机制在几百台、几千台设备上稳定运行两三年不 reunion 出问题。这一节讲的是工程化层面的东西。6.1 版本、回滚与双区版本号必须写进镜像里而且要有两个镜像自己的版本号编译时写死和升级成功后记录在标志区的版本号。上电时比对两者如果不一致说明升级过程没走完应该拒绝跳转。回滚能力取决于分区方案。空间够就上 A/B 双区切换标志指向哪个区就跑哪个区新版本启动后跑一段时间比如连续运行 10 分钟、或者完成一次自检再确认确认失败就切回旧区。这套逻辑在服务端设备上用得很普遍单片机上也完全做得到只是要占用一倍空间。空间不够就用最小回滚保留旧镜像的 CRC 和长度新镜像启动失败时比如连续三次看门狗复位把标志改回旧版本。但如果旧镜像已经被擦掉了这条路也走不通。所以擦除旧镜像之前一定要先确认新镜像完整写入并校验通过这个顺序不能错。6.2 量产与现场升级的防呆设计量产阶段最容易出的问题是烧错版本。同一块板子可能有多个型号、多个客户定制版固件不通用。我在 BootLoader 里加了一道校验镜像头里带一个产品型号字段和硬件版本范围不匹配直接拒绝升级并返回明确错误。现场升级的防呆则更偏流程层面升级前检查设备状态电量、温度、是否处于工作状态不满足就直接拒绝。升级过程中设备上要有明确的指示LED 闪烁、屏幕提示让人知道正在升级别断电。升级失败要有可读的错误码不能只显示升级失败得让现场人员能拍照发回来定位。提供一个强制进入升级模式的物理手段比如上电时按住某个按键。这是最后一道保险。我给错误码编过一套规则高 4 位表示阶段1 握手、2 擦除、3 传输、4 写入、5 校验、6 跳转低 4 位表示具体原因。这样现场报一个0x52我就知道是校验阶段的具体某类失败不用反复问。6.3 我踩坑后定下的几条硬规矩写到最后分享几条我这些年形成的、不那么标准但极其管用的个人规矩。它们不一定写在任何文档里但每一条都是踩坑换来的。第一条BootLoader 的代码量控制在 16KB 以内并且永远不做业务逻辑。它只干四件事判断跳不跳、擦写 Flash、跑升级协议、跳转。功能越多出问题的面越大而且它一旦坏了设备连修复的机会都没有。第二条跳转前一定打一个 IO 标记永远保留。这个标记在生产固件里也不删因为它只占一个引脚成本可以忽略但排查问题时价值巨大。第三条任何一次 Flash 写入之后都要读回校验哪怕是单字节。写函数返回成功不代表真的写进去了。读回校验的开销是写入的三分之一左右换来的是确定性。第四条升级标志区永远不放在代码区的最后一页。很多芯片的最后一页有特殊用途或者被某些工具默认擦除。放在中间、独立、且两边都不用的位置最安全。第五条先用最小镜像验证链路再上真实固件。我习惯做一个 4KB 的最小可运行程序只做一件事点亮一个 LED 并不断翻转。链路调通之后再换真实固件。这样能把链路问题和应用问题彻底分开。最后补一个实操中的小技巧如果手头的板子没有预留调试口也没有串口只有一个 LED那就在 BootLoader 里用 LED 的闪烁次数表示状态码。闪 1 次表示进入升级模式闪 2 次表示擦除完成闪 3 次表示校验通过闪 5 次表示跳转失败。现场人员数一下闪光次数报给你就能大致定位问题。这个土办法我在三个项目里用过每次都救了急。
