简介面向STM32F103系列的CAN bootloader源码包专为需要远程或在线升级固件的嵌入式开发者准备尤其适用于汽车电子、工业控制等依赖CAN总线通信的现场维护场景。压缩包共359个文件以c与h源码文件为主体辅以s汇编启动文件、uvprojx/uvoptx工程文件及配置文档整体体积仅1.27MB工程结构紧凑便于直接导入Keil或STM32CubeIDE分析。目前已有427人学习下载。核心实现覆盖Bootloader完整流程包括CAN报文收发、固件完整性校验、Flash擦写与程序跳转并对传输数据加密有所处理。同时s文件展示了芯片启动流程c/h文件则是协议栈与驱动实现结合工程文件可快速构建与烧录验证。开发者可从中理解CAN协议栈与STM32 HAL/LL库的实际用法参考其错误处理与多设备同步更新思路对搭建安全的远程固件更新方案很有帮助。1. 拿到这个压缩包你要解决的是「拆机刷固件」的痛点如果你的产品已经装进外壳、拧上螺丝还在靠 SWD 排线刷固件你一定遇到过这种场景产线追着要升级、售后抱着旧版本机子等回炉、同事拆了半小时壳还没碰到调试口。CANbootloader_stm32f103_HD这个压缩包的标题翻译过来就是基于 CAN 总线的 STM32F103 引导加载程序且针对 HD 高密度型号。它解决的是让设备不拆机、不开盖、通过一条 CAN 总线把新固件灌进芯片的问题。这类程序在车载、工控、储能设备里几乎是标配因为 CAN 总线在这类产品里本来就在跑通信顺手复用做升级通道能省掉一路串口、一个调试孔位产线也只需要一根 CAN 线怼上去就能刷。本文会把这套方案的原理、协议设计、最小可复现代码、常见翻车点一次讲透适合正在做 IAP 功能或者被产线升级逼疯的嵌入式开发者也适合想评估「CAN 升级到底值不值得做」的选型工程师。压缩包里大概率是标准库工程、MDK 项目和应用层说明但光看工程不够你得理解这套东西为什么这么分、跳转时哪里会炸、HD 型号和普通 F103 的 flash 操作差在哪里这些才是真正值钱的信息。2. 先定 Flash 分区HD 芯片的扇区结构决定 bootloader 能放多大2.1 F103 HD 的 Flash 扇区为什么和中容量的 MD 完全不同网上随便搜「STM32F103 bootloader」你会看到大量基于 64KB、128KB 中容量芯片的教程它们的扇区是 4 个 16KB 起步总共没几页。但标题里的HDHigh Density指的是 256KB 到 512KB Flash 的大容量型号比如 F103ZET6、F103RCT6 这类。它们的扇区布局是前 4 个扇区每块 16KB从第 4 块开始每块 64KB。512KB 的完整布局就是 4×16KB 7×64KB。这个差异直接影响 bootloader 和 App 的分区边界。如果你按中容量芯片的习惯把 App 起始地址放在0x08004000256KB 处会以为是扇区边界在 HD 芯片上擦除0x08004000开始的扇区时由于它是 64KB 扇区的起始擦除动作会覆盖0x08004000 ~ 0x08014000整整 64KB连同你可能放在0x08004000之前的 bootloader 尾巴一起擦掉。我见过不止一个人在这里翻车App 能烧进去但 bootloader 没了重新上电直接进不了升级模式。还有一种更隐蔽的情况你在 bootloader 里调用了全片擦除函数或者把擦除地址算错了页号结果把 option byte 也改了。HD 芯片的 option byte 区有自己的地址空间操作时要走FLASH_OB_Unlock流程普通擦写碰不到它但全片擦除在某些库函数里行为会不一样。所以第一课很简单先查你用的具体型号的 flash 编程手册把扇区表打出来贴在屏幕边上再动分区。2.2 两套可用的分区方案以及 App 链接脚本里要改的三个数我一般建议给 bootloader 留 32KB也就是占用前两个 16KB 扇区0x08000000 ~ 0x08008000App 从0x08008000开始。好处是 32KB 对 bootloader 来说很宽裕协议栈、CAN 驱动、flash 驱动、CRC 校验全放进去还能留日志缓冲坏处是 512KB 容量里 App 可用区域少了 32KB但对绝大多数固件来说无感。如果你的 bootloader 想压到 16KB只占扇区 00x08000000 ~ 0x08004000App 从0x08004000开始那就要要求 bootloader 代码精简到极致CAN 接收、命令解析、flash 擦写全部裸写不挂 RTOS不开 printf。16KB 不是不可能但每次加功能都要小心尺寸。产线要加个「固件版本查询」功能可能就超了。所以我个人建议除非你的 App 极大且 bootloader 有硬性容量限制否则用 32KB 方案省心。链接脚本里要改的地方是三个数这个不管你是用 MDK 的.sct文件还是 GCC 的.ld文件# App 的链接脚本以 GCC ld 为例 FLASH_START 0x08008000; # 第一个数Flash 起始地址 FLASH_SIZE 480K; # 第二个数可用容量512K - 32K # 第三个数藏在启动汇编里中断向量表偏移 # 在 system_stm32f1xx.c 或启动文件的 SystemInit 里 VECT_TAB_OFFSET 0x8000; # 0x08008000 相对 0x08000000 的偏移前两个数决定 App 能链接到哪、能占多大第三个数决定 App 的中断向量表指向哪。如果你用的是标准外设库的老工程启动文件里通常会有一段VECT_TAB_OFFSET的宏定义要确保它是0x8000否则 App 一进中断就去0x08000000查向量表找到的是 bootloader 的向量轻则中断无效重则 HardFault。2.3 跳转到 App 前必须处理的向量表与中断清理F103 用的是 Cortex-M3 老内核它没有 F4/F7 上那个好用的VTOR重定位寄存器。这直接导致一个经典坑你以为 App 编译时地址改到0x08008000中断向量就自动跑到那里了实际上它没有。常见的可靠做法有两种。第一种是跳转前把 App 的向量表从0x08008000拷贝到 SRAM 起始处然后把SYSCFG-CFGR1的MEM_MODE位设成 SRAM 映射让内核从 SRAM 里取向量。第二种是 App 在启动早期、任何外设中断打开之前自己完成上面的拷贝和重映射bootloader 只管把 PC 指过去。我建议第二种把向量表的事交给 App 自己处理bootloader 端不碰职责更干净。跳转函数本身很简单但有几个被低估的细节。跳转前要把SysTick停掉、把控制器里所有已使能的外设时钟和中断关掉否则 App 初始化到一半定时器中断触发PC 还在 bootloader 的栈上直接跑飞。我见过一个案例现象是 App 启动后 1 秒内必死查了半天才发现是 bootloader 里没关 CAN 外设CAN 接收中断在跳转后继续触发进了 App 的中断处理函数而那个地址上还是 bootloader 的静态变量。3. 通信协议设计一帧 8 字节怎么装下命令、地址、数据和校验3.1 选标准帧还是扩展帧CAN ID 如何分配CAN 标准帧最多 8 字节数据扩展帧也是 8 字节数据差别只在 ID 长度和仲裁逻辑上。对 bootloader 来说标准框架那么简单就用标准帧你的设备总线负载率高、线上已经有大量报文建议用扩展帧把 bootloader 的帧 ID 规划在不容易和业务报文冲突的区间。ID 分配上要留出控制通道和数据通道的区分。我习惯用两个固定 ID控制命令走0x501数据块走0x502全部用标准帧。控制命令含义清晰数据帧专门搬数据不容易混淆。如果产品后续有多机升级需求可以用 ID 高字节区分节点号比如0x501 | (node_id 8)但这要求 bootloader 在出厂时就知道自己的节点号通常从拨码开关或备份寄存器里读。选择 ID 时还要避坑不要在 bootloader 里用过滤器把所有报文都放进来然后靠软件过滤。CAN 控制器硬件过滤器能帮你省掉大量软件判断在 F103 的 bxCAN 上我一般把0x501和0x502配置成只接收这两个 ID其余全部丢弃。这么做的好处是即使线上有别的业务报文疯狂刷bootloader 的接收中断和主循环也不会被打扰。3.2 命令帧与数据帧的载荷布局seq、flag、CRC 的取舍CAN 一帧最多 8 字节所以载荷布局必须精打细算。我沿用了很长一段时间的布局是这样命令帧0x5018 字节 Byte 0: 0xA5 同步头 Byte 1: 命令码0x01 握手 / 0x02 擦除 / 0x03 编程 / 0x04 校验 / 0x05 跳转 Byte 2: 帧序号 seq用于重传识别 Byte 3: 保留 Byte 4~7: 命令参数擦除时放起始地址高 24 位 长度数据帧0x5028 字节 Byte 0: seq4 bit 序号 4 bit 保留 Byte 1: flagbit0 最后一帧标志 Byte 2~5: 4 字节固件数据 Byte 6~7: 4 字节数据的 CRC16每帧只带 4 字节固件数据看起来效率不高但换来的是帧格式简单、硬件 CRC 不用也可纯软算、出错定位容易。你要真想提高吞吐可以把 8 字节全塞数据CRC 放到单独的结束帧里校验整个文件但这会引入「数据全收了最后校验失败要整包重传」的局面产线上一包几百 KB 重传一次很痛苦。分帧带 CRC哪帧坏了补哪帧重传成本低一个数量级。3.3 可靠传输策略逐帧 ACK 还是流水线各自代价逐帧 ACK 是最稳的方案设备每收到一帧校验 CRC 通过后回一个 ACK 帧上位机收到 ACK 才发下一帧。这个方案的缺点肉眼可见——慢。CAN 500Kbps 下一帧标准帧在总线上的时间大约 0.2~0.3ms但加上上位机等待 ACK 的往返延迟、flash 写入等待时间实际刷 256KB 固件可能要两分钟以上。工业产线能接受但如果一天刷几百台产线可能不干。流水线方案是连续发 N 帧不停设备收到校验失败的帧时回复 NAK上位机从失败帧重新开始补发。这个方案要把协议加一个「连续传输模式」发完 64 帧seq 0~63后等一个批量 ACK。速度能追上纯 CAN 理论带宽刷 256KB 大约二十秒内完成。代价是设备端要有足够大的接收缓冲区和精心设计的 flash 写入流程否则高频帧到的时候上一条还没写完照样溢出丢帧。我的建议是初期版本先做逐帧 ACK把功能和稳定性跑通再抽象出一层「发送策略」接口改成流水线模式只动上位机和设备端的一个状态机不动帧格式。逐帧 ACK 不是浪费时间它是你调试流水线时的参照物——改成流水线后发现丢帧你可以立刻切回逐帧 ACK 对比定位是协议问题还是 flash 写入问题。3.4 握手时序从复位到擦除的关键状态机设备上电后 bootloader 不会立刻进入升级模式它会先看一个标志位App 区的起始位置有没有有效的栈指针和复位向量。如果有延迟几百毫秒直接跳进 App如果没有或者收到升级命令才留在 bootloader。这个延迟窗口是给上位机留的产线刷机时先给设备上电紧接着发握手命令bootloader 在延迟窗口里收到握手命令就放弃跳转、进入升级流程。握手流程建议做成这样bootloader 收到0xA5 0x01后回一帧包含 bootloader 版本号、App 版本号、最大支持固件大小的响应帧。上位机解析版本号确认固件匹配后再发擦除命令。擦除命令执行完成后bootloader 回一个 ACK上位机才开始逐帧发数据。最后上位机发校验命令设备端对 App 区整段做 CRC32 校验结果正确回 ACK上位机再发跳转命令。这套流程看起来啰嗦但每一步都在避免「刷到一半发现固件不对」。比如握手时校验 App 版本号能防止把 A 产品的固件刷进 B 产品擦除后回 ACK能防止设备还在擦除时上位机就开始发数据导致擦写竞争。产线刷机的操作员不懂协议他们只看到上位机界面上的红绿状态所以协议里的每一步都是给可靠性兜底。4. 把 bootloader 代码跑起来擦写驱动、状态机与最小程序4.1 Flash 驱动解锁、双字编程与扇区擦除的最小函数F103 的 flash 编程有一个必须记住的原则写入的最小单位是 16 位但性能最优的单位是 64 位双字。逐 16 位写不是不行但 flash 控制器每次编程操作都有固定的操作时间一次写 16 位和一次写 64 位耗时接近所以攒满双字再写是提升速度的关键。下面这段是基于标准外设库的最小 flash 驱动去掉错误处理保留核心流程#include stm32f1xx.h #define APP_BASE_ADDR 0x08008000UL #define BOOTLOADER_SIZE 0x8000UL static uint8_t flash_buf[8]; // 双字缓冲8 字节 static uint8_t flash_buf_cnt 0; void flash_unlock(void) { FLASH_Unlock(); // 标准库解锁写 KEYR 两次 /* 在 F103 HD 上解锁 flash 后才能操作闪存编程/擦除 */ } void flash_erase_sector(uint32_t sector_addr) { FLASH_ErasePage(sector_addr); // 按页擦除F103 HD 1KB/页 while (FLASH_GetFlagStatus(FLASH_FLAG_BSY) SET); // 等忙标志 } void flash_write_dword(uint32_t addr, const uint8_t data[8]) { uint16_t lo, hi; /* 先按 16 位拆两个 half-word。F103 flash 编程要求 16 位操作 */ lo data[0] | (data[1] 8); FLASH_ProgramHalfWord(addr, lo); while (FLASH_GetFlagStatus(FLASH_FLAG_BSY) SET); hi data[2] | (data[3] 8); FLASH_ProgramHalfWord(addr 2, hi); while (FLASH_GetFlagStatus(FLASH_FLAG_BSY) SET); /* 双字模式需要连续写 4 个 half-word这里简化演示只写 4 字节 实际应当写 8 字节或一次只写 4 字节。正式代码请扩展为 8 字节 */ } void flash_write_stream(uint32_t addr, const uint8_t *data, uint32_t len) { uint32_t i; for (i 0; i len; i) { flash_buf[flash_buf_cnt] data[i]; if (flash_buf_cnt 8) { flash_write_dword(addr, flash_buf); // 双字对齐写入 addr 8; flash_buf_cnt 0; } } }这段代码里的flash_write_stream最关键它把上位机一帧一帧发来的 4 字节数据攒到flash_buf里攒满 8 字节才调用一次 flash 编程。如果你偷懒每收一帧写一次写入时间会翻好几倍而且 CAN 下一帧随时可能到flash 还在忙丢帧就来了。注意FLASH_ProgramHalfWord要求地址是 2 字节对齐所以addr必须是偶数双字对齐时addr应是 8 的倍数。如果你从0x08008000开始写天然满足这个条件但如果你在 App 区中间偏移了一个奇数地址写入flash 控制器会直接报错。4.2 Bootloader 主循环CAN 接收、命令解析、喂狗主循环极简版如下重点在状态机和看门狗typedef enum { ST_IDLE, // 空闲等待握手 ST_HANDSHAKE, // 已握手 ST_ERASE, // 正在擦除 ST_PROGRAM, // 正在接收数据 ST_VERIFY, // 校验中 ST_JUMP // 准备跳转 } boot_state_t; static boot_state_t state ST_IDLE; static uint32_t write_addr APP_BASE_ADDR; void bootloader_main(void) { CanRxMsg rx_msg; uint8_t crc_ok; IWDG_Config(500); // 独立看门狗500ms 复位 while (1) { IWDG_Reload(); // 每条路径都喂狗 if (CAN_Receive(CAN1, CAN_FIFO0, rx_msg) CAN_OK) { if (rx_msg.IDE CAN_Id_Standard) { if (rx_msg.StdId 0x501) { handle_cmd_frame(rx_msg); } else if (rx_msg.StdId 0x502) { handle_data_frame(rx_msg); } } } if (state ST_JUMP) { jump_to_app(APP_BASE_ADDR); } } } static void handle_cmd_frame(CanRxMsg *msg) { uint8_t *d msg-Data; switch (d[1]) { case 0x01: // 握手 if (state ST_IDLE) { uint8_t reply[8] {0xA5, 0x01, BOOT_VERSION, APP_VERSION, 0, 0, 0, 0}; can_send(0x501, reply, 8); state ST_HANDSHAKE; } break; case 0x02: // 擦除 if (state ST_HANDSHAKE) { uint32_t addr (d[4] 24) | (d[5] 16) | (d[6] 8) | d[7]; flash_erase_sector(addr); write_addr APP_BASE_ADDR; can_send_ack(0x02); // 回复擦除完成 state ST_PROGRAM; } break; case 0x05: // 跳转 if (state ST_VERIFY) { state ST_JUMP; } break; } } static void handle_data_frame(CanRxMsg *msg) { uint8_t *d msg-Data; if (state ! ST_PROGRAM) return; if ((d[0] 0x0F) ! expected_seq) return; // 序号不符丢弃 crc_ok check_crc16(d 2, 4, d[6], d[7]); // CRC 校验 if (crc_ok) { flash_write_stream(write_addr, d 2, 4); write_addr 4; can_send(0x502, ack_frame, 8); // 逐帧 ACK expected_seq; } else { can_send(0x502, nack_frame, 8); // NAK请求重传 } }主循环里每个分支都调用了IWDG_Reload这不是偷懒是必需的——如果擦除扇区用时超过看门狗周期擦除过程中没地方喂狗设备直接复位升级中断。所以看门狗超时要配合擦除耗时调比如擦一个 64KB 扇区实测 30ms看门狗就设 500ms 甚至 1s别设 100ms。expected_seq是逐帧 ACK 模式下防重放的哨兵。上位机每发一帧设备端都检查序号只有严格递增才写入。如果中间丢了一帧上位机的 ACK 没等到会超时重发序号对不上就全部回 NAK直到上位机把断点之后的数据重新发全。4.3 上位机最小脚本按协议把 bin 文件拆帧发送设备端代码没有上位机配合等于只有半套工具。这里给一个基于 python-can 的最小上位机示例它只做两件事把 bin 文件按 4 字节拆成数据帧逐帧发送并等待 ACK。换成不同的 USB-CAN 适配器只需要改can.interface.Bus那一行的interface和channel参数。import can import struct import time CAN_BITRATE 500000 ID_CMD 0x501 ID_DATA 0x502 APP_BASE 0x08008000 def crc16(data: bytes) - int: crc 0xFFFF for b in data: crc ^ b for _ in range(8): crc (crc 1) ^ 0xA001 if (crc 1) else (crc 1) return crc def send_frame(bus, arb_id, data): msg can.Message(arbitration_idarb_id, datadata, is_extended_idFalse) bus.send(msg) def wait_ack(bus, timeout0.5): deadline time.time() timeout while time.time() deadline: msg bus.recv(timeout0.1) if msg is not None and msg.arbitration_id ID_DATA: if msg.data[1] 0x00: # 约定 ACK 帧第二字节为 0 return True if msg.data[1] 0x01: # NAK return False return None def send_firmware(bus, filepath): fw open(filepath, rb).read() if len(fw) % 4: fw b\xFF * (4 - len(fw) % 4) # 补位到 4 字节对齐 seq 0 for i in range(0, len(fw), 4): chunk fw[i:i4] last 1 if i 4 len(fw) else 0 c crc16(chunk) frame bytes([seq, last]) chunk struct.pack(H, c) send_frame(bus, ID_DATA, frame) for _ in range(10): # 最多重试 10 次 r wait_ack(bus) if r is True: break send_frame(bus, ID_DATA, frame) # NAK 或超时都重发 else: raise RuntimeError(fSeq {seq} 发送失败) seq (seq 1) 0x0F # 只取低 4 位做序号 if __name__ __main__: bus can.interface.Bus(interfacepcan, channelPCAN_USBBUS1, bitrateCAN_BITRATE) send_firmware(bus, app.bin)脚本里的重试逻辑很朴素10 次内收到 ACK 继续否则抛异常。实际产线脚本会再加一层「整包超时」判断如果你 30 秒没收到任何响应直接报设备不在线别无限重试下去。另外注意补位用的0xFF这是给未初始化的 Flash 空间用的——如果固件本身尾部有未用区域填充0xFF能把它们变成擦除后的值避免后续校验麻烦。5. CAN bootloader 翻车排查6 条最常见的血泪坑5.1 擦除把自己擦没了现象刷机过程中设备彻底变砖连 bootloader 都进不去SWD 连上后发现 Flash 全空。 原因擦除命令里传的地址不是扇区边界比如把 App 地址0x08008000当成了 1KB 页对齐地址做按页擦除但某些实现里调用了全片擦除或者擦除范围包含 bootloader 扇区。 解决擦除地址必须来自 2.2 节的分区表bootloader 占用的扇区绝对不能被擦除命令覆盖。在handle_cmd_frame里加边界断言if (addr BOOTLOADER_SIZE) return;任何擦除地址小于 bootloader 大小的命令一律拒绝。同时擦除命令的地址和长度都要约束在 App 区内。5.2 App 一进中断就 HardFault现象App 能启动main 也能跑但一开定时器中断或 CAN 接收中断立刻死机。 原因F103 没有 VTORApp 的向量表还留在0x08000000那里是 bootloader 的向量表。中断触发时内核去 bootloader 的向量表找 handler里面是 bootloader 的中断函数地址跳过去访问了 App 的地址空间逻辑错乱。 解决App 启动第一件事就是做向量表重映射。常见做法是把 App 向量表拷贝到 SRAM 起始地址然后设置SYSCFG-CFGR1的MEM_MODE为 SRAM 映射。这段逻辑必须在任何外设中断使能之前执行。5.3 CAN 丢帧严重刷机成功率不到一半现象逐帧 ACK 模式下频繁超时重传几轮才成功一次流水线模式下几乎每批都缺帧。 原因F103 的 bxCAN 接收 FIFO 深度有限FIFO0 最多 3 个邮箱而你每收到一帧就要做 CRC、写 flash、发 ACKflash 编程期间 CAN 控制器还在接收新帧邮箱满了溢出丢帧。 解决逐帧 ACK 模式已经天然做了限速理论上不该溢但如果 flash 写入函数没做双字攒批每帧写入时间过长照样会溢。先优化flash_write_stream攒满 8 字节再写再不行用 CAN 硬件过滤器把无关帧全挡住还不行在设备端加一个简单流控收到数据帧后先回 ACK 再做 flash 操作让上位机等一拍。流水线模式则要引入环形缓冲把接收和 flash 写入解耦。5.4 看门狗复位导致刷到一半重启现象擦除大扇区时设备复位刷机中断重新上电后还是旧固件。 原因主循环里每个分支都喂狗但擦除函数是同步阻塞的一次擦 64KB 扇区可能耗时几十 ms 到上百 ms如果看门狗超时设得比擦除时间短擦除没结束狗就饿了。 解决看门狗超时要按最长阻塞路径设置擦除 64KB 扇区实测耗时 ×2 留余量。或者把擦除打散成多次小块擦除每次擦 1KB擦完喂狗但这会让擦除函数变复杂。产线场景我推荐前者简单可靠。5.5 校验通过但跳转后不停复位现象上位机校验 CRC 全部正确发跳转命令设备复位后再启动直接回到 bootloader反复循环。 原因App 区确实有数据但 App 的栈指针或复位向量不合法跳转函数检查失败主动留在 bootloader。更隐蔽的原因是 App 的复位处理函数执行不到一半又触发了某个中断中断向量表还没重映射死循环复位。 解决跳转函数里做两层判断第一层检查栈指针是否在 SRAM 范围0x20000000 ~ 0x20020000第二层检查复位向量是否为有效 Flash 地址。App 端的向量表重映射逻辑要在系统时钟初始化之后、外设中断使能之前做完。5.6 刷完固件后出厂配置全丢现象固件更新成功但设备的校准参数、序列号、MAC 地址全部被清空。 原因上位机或 bootloader 把数据写进了 App 区末尾存放参数的位置而参数区的扇区被擦除命令覆盖了。嵌入式工程师常把参数放在最后一个扇区如果分区时没把参数区独立出来擦除 App 区的命令就可能误伤。 解决在链路脚本和分区表里给参数区单独划一个扇区App 区结束地址和参数区起始地址之间留一个扇区边界。bootloader 的擦除范围必须控制在 App 区结束地址之内任何跨过参数区起始地址的擦除命令直接拒绝。同时升级前先备份参数区到 SRAM升级完成后回写这是双保险。6. 把这个 bootloader 用得更稳双分区回滚、版本握手与产线效率如果你的设备已经部署在现场而不是只在产线刷那单分区方案迟早会让你深夜进群求助。「升级到一半断电」「固件刷错了版本」「新固件有 bug 但旧固件已经被覆盖」这三个场景单分区全部无解。我在自己的项目里改用双分区后才真正睡踏实。双分区的思路是Flash 划出两个等大的 App 区bootloader 根据标志位决定从哪个区启动。升级时永远先写非活跃区写完校验通过后把标志位切过去再跳转。这样即使新固件有问题bootloader 检测到启动失败比如 App 在 3 秒内没有回心跳自动切回旧分区。代价是 Flash 占用翻倍512KB 芯片去掉 32KB bootloader剩 480KB分两个区每个 240KB对大多数固件够用。如果你的固件超过 240KB可以做成「活跃区大、备份区小」的不对称模式备份区只放一份精简回滚固件。版本握手帧是量产时的刚需。bootloader 里编死一个 bootloader 版本号App 区头部预留 4 字节版本号握手命令回复时把两个版本号一起发出去。上位机脚本先校验这两个数bootloader 版本太低不支持新协议时直接报错App 版本和要刷的固件不一致时提示确认。生产线上不同批次设备 bootloader 版本可能不一样有了版本号脚本才能给出明确报错而不是玄学超时。产线效率方面我踩过一次很深的坑最初用 100Kbps 波特率刷机256KB 固件要刷 8 分钟产线直接骂娘。后来把 CAN 波特率提到 500Kbps并且在流水线模式下连续发帧256KB 固件压缩到 40 秒出头。如果未来产品固件更大可以考虑 1Mbps但要注意总线负载和终端电阻1Mbps 下CAN_H/CAN_L 线缆长度别超过 40 米线材质量差一点就翻车。最后说一个我自己的习惯每次这套 bootloader 换到新项目我一定会在第一周故意制造「断电升级」「发一半拔线」「发一个被截断的 bin」这三种故障来测试确认设备都能回滚、都能重新进入升级模式才敢交给产线。没有经过故障注入测试的 bootloader本质上只是一堆「看起来能跑」的代码。希望这篇笔记能帮你少走几个月的弯路也希望你下次拿到这类工程标题时能一眼看出它的方案、边界和风险点。本文还有配套的精品资源点击获取 
长河君 · 2026/10/16 18:27:03 · 阅读 1.2k STM32F103 HD CAN Bootloader 方案详解：Flash分区与协议避坑
简介面向STM32F103系列的CAN bootloader源码包专为需要远程或在线升级固件的嵌入式开发者准备尤其适用于汽车电子、工业控制等依赖CAN总线通信的现场维护场景。压缩包共359个文件以c与h源码文件为主体辅以s汇编启动文件、uvprojx/uvoptx工程文件及配置文档整体体积仅1.27MB工程结构紧凑便于直接导入Keil或STM32CubeIDE分析。目前已有427人学习下载。核心实现覆盖Bootloader完整流程包括CAN报文收发、固件完整性校验、Flash擦写与程序跳转并对传输数据加密有所处理。同时s文件展示了芯片启动流程c/h文件则是协议栈与驱动实现结合工程文件可快速构建与烧录验证。开发者可从中理解CAN协议栈与STM32 HAL/LL库的实际用法参考其错误处理与多设备同步更新思路对搭建安全的远程固件更新方案很有帮助。1. 拿到这个压缩包你要解决的是「拆机刷固件」的痛点如果你的产品已经装进外壳、拧上螺丝还在靠 SWD 排线刷固件你一定遇到过这种场景产线追着要升级、售后抱着旧版本机子等回炉、同事拆了半小时壳还没碰到调试口。CANbootloader_stm32f103_HD这个压缩包的标题翻译过来就是基于 CAN 总线的 STM32F103 引导加载程序且针对 HD 高密度型号。它解决的是让设备不拆机、不开盖、通过一条 CAN 总线把新固件灌进芯片的问题。这类程序在车载、工控、储能设备里几乎是标配因为 CAN 总线在这类产品里本来就在跑通信顺手复用做升级通道能省掉一路串口、一个调试孔位产线也只需要一根 CAN 线怼上去就能刷。本文会把这套方案的原理、协议设计、最小可复现代码、常见翻车点一次讲透适合正在做 IAP 功能或者被产线升级逼疯的嵌入式开发者也适合想评估「CAN 升级到底值不值得做」的选型工程师。压缩包里大概率是标准库工程、MDK 项目和应用层说明但光看工程不够你得理解这套东西为什么这么分、跳转时哪里会炸、HD 型号和普通 F103 的 flash 操作差在哪里这些才是真正值钱的信息。2. 先定 Flash 分区HD 芯片的扇区结构决定 bootloader 能放多大2.1 F103 HD 的 Flash 扇区为什么和中容量的 MD 完全不同网上随便搜「STM32F103 bootloader」你会看到大量基于 64KB、128KB 中容量芯片的教程它们的扇区是 4 个 16KB 起步总共没几页。但标题里的HDHigh Density指的是 256KB 到 512KB Flash 的大容量型号比如 F103ZET6、F103RCT6 这类。它们的扇区布局是前 4 个扇区每块 16KB从第 4 块开始每块 64KB。512KB 的完整布局就是 4×16KB 7×64KB。这个差异直接影响 bootloader 和 App 的分区边界。如果你按中容量芯片的习惯把 App 起始地址放在0x08004000256KB 处会以为是扇区边界在 HD 芯片上擦除0x08004000开始的扇区时由于它是 64KB 扇区的起始擦除动作会覆盖0x08004000 ~ 0x08014000整整 64KB连同你可能放在0x08004000之前的 bootloader 尾巴一起擦掉。我见过不止一个人在这里翻车App 能烧进去但 bootloader 没了重新上电直接进不了升级模式。还有一种更隐蔽的情况你在 bootloader 里调用了全片擦除函数或者把擦除地址算错了页号结果把 option byte 也改了。HD 芯片的 option byte 区有自己的地址空间操作时要走FLASH_OB_Unlock流程普通擦写碰不到它但全片擦除在某些库函数里行为会不一样。所以第一课很简单先查你用的具体型号的 flash 编程手册把扇区表打出来贴在屏幕边上再动分区。2.2 两套可用的分区方案以及 App 链接脚本里要改的三个数我一般建议给 bootloader 留 32KB也就是占用前两个 16KB 扇区0x08000000 ~ 0x08008000App 从0x08008000开始。好处是 32KB 对 bootloader 来说很宽裕协议栈、CAN 驱动、flash 驱动、CRC 校验全放进去还能留日志缓冲坏处是 512KB 容量里 App 可用区域少了 32KB但对绝大多数固件来说无感。如果你的 bootloader 想压到 16KB只占扇区 00x08000000 ~ 0x08004000App 从0x08004000开始那就要要求 bootloader 代码精简到极致CAN 接收、命令解析、flash 擦写全部裸写不挂 RTOS不开 printf。16KB 不是不可能但每次加功能都要小心尺寸。产线要加个「固件版本查询」功能可能就超了。所以我个人建议除非你的 App 极大且 bootloader 有硬性容量限制否则用 32KB 方案省心。链接脚本里要改的地方是三个数这个不管你是用 MDK 的.sct文件还是 GCC 的.ld文件# App 的链接脚本以 GCC ld 为例 FLASH_START 0x08008000; # 第一个数Flash 起始地址 FLASH_SIZE 480K; # 第二个数可用容量512K - 32K # 第三个数藏在启动汇编里中断向量表偏移 # 在 system_stm32f1xx.c 或启动文件的 SystemInit 里 VECT_TAB_OFFSET 0x8000; # 0x08008000 相对 0x08000000 的偏移前两个数决定 App 能链接到哪、能占多大第三个数决定 App 的中断向量表指向哪。如果你用的是标准外设库的老工程启动文件里通常会有一段VECT_TAB_OFFSET的宏定义要确保它是0x8000否则 App 一进中断就去0x08000000查向量表找到的是 bootloader 的向量轻则中断无效重则 HardFault。2.3 跳转到 App 前必须处理的向量表与中断清理F103 用的是 Cortex-M3 老内核它没有 F4/F7 上那个好用的VTOR重定位寄存器。这直接导致一个经典坑你以为 App 编译时地址改到0x08008000中断向量就自动跑到那里了实际上它没有。常见的可靠做法有两种。第一种是跳转前把 App 的向量表从0x08008000拷贝到 SRAM 起始处然后把SYSCFG-CFGR1的MEM_MODE位设成 SRAM 映射让内核从 SRAM 里取向量。第二种是 App 在启动早期、任何外设中断打开之前自己完成上面的拷贝和重映射bootloader 只管把 PC 指过去。我建议第二种把向量表的事交给 App 自己处理bootloader 端不碰职责更干净。跳转函数本身很简单但有几个被低估的细节。跳转前要把SysTick停掉、把控制器里所有已使能的外设时钟和中断关掉否则 App 初始化到一半定时器中断触发PC 还在 bootloader 的栈上直接跑飞。我见过一个案例现象是 App 启动后 1 秒内必死查了半天才发现是 bootloader 里没关 CAN 外设CAN 接收中断在跳转后继续触发进了 App 的中断处理函数而那个地址上还是 bootloader 的静态变量。3. 通信协议设计一帧 8 字节怎么装下命令、地址、数据和校验3.1 选标准帧还是扩展帧CAN ID 如何分配CAN 标准帧最多 8 字节数据扩展帧也是 8 字节数据差别只在 ID 长度和仲裁逻辑上。对 bootloader 来说标准框架那么简单就用标准帧你的设备总线负载率高、线上已经有大量报文建议用扩展帧把 bootloader 的帧 ID 规划在不容易和业务报文冲突的区间。ID 分配上要留出控制通道和数据通道的区分。我习惯用两个固定 ID控制命令走0x501数据块走0x502全部用标准帧。控制命令含义清晰数据帧专门搬数据不容易混淆。如果产品后续有多机升级需求可以用 ID 高字节区分节点号比如0x501 | (node_id 8)但这要求 bootloader 在出厂时就知道自己的节点号通常从拨码开关或备份寄存器里读。选择 ID 时还要避坑不要在 bootloader 里用过滤器把所有报文都放进来然后靠软件过滤。CAN 控制器硬件过滤器能帮你省掉大量软件判断在 F103 的 bxCAN 上我一般把0x501和0x502配置成只接收这两个 ID其余全部丢弃。这么做的好处是即使线上有别的业务报文疯狂刷bootloader 的接收中断和主循环也不会被打扰。3.2 命令帧与数据帧的载荷布局seq、flag、CRC 的取舍CAN 一帧最多 8 字节所以载荷布局必须精打细算。我沿用了很长一段时间的布局是这样命令帧0x5018 字节 Byte 0: 0xA5 同步头 Byte 1: 命令码0x01 握手 / 0x02 擦除 / 0x03 编程 / 0x04 校验 / 0x05 跳转 Byte 2: 帧序号 seq用于重传识别 Byte 3: 保留 Byte 4~7: 命令参数擦除时放起始地址高 24 位 长度数据帧0x5028 字节 Byte 0: seq4 bit 序号 4 bit 保留 Byte 1: flagbit0 最后一帧标志 Byte 2~5: 4 字节固件数据 Byte 6~7: 4 字节数据的 CRC16每帧只带 4 字节固件数据看起来效率不高但换来的是帧格式简单、硬件 CRC 不用也可纯软算、出错定位容易。你要真想提高吞吐可以把 8 字节全塞数据CRC 放到单独的结束帧里校验整个文件但这会引入「数据全收了最后校验失败要整包重传」的局面产线上一包几百 KB 重传一次很痛苦。分帧带 CRC哪帧坏了补哪帧重传成本低一个数量级。3.3 可靠传输策略逐帧 ACK 还是流水线各自代价逐帧 ACK 是最稳的方案设备每收到一帧校验 CRC 通过后回一个 ACK 帧上位机收到 ACK 才发下一帧。这个方案的缺点肉眼可见——慢。CAN 500Kbps 下一帧标准帧在总线上的时间大约 0.2~0.3ms但加上上位机等待 ACK 的往返延迟、flash 写入等待时间实际刷 256KB 固件可能要两分钟以上。工业产线能接受但如果一天刷几百台产线可能不干。流水线方案是连续发 N 帧不停设备收到校验失败的帧时回复 NAK上位机从失败帧重新开始补发。这个方案要把协议加一个「连续传输模式」发完 64 帧seq 0~63后等一个批量 ACK。速度能追上纯 CAN 理论带宽刷 256KB 大约二十秒内完成。代价是设备端要有足够大的接收缓冲区和精心设计的 flash 写入流程否则高频帧到的时候上一条还没写完照样溢出丢帧。我的建议是初期版本先做逐帧 ACK把功能和稳定性跑通再抽象出一层「发送策略」接口改成流水线模式只动上位机和设备端的一个状态机不动帧格式。逐帧 ACK 不是浪费时间它是你调试流水线时的参照物——改成流水线后发现丢帧你可以立刻切回逐帧 ACK 对比定位是协议问题还是 flash 写入问题。3.4 握手时序从复位到擦除的关键状态机设备上电后 bootloader 不会立刻进入升级模式它会先看一个标志位App 区的起始位置有没有有效的栈指针和复位向量。如果有延迟几百毫秒直接跳进 App如果没有或者收到升级命令才留在 bootloader。这个延迟窗口是给上位机留的产线刷机时先给设备上电紧接着发握手命令bootloader 在延迟窗口里收到握手命令就放弃跳转、进入升级流程。握手流程建议做成这样bootloader 收到0xA5 0x01后回一帧包含 bootloader 版本号、App 版本号、最大支持固件大小的响应帧。上位机解析版本号确认固件匹配后再发擦除命令。擦除命令执行完成后bootloader 回一个 ACK上位机才开始逐帧发数据。最后上位机发校验命令设备端对 App 区整段做 CRC32 校验结果正确回 ACK上位机再发跳转命令。这套流程看起来啰嗦但每一步都在避免「刷到一半发现固件不对」。比如握手时校验 App 版本号能防止把 A 产品的固件刷进 B 产品擦除后回 ACK能防止设备还在擦除时上位机就开始发数据导致擦写竞争。产线刷机的操作员不懂协议他们只看到上位机界面上的红绿状态所以协议里的每一步都是给可靠性兜底。4. 把 bootloader 代码跑起来擦写驱动、状态机与最小程序4.1 Flash 驱动解锁、双字编程与扇区擦除的最小函数F103 的 flash 编程有一个必须记住的原则写入的最小单位是 16 位但性能最优的单位是 64 位双字。逐 16 位写不是不行但 flash 控制器每次编程操作都有固定的操作时间一次写 16 位和一次写 64 位耗时接近所以攒满双字再写是提升速度的关键。下面这段是基于标准外设库的最小 flash 驱动去掉错误处理保留核心流程#include stm32f1xx.h #define APP_BASE_ADDR 0x08008000UL #define BOOTLOADER_SIZE 0x8000UL static uint8_t flash_buf[8]; // 双字缓冲8 字节 static uint8_t flash_buf_cnt 0; void flash_unlock(void) { FLASH_Unlock(); // 标准库解锁写 KEYR 两次 /* 在 F103 HD 上解锁 flash 后才能操作闪存编程/擦除 */ } void flash_erase_sector(uint32_t sector_addr) { FLASH_ErasePage(sector_addr); // 按页擦除F103 HD 1KB/页 while (FLASH_GetFlagStatus(FLASH_FLAG_BSY) SET); // 等忙标志 } void flash_write_dword(uint32_t addr, const uint8_t data[8]) { uint16_t lo, hi; /* 先按 16 位拆两个 half-word。F103 flash 编程要求 16 位操作 */ lo data[0] | (data[1] 8); FLASH_ProgramHalfWord(addr, lo); while (FLASH_GetFlagStatus(FLASH_FLAG_BSY) SET); hi data[2] | (data[3] 8); FLASH_ProgramHalfWord(addr 2, hi); while (FLASH_GetFlagStatus(FLASH_FLAG_BSY) SET); /* 双字模式需要连续写 4 个 half-word这里简化演示只写 4 字节 实际应当写 8 字节或一次只写 4 字节。正式代码请扩展为 8 字节 */ } void flash_write_stream(uint32_t addr, const uint8_t *data, uint32_t len) { uint32_t i; for (i 0; i len; i) { flash_buf[flash_buf_cnt] data[i]; if (flash_buf_cnt 8) { flash_write_dword(addr, flash_buf); // 双字对齐写入 addr 8; flash_buf_cnt 0; } } }这段代码里的flash_write_stream最关键它把上位机一帧一帧发来的 4 字节数据攒到flash_buf里攒满 8 字节才调用一次 flash 编程。如果你偷懒每收一帧写一次写入时间会翻好几倍而且 CAN 下一帧随时可能到flash 还在忙丢帧就来了。注意FLASH_ProgramHalfWord要求地址是 2 字节对齐所以addr必须是偶数双字对齐时addr应是 8 的倍数。如果你从0x08008000开始写天然满足这个条件但如果你在 App 区中间偏移了一个奇数地址写入flash 控制器会直接报错。4.2 Bootloader 主循环CAN 接收、命令解析、喂狗主循环极简版如下重点在状态机和看门狗typedef enum { ST_IDLE, // 空闲等待握手 ST_HANDSHAKE, // 已握手 ST_ERASE, // 正在擦除 ST_PROGRAM, // 正在接收数据 ST_VERIFY, // 校验中 ST_JUMP // 准备跳转 } boot_state_t; static boot_state_t state ST_IDLE; static uint32_t write_addr APP_BASE_ADDR; void bootloader_main(void) { CanRxMsg rx_msg; uint8_t crc_ok; IWDG_Config(500); // 独立看门狗500ms 复位 while (1) { IWDG_Reload(); // 每条路径都喂狗 if (CAN_Receive(CAN1, CAN_FIFO0, rx_msg) CAN_OK) { if (rx_msg.IDE CAN_Id_Standard) { if (rx_msg.StdId 0x501) { handle_cmd_frame(rx_msg); } else if (rx_msg.StdId 0x502) { handle_data_frame(rx_msg); } } } if (state ST_JUMP) { jump_to_app(APP_BASE_ADDR); } } } static void handle_cmd_frame(CanRxMsg *msg) { uint8_t *d msg-Data; switch (d[1]) { case 0x01: // 握手 if (state ST_IDLE) { uint8_t reply[8] {0xA5, 0x01, BOOT_VERSION, APP_VERSION, 0, 0, 0, 0}; can_send(0x501, reply, 8); state ST_HANDSHAKE; } break; case 0x02: // 擦除 if (state ST_HANDSHAKE) { uint32_t addr (d[4] 24) | (d[5] 16) | (d[6] 8) | d[7]; flash_erase_sector(addr); write_addr APP_BASE_ADDR; can_send_ack(0x02); // 回复擦除完成 state ST_PROGRAM; } break; case 0x05: // 跳转 if (state ST_VERIFY) { state ST_JUMP; } break; } } static void handle_data_frame(CanRxMsg *msg) { uint8_t *d msg-Data; if (state ! ST_PROGRAM) return; if ((d[0] 0x0F) ! expected_seq) return; // 序号不符丢弃 crc_ok check_crc16(d 2, 4, d[6], d[7]); // CRC 校验 if (crc_ok) { flash_write_stream(write_addr, d 2, 4); write_addr 4; can_send(0x502, ack_frame, 8); // 逐帧 ACK expected_seq; } else { can_send(0x502, nack_frame, 8); // NAK请求重传 } }主循环里每个分支都调用了IWDG_Reload这不是偷懒是必需的——如果擦除扇区用时超过看门狗周期擦除过程中没地方喂狗设备直接复位升级中断。所以看门狗超时要配合擦除耗时调比如擦一个 64KB 扇区实测 30ms看门狗就设 500ms 甚至 1s别设 100ms。expected_seq是逐帧 ACK 模式下防重放的哨兵。上位机每发一帧设备端都检查序号只有严格递增才写入。如果中间丢了一帧上位机的 ACK 没等到会超时重发序号对不上就全部回 NAK直到上位机把断点之后的数据重新发全。4.3 上位机最小脚本按协议把 bin 文件拆帧发送设备端代码没有上位机配合等于只有半套工具。这里给一个基于 python-can 的最小上位机示例它只做两件事把 bin 文件按 4 字节拆成数据帧逐帧发送并等待 ACK。换成不同的 USB-CAN 适配器只需要改can.interface.Bus那一行的interface和channel参数。import can import struct import time CAN_BITRATE 500000 ID_CMD 0x501 ID_DATA 0x502 APP_BASE 0x08008000 def crc16(data: bytes) - int: crc 0xFFFF for b in data: crc ^ b for _ in range(8): crc (crc 1) ^ 0xA001 if (crc 1) else (crc 1) return crc def send_frame(bus, arb_id, data): msg can.Message(arbitration_idarb_id, datadata, is_extended_idFalse) bus.send(msg) def wait_ack(bus, timeout0.5): deadline time.time() timeout while time.time() deadline: msg bus.recv(timeout0.1) if msg is not None and msg.arbitration_id ID_DATA: if msg.data[1] 0x00: # 约定 ACK 帧第二字节为 0 return True if msg.data[1] 0x01: # NAK return False return None def send_firmware(bus, filepath): fw open(filepath, rb).read() if len(fw) % 4: fw b\xFF * (4 - len(fw) % 4) # 补位到 4 字节对齐 seq 0 for i in range(0, len(fw), 4): chunk fw[i:i4] last 1 if i 4 len(fw) else 0 c crc16(chunk) frame bytes([seq, last]) chunk struct.pack(H, c) send_frame(bus, ID_DATA, frame) for _ in range(10): # 最多重试 10 次 r wait_ack(bus) if r is True: break send_frame(bus, ID_DATA, frame) # NAK 或超时都重发 else: raise RuntimeError(fSeq {seq} 发送失败) seq (seq 1) 0x0F # 只取低 4 位做序号 if __name__ __main__: bus can.interface.Bus(interfacepcan, channelPCAN_USBBUS1, bitrateCAN_BITRATE) send_firmware(bus, app.bin)脚本里的重试逻辑很朴素10 次内收到 ACK 继续否则抛异常。实际产线脚本会再加一层「整包超时」判断如果你 30 秒没收到任何响应直接报设备不在线别无限重试下去。另外注意补位用的0xFF这是给未初始化的 Flash 空间用的——如果固件本身尾部有未用区域填充0xFF能把它们变成擦除后的值避免后续校验麻烦。5. CAN bootloader 翻车排查6 条最常见的血泪坑5.1 擦除把自己擦没了现象刷机过程中设备彻底变砖连 bootloader 都进不去SWD 连上后发现 Flash 全空。 原因擦除命令里传的地址不是扇区边界比如把 App 地址0x08008000当成了 1KB 页对齐地址做按页擦除但某些实现里调用了全片擦除或者擦除范围包含 bootloader 扇区。 解决擦除地址必须来自 2.2 节的分区表bootloader 占用的扇区绝对不能被擦除命令覆盖。在handle_cmd_frame里加边界断言if (addr BOOTLOADER_SIZE) return;任何擦除地址小于 bootloader 大小的命令一律拒绝。同时擦除命令的地址和长度都要约束在 App 区内。5.2 App 一进中断就 HardFault现象App 能启动main 也能跑但一开定时器中断或 CAN 接收中断立刻死机。 原因F103 没有 VTORApp 的向量表还留在0x08000000那里是 bootloader 的向量表。中断触发时内核去 bootloader 的向量表找 handler里面是 bootloader 的中断函数地址跳过去访问了 App 的地址空间逻辑错乱。 解决App 启动第一件事就是做向量表重映射。常见做法是把 App 向量表拷贝到 SRAM 起始地址然后设置SYSCFG-CFGR1的MEM_MODE为 SRAM 映射。这段逻辑必须在任何外设中断使能之前执行。5.3 CAN 丢帧严重刷机成功率不到一半现象逐帧 ACK 模式下频繁超时重传几轮才成功一次流水线模式下几乎每批都缺帧。 原因F103 的 bxCAN 接收 FIFO 深度有限FIFO0 最多 3 个邮箱而你每收到一帧就要做 CRC、写 flash、发 ACKflash 编程期间 CAN 控制器还在接收新帧邮箱满了溢出丢帧。 解决逐帧 ACK 模式已经天然做了限速理论上不该溢但如果 flash 写入函数没做双字攒批每帧写入时间过长照样会溢。先优化flash_write_stream攒满 8 字节再写再不行用 CAN 硬件过滤器把无关帧全挡住还不行在设备端加一个简单流控收到数据帧后先回 ACK 再做 flash 操作让上位机等一拍。流水线模式则要引入环形缓冲把接收和 flash 写入解耦。5.4 看门狗复位导致刷到一半重启现象擦除大扇区时设备复位刷机中断重新上电后还是旧固件。 原因主循环里每个分支都喂狗但擦除函数是同步阻塞的一次擦 64KB 扇区可能耗时几十 ms 到上百 ms如果看门狗超时设得比擦除时间短擦除没结束狗就饿了。 解决看门狗超时要按最长阻塞路径设置擦除 64KB 扇区实测耗时 ×2 留余量。或者把擦除打散成多次小块擦除每次擦 1KB擦完喂狗但这会让擦除函数变复杂。产线场景我推荐前者简单可靠。5.5 校验通过但跳转后不停复位现象上位机校验 CRC 全部正确发跳转命令设备复位后再启动直接回到 bootloader反复循环。 原因App 区确实有数据但 App 的栈指针或复位向量不合法跳转函数检查失败主动留在 bootloader。更隐蔽的原因是 App 的复位处理函数执行不到一半又触发了某个中断中断向量表还没重映射死循环复位。 解决跳转函数里做两层判断第一层检查栈指针是否在 SRAM 范围0x20000000 ~ 0x20020000第二层检查复位向量是否为有效 Flash 地址。App 端的向量表重映射逻辑要在系统时钟初始化之后、外设中断使能之前做完。5.6 刷完固件后出厂配置全丢现象固件更新成功但设备的校准参数、序列号、MAC 地址全部被清空。 原因上位机或 bootloader 把数据写进了 App 区末尾存放参数的位置而参数区的扇区被擦除命令覆盖了。嵌入式工程师常把参数放在最后一个扇区如果分区时没把参数区独立出来擦除 App 区的命令就可能误伤。 解决在链路脚本和分区表里给参数区单独划一个扇区App 区结束地址和参数区起始地址之间留一个扇区边界。bootloader 的擦除范围必须控制在 App 区结束地址之内任何跨过参数区起始地址的擦除命令直接拒绝。同时升级前先备份参数区到 SRAM升级完成后回写这是双保险。6. 把这个 bootloader 用得更稳双分区回滚、版本握手与产线效率如果你的设备已经部署在现场而不是只在产线刷那单分区方案迟早会让你深夜进群求助。「升级到一半断电」「固件刷错了版本」「新固件有 bug 但旧固件已经被覆盖」这三个场景单分区全部无解。我在自己的项目里改用双分区后才真正睡踏实。双分区的思路是Flash 划出两个等大的 App 区bootloader 根据标志位决定从哪个区启动。升级时永远先写非活跃区写完校验通过后把标志位切过去再跳转。这样即使新固件有问题bootloader 检测到启动失败比如 App 在 3 秒内没有回心跳自动切回旧分区。代价是 Flash 占用翻倍512KB 芯片去掉 32KB bootloader剩 480KB分两个区每个 240KB对大多数固件够用。如果你的固件超过 240KB可以做成「活跃区大、备份区小」的不对称模式备份区只放一份精简回滚固件。版本握手帧是量产时的刚需。bootloader 里编死一个 bootloader 版本号App 区头部预留 4 字节版本号握手命令回复时把两个版本号一起发出去。上位机脚本先校验这两个数bootloader 版本太低不支持新协议时直接报错App 版本和要刷的固件不一致时提示确认。生产线上不同批次设备 bootloader 版本可能不一样有了版本号脚本才能给出明确报错而不是玄学超时。产线效率方面我踩过一次很深的坑最初用 100Kbps 波特率刷机256KB 固件要刷 8 分钟产线直接骂娘。后来把 CAN 波特率提到 500Kbps并且在流水线模式下连续发帧256KB 固件压缩到 40 秒出头。如果未来产品固件更大可以考虑 1Mbps但要注意总线负载和终端电阻1Mbps 下CAN_H/CAN_L 线缆长度别超过 40 米线材质量差一点就翻车。最后说一个我自己的习惯每次这套 bootloader 换到新项目我一定会在第一周故意制造「断电升级」「发一半拔线」「发一个被截断的 bin」这三种故障来测试确认设备都能回滚、都能重新进入升级模式才敢交给产线。没有经过故障注入测试的 bootloader本质上只是一堆「看起来能跑」的代码。希望这篇笔记能帮你少走几个月的弯路也希望你下次拿到这类工程标题时能一眼看出它的方案、边界和风险点。本文还有配套的精品资源点击获取