STM32 CAN Bootloader设计与实现：基于CAN总线的固件升级方案

STM32的Bootloader通过CAN总线通讯、把HEX文件分帧发下去写进内部Flash，这套玩法听着有点绕，但在现场蹲过几次就知道有多香。我之前也一直是老老实实用串口ISP烧固件，直到碰上一个环境：设备装在全封闭机箱里，柜内还有高压模块，唯一从柜子里拉出来的通讯接口，就是两根CAN线。每次升级都要拆螺丝、开柜门、再找一根串口延长线，运气不好还接触不良，折腾一上午只烧了三台。后来我花了一个周末把CAN bootloader跑通，从此固件升级就是打开笔记本、插一条USB-CAN线、点一下发送，几分钟完事，不用拆任何盖子。这篇文章就把完整的实现思路、协议设计、上下位机代码和坑位都讲清楚，适合正在做产线固件升级、想批量给现场节点更新程序的人参考。

1. 先从现场说清楚：为什么非要挂一条CAN线做升级

1.1 设备装在全封闭机箱里，串口根本够不着

做嵌入式前期调试，大家习惯用串口、SWD、ST-Link这类工具，反正板子就在手边，怎么方便怎么来。但一旦设备进了现场，硬件形态就由你的壳子和接线决定了。我那个项目里，控制器安装在全封闭的金属柜中，柜门平时不允许打开，板上的调试引脚一律不引出，唯一的对外通讯口就是CAN。这意味着什么呢？你手里所有基于串口或SWD的升级手段，全用不上。

有人会说，那你在设计的时候留一个调试口不就行了？说得对，但现场不只有一台设备，而是几十台。柜子在产线各处分散安装，哪怕留了串口座子，你也得一台一台插线、一台一台烧。串口线一长，波特率就上不去，现场电磁环境一复杂，还动不动传错帧。真正干过批量升级的人都有体会：最耗时间的不是烧录本身，而是来回走线、拆装、确认接口的重复劳动。

所以当设备本身已经自带CAN收发器、且有一条长期在线的CAN总线时，基于CAN的Bootloader就变成了非常自然的选项。不用改任何硬件，把升级命令和数据帧挂到现有总线上就行。

1.2 串口、RS485、以太网、CAN，横向一比就有了答案

先把常见升级方式摆在一起看：

我从这两个角度来分析。串口不是不行，而是它从设计上就是点对点的，而且信号是单端，线一长、现场干扰一大，波特率就必须调低，传输可靠性也大打折扣。SWD/JTAG适合开发阶段，不适合生产现场，因为插拔次数多、引脚容易损坏，而且没法远程操作。以太网固然快，但不是每块板子都有PHY，为了升级去加一个PHY，成本和质量都是负担。

CAN的硬件门槛其实很低：一块带控制器外设的MCU、一个CAN收发器芯片、两个终端电阻，就能组成一条可靠总线。很多工业设备本来就在跑CAN应用报文，升级只是“复用这条线”。更妙的是CAN本身有总线仲裁机制，天然支持多节点挂接，这就为后面做批量升级留了很大的空间。所以选CAN，不是因为它功能新，而是它最适合现场条件。

1.3 这套方案不是万能的，先看清适用范围

CAN bootloader也有明显边界。典型波特率就是500kbps，一帧最多带8字节有效载荷，刨去帧头、地址、命令字节，实际固件吞吐量大约每秒几KB到十几KB。几百KB的固件升级还能忍，要是几十MB级别的固件，CAN的高延迟就会让升级变成煎熬。

它的适用场景是这样的：固件在几十到几百KB区间、板子已经有CAN接口、节点分散且需要避免开箱、升级频次不高。如果固件很大、升级又很频繁，我更建议考虑以太网或USB，那些方案适合的是“带宽充足”的场景。想清楚这个边界，你就知道为什么后续所有的设计都在跟“8字节一帧、4字节有效数据”较劲了。

2. 协议先行：帧ID、命令码、应答和状态机一次定死

2.1 帧结构：数据帧直接携带4字节地址，比带序号更抗乱序

协议设计是整个Bootloader的骨架，我在这上面吃过亏。刚开始我学别人的做法，数据帧只带序号和6字节数据，下位机根据序号推算地址。结果实际调试时发现，一旦CAN总线有突发干扰、某一帧丢包，上位机就得重新同步“当前序号”，下位机和上位机的计数稍微错开，整个升级链路就乱了。

后来我把方案改成“数据帧直接携带目标地址”。每个数据帧的8字节载荷这么分配：

地址是4字节，数据是4字节，正好把CAN一帧8字节用完。没有序号，没有额外的标志。你可能觉得这样浪费带宽，但这张设计的收益很大：每一帧都是自描述的，下位机拿到地址和数据直接写Flash，丢哪一帧就重发哪一帧，重复帧也不会写错位置，乱序到达也没关系。对几十KB的固件来说，单帧带宽从6字节变成4字节，损失的速度完全能用“确定性”换回来。

CAN标准帧的11位ID我用了三个：0x155给命令、0x156给数据、0x157做应答。如果总线上还有其他应用报文，记得选一个不与现有业务ID冲突的区段。

2.2 命令集：握手、擦除、写入、校验、跳转，一个都不能少

升级就是一个状态流转过程，每一步都需要明确的命令。我定义的核心命令如下：

整套流程走下来是这个顺序：上位机先发0x10握手，下位机回0x11，双方确认协议版本对得上；上位机发0x20擦除目标区域，等0x21应答；然后上位机循环发0x156数据帧，每收一帧下位机回答应帧0x157；所有数据发完后，上位机发0x40校验，下位机返回累计写入字节数，上位机跟HEX文件解析出的总字节数比对；一致后发0x50跳转，Bootloader复位并跳入APP。

这里最关键的一个顺序约束是：上位机绝不能不等擦除应答就发数据帧。擦除Flash是需要时间的，老一些的MCU擦一个128KB扇区要几百毫秒到一秒钟，这段时间CAN接收FIFO很可能溢出。如果上位机闷头猛发数据，最终结果就是丢帧，升级失败。我在协议里把擦除设计成“上行命令、下行应答、再继续”串行模式，就是为了把这个时间窗口卡住。

2.3 应答与重传：靠“回包带下一地址”解决丢帧烦恼

数据帧的应答机制是我认为这套协议里最值得分享的部分。下位机每收到一帧数据，写完后不会只回一个“成功”状态，而是在应答帧里返回“下一个待写入地址”。也就是说，下位机维护一个内部写指针current_addr_，每成功写完一帧，这个指针就加4。应答帧0x157的载荷长这样：

为什么这个设计好用？因为上位机不需要维护复杂的“序号期望值”。它只需要知道两件事：自己已经发到哪个地址了，以及下位机确认写到了哪个地址。如果应答返回的地址等于刚才发送帧的地址+4，说明这帧成功；如果小于预期，说明中间有帧丢了，上位机直接从应答地址继续重发就好。这样一来，丢包、重复帧、乱序都不需要单独处理，一个“确认地址”就全部兜住了。

上位机侧的重传逻辑也很简单：发完一帧后等50ms，没收到确认，就重发同一帧。如果重发3次仍然失败，直接报错并提示检查CAN线连接。这个超时值不要设得太短，否则在擦除等长耗时操作时会导致误重发，50ms对500kbps的CAN来说已经足够宽松。

2.4 上位机和下位机的状态机长什么样

协议一旦有状态机，代码才不会写成一锅粥。我是这样划分阶段的：

下位机在IDLE状态时不能干等，否则如果上位机一直没来，设备就永远停在Bootloader里了。我设定了一个500ms等待窗口：上电复位后如果在窗口内收到有效握手命令，就进入升级流程；否则自动跳转到APP。等窗口的具体值要根据项目来调，太短了现场操作人员反应不过来，太长了设备上电后启动延迟会变明显。

上位机这边的状态机就简单多了，无非是“发握手→等应答→发擦除→等应答→发数据包→等确认→发校验→发跳转”。真正要注意的是出错分支，比如握手上位机发了三次都没回应，要提示“目标设备可能不在升级模式”。我在上位机里把这几种失败场景做了明确区分，排查问题时能省不少时间。

3. 上位机实现：HEX解析和CAN发送的完整流水线

3.1 先把HEX读明白：冒号行与扩展地址

HEX文件这个名字很多人都听说过，但真到解析时，最容易被它绕晕的是地址映射。HEX不是直接“把文件内容丢给单片机”，它是一行行文本记录，每行代表一段数据以及它要写入的绝对地址。

典型的一行长这样：

:10010000214601380121470136007EFE09D21901

拆开看：

那个16位地址AAAA并不是最终写入Flash的完整地址。对于STM32这类按线性地址寻址的MCU，HEX里会有类型04的“扩展线性地址记录”，比如：

:020000040800F2

这一行的意思是：把后续地址的高16位基地址设置为0x0800。后面的数据记录地址0x0100，完整地址就是0x08000100。STM32内部Flash的起始地址是0x08000000，所以典型的固件HEX会先用一行040008把基地址拉到0x0800，接着才是从0x08000100开始的数据。

3.2 解析HEX的代码与边界处理

我用Python写了个简单的解析器，框架大概长这样：

def parse_hex_file(path): # 返回一个 dict: 绝对地址 -> bytes flash = {} upper_addr = 0 segment_base = 0 with open(path, 'r', encoding='ascii') as f: for raw in f: line = raw.strip() if not line.startswith(':'): continue hex_data = line[1:] # 转成字节 try: b = bytes.fromhex(hex_data) except ValueError: continue rec_len = b[0] # 数据长度 addr = (b[1] << 8) | b[2] # 16位地址 rec_type = b[3] # 记录类型 data = b[4:4 + rec_len] check = b[4 + rec_len] # 校验字节 # 校验：所有字节（包括校验字节）求和低8位应为0 if (sum(b[:-1]) + check) & 0xFF != 0: raise ValueError("HEX校验失败: " + line) if rec_type == 0: # 数据记录 # 完整地址由扩展基地址 + 16位address组成 absolute = ((upper_addr << 16) | addr) + segment_base flash[absolute] = bytes(data) elif rec_type == 1: # 文件结束 break elif rec_type == 2: # 扩展段地址 segment_base = ((data[0] << 8) | data[1]) << 4 elif rec_type == 4: # 扩展线性地址 upper_addr = (data[0] << 8) | data[1] # 排序并拼接成连续块 items = sorted(flash.items()) merged = [] cur_addr = None cur_data = bytearray() for addr, data in items: if cur_addr is None: cur_addr, cur_data = addr, bytearray(data) elif addr == cur_addr + len(cur_data): cur_data.extend(data) else: merged.append((cur_addr, bytes(cur_data))) cur_addr, cur_data = addr, bytearray(data) if cur_addr is not None: merged.append((cur_addr, bytes(cur_data))) return merged

写这个解析器时最需要注意两个点。第一，类型04和类型02是两种不同的基地址扩展方式，我一开始只处理了04，结果某次拿到一个用02扩展段地址的HEX文件时，所有地址都差了16字节。后来把两种都处理好，才不再挑文件。第二，HEX里偶尔会有地址重叠的记录，正常编译器生成的文件很少重叠，但最好不要直接覆盖旧值就完事，先按地址写入dict，最后排序拼接，这样后出现的数据会自然覆盖前面的数据，符合“文件里越靠后的记录越新”的直觉。

3.3 把二进制数据装进8字节CAN帧

解析出连续块之后，剩下的就是流水线操作：逐4字节取出，拼成CAN数据帧，发给下位机，等待应答。

def make_data_frame(addr, data_bytes): if len(data_bytes) != 4: raise ValueError("数据必须是4字节") # 地址大端在前，数据小端低字节在前 frame = [ (addr >> 24) & 0xFF, (addr >> 16) & 0xFF, (addr >> 8) & 0xFF, addr & 0xFF, data_bytes[0], data_bytes[1], data_bytes[2], data_bytes[3], ] return frame

发送主循环的思路是这样的：先解析HEX获得(addr, data)块列表；然后把每个块按4字节切片；逐个发送，并且在每次发送后调用一个wait_ack(expected_addr)函数，等待下位机返回的“下一地址”。一旦返回地址不是预期值，就把发送游标重置到返回地址处继续。

上位机端还有一个容易忽略的细节：CAN接口库调用send之后，帧只是进了发送缓冲区，不代表总线真的发出去。要根据适配器的软件判断是同步发送还是异步发送。我用的方案是发完一帧后强制等待一小段延时（比如2ms），再处理应答，这样既可以避免把发送缓冲区挤爆，也不会因为等应答卡太死把升级速度拖垮。实测下来，64KB固件大概6-10秒可以刷完，这个速度对现场升级完全够用。

4. 下位机实现：Bootloader启动流程与Flash写入

4.1 上电后先进Bootloader还是直接进APP，靠一个魔术数决定

Bootloader侧最关键的问题是：设备上电后，CPU从0x08000000开始执行，这一段到底是Bootloader还是APP？我采用的方案是：Bootloader始终放在0x08000000，APP放在偏移地址之后，比如0x08010000。Bootloader上电后先做一件小事，检查“是否需要进入升级模式”。

判断依据是写在备份寄存器或RAM里的一组魔术数。具体流程是这样：APP在运行中如果收到远程升级指令，它先往备份寄存器里写入一个约定好的魔数0x5A5AU，然后执行系统软复位。Bootloader启动后读取这个魔术数，如果匹配，就清掉它并停留在升级模式；如果不匹配，就执行正常跳转，进入APP。

同时Bootloader在升级模式里还会开一个500ms的超时窗口。也就是说，不管有没有魔术数，只要设备上电后500ms内收到了上位机的握手命令，也会留在Bootloader里。这给现场调试留了一个后门：就算APP已经跑飞、远程指令发不出去，操作人员也可以在上电瞬间立刻点握手，把设备拽进升级模式。

跳转APP的代码是所有Bootloader的公共部分，我把它整理成一个函数：

void jump_to_app(uint32_t app_addr) { /* 跳转前把能关的外设全部关掉 */ __disable_irq(); /* 从APP头部取栈顶地址和复位向量 */ uint32_t app_sp = *(volatile uint32_t *)app_addr; uint32_t app_pc = *(volatile uint32_t *)(app_addr + 4); /* 重新设置主栈指针 */ __set_MSP(app_sp); /* 跳转 */ void (*reset_handler)(void) = (void (*)(void))app_pc; reset_handler(); }

这里要注意两点：跳转之前一定要关闭全局中断和外设时钟，否则跳进APP之后中断向量仍然指向Bootloader的地址，一旦某个外设中断触发，程序就飞到不该去的地方，直接HardFault；另外，APP的链接脚本必须把FLASH起始地址改为0x08010000，APP代码本身要设置SCB->VTOR = 0x08010000，否则即便跳转成功，中断一进来还是会跑飞。

4.2 Flash擦除：按扇区来，一次清干净

STM32内部Flash的擦除不是按字节、按KB来的，而是按“扇区”整块操作。以一块1MB容量的F4芯片为例，Flash被分成4个16KB扇区、1个64KB扇区、7个128KB扇区。APP如果从0x08010000开始，占用的大小通常覆盖若干个扇区，擦除时就得把涉及到的扇区全部擦一遍。

擦除之前要先给Flash控制器解锁。STM32是这么设计的：Flash控制器默认处于锁定状态，防止程序误写，解锁需要在KEYR寄存器里依次写入两个固定密钥值（这两个值是芯片手册公开的固定值）。写入后，设置扇区选择寄存器，然后把擦除启动位置1，等待忙标志清除。

void flash_sector_erase(uint32_t sector_num, uint8_t count) { flash_unlock(); for (uint8_t i = 0; i < count; i++) { FLASH->CR |= FLASH_CR_SER; /* 扇区擦除模式 */ FLASH->CR &= ~FLASH_CR_SNB_Msk; FLASH->CR |= ((sector_num + i) << FLASH_CR_SNB_Pos) & FLASH_CR_SNB_Msk; FLASH->CR |= FLASH_CR_STRT; /* 启动擦除 */ while (FLASH->SR & FLASH_SR_BSY); /* 等待完成 */ if (FLASH->SR & FLASH_SR_PGSERR) { /* 错误处理 */ } } flash_lock(); }

我踩过一个跟擦除有关的坑：擦除期间不能继续接收大量CAN帧，因为擦除操作会阻塞CPU。如果协议设计成“擦除命令由上位机发出、上位机不等应答就继续发数据”，那这些数据基本都会丢在CAN的接收FIFO溢出错里。所以我的下位机代码里，收到擦除命令后会在擦除期间暂时屏蔽CAN接收中断，擦完再恢复，这样就算上位机误发了几帧数据，也不会把状态搞乱，最多是丢帧后依赖协议重传兜回来。

4.3 逐帧写入与校验：别让BSY标志卡死你

Flash写入和擦除一样，也要先解锁，然后设置编程模式。写入是按双字（8字节）还是按32位字来，取决于具体芯片。我在示例里先用32位字写，保证4字节对齐，这跟CAN数据帧的4字节设计刚好匹配。

void flash_write_word(uint32_t addr, uint32_t value) { flash_unlock(); FLASH->CR |= FLASH_CR_PG; /* 编程模式 */ /* 写入前等BSY清除，防上次操作未完成 */ while (FLASH->SR & FLASH_SR_BSY); *(volatile uint32_t *)addr = value; while (FLASH->SR & FLASH_SR_BSY); /* 等本次写完成 */ if (FLASH->SR & FLASH_SR_EOP) { FLASH->SR |= FLASH_SR_EOP; /* 清结束标志 */ } FLASH->CR &= ~FLASH_CR_PG; /* 关闭编程模式 */ flash_lock(); }

这段代码有两个细节值得展开。第一，写入完成后一定要检查PGSERR等错误标志，而且要用“读回验证”确认写入正确。我写过一个回读函数：写完地址后把该地址的数据读出来跟期望值比一比，不相等就返回错误应答。Flash编程是有可能失败的，尤其电源不稳定的时候，只靠“写完没报错”根本不够。第二，等待周期（LATENCY）必须在Flash初始化时配置好。MCU主频越高，Flash读取需要的等待周期就越多。如果某个项目里APP跑起来频繁卡死、偶尔用着用着就HardFault，八成就是这个等待周期没配，跟Bootloader本身没写对是两码事。很多人在Bootloader里闪写正常，一到APP就跑飞，其实就是编译时忘记在APP侧重新配置Flash的等待周期。

4.4 跳转APP前要收拾干净的几件事

下位机在收到0x50跳转命令后，不能直接调jump_to_app，那会导致CAN外设还开着、中断还挂着，跳到APP一瞬间就被旧的外设中断打乱。正确的跳转顺序是：

1. 关闭CAN外设，关闭用到的定时器和中断；
2. 把所有挂起的中断请求清掉；
3. 重新把系统时钟切回默认时钟源，避免APP初始化假设从默认时钟开始；
4. 读取APP首字设置MSP；
5. 读取复位向量并跳转。

还有一点很容易被忽略：APP的链接脚本必须把中断向量表放在APP的起始地址，且APP代码要在启动早期设置SCB->VTOR。我见过跳转成功后第一个中断就HardFault的案例，查到最后就是VTOR没设。用文字描述，跳转这件事本身不复杂，但“跳转前的环境清理”和“APP侧向量表配置”两个环节，几乎覆盖了我遇到的所有跑飞问题。

5. 实测记录：一次完整升级的时间线和踩过的坑

5.1 从解析HEX到跑起APP的十分钟体验

实测时我用的是一块F4开发板，通过一个USB-CAN适配器接到电脑，下位机跑Bootloader，上位机用自己写的Python脚本做升级。整个升级动作是这样的：

• 连接CAN适配器，波特率统一设为500kbps；
• 上电后电脑先发握手命令，设备回握手应答；
• 上位机发擦除命令，把APP所占用的Flash扇区清空；
• 上位机开始连续发数据帧，一帧4字节，全网实测大概每秒能发2000帧左右；
• 64KB固件分16384帧发完，约7秒；
• 发完后上位机发校验命令，下位机返回累计字节数，比对一致；
• 上位机发跳转命令，设备重启，APP跑起来。

第一次跑通时我还挺激动，后来我发现整个过程稳定得像流水线，反而没人觉得这是多难的事。但如果只从时间上看，64KB固件用CAN传输也就几秒钟，真正花时间的恰恰是你前期把协议、解析、擦写这几个环节弄对。

5.2 现场踩过的几个坑与排查思路

这里把我印象最深的几个问题写出来，每一个都对应着一个可复现的现场现象。

第一个坑是上位机握手永远没响应。排查到最后是USB-CAN适配器和板子的波特率配置不一致。CAN的位时间由APB1时钟、预分频和段寄存器共同决定，两边参数看着像其实完全不是一码事。比如APB1时钟为42MHz、目标500kbps时，如果预分频设为6、位时间用14个tq，即42MHz除以6再除以14等于500kbps。这类参数最好直接在代码里写死，并且在握手应答里带上版本号，避免旧板子和新上位机参数漂移。

第二个坑是升级到一半进度条卡住，然后上位机报超时。我加打印后发现，下位机明明收到了数据帧，但应答帧没回出去。原因是应答帧发送后，我没有检查CAN发送邮箱是否完成就进入下一次擦除或写入，而下一条总线报文把还没发出的应答帧覆盖了。排查后我把应答发送改成“必须等发送邮箱空闲或发送完成中断置位”，问题立刻消失。

第三个坑是HEX文件本身带了多个不连续的地址段。有一次我拿到一个固件，它的数据段在0x08010000到0x08017FFF之间跳来跳去，中间留了很大一段空洞。如果上位机只按“所有地址连续”的假设去发数据、下位机按固定顺序写，就会在空洞处写入一大堆原本不存在的数据，导致APP启动异常。解决办法就是前面说的，把HEX先解析成连续块，再按块发。对于块与块之间的空洞，上位机可以正常工作，因为数据帧里带地址，地址跳变不会影响下位机。

第四个坑是跳转APP后设备完全没反应，硬件上电电流也没异常。我把Bootloader里跳转前的中断关闭和APP的VTOR配置都检查了一遍，最后发现是APP的链接脚本里Flash起始地址还写在0x08000000，导致APP的向量表覆盖了Bootloader区域，两个程序相互干扰。把链接脚本改成0x08010000之后，一切都正常了。

5.3 调试CAN Bootloader的常用工具与手段

CAN总线调试没有串口那么直观，但办法还是有的。我常用的调试手段按优先级排是这样的：

• 用CAN分析仪或逻辑分析仪抓总线帧，对照协议逐帧核对ID、命令码和数据；
• 下位机在关键步骤回传错误码。例如擦除失败返回0xF0+错误码，写Flash校验失败返回0xF0+错误码；
• 在上位机打印每一帧的发送地址和确认地址，出现差值就知道丢帧发生在哪个区间；
• 如果问题在下位机内部逻辑，可以在Bootloader里通过CAN把调试信息发出来，相当于用CAN当串口用。比如send_dbg("erase start")和send_dbg("erase done")，看这些字符串就能定位到卡在哪一步。

我最喜欢的是“错误码入协议”的做法。本来Bootloader为了省空间几乎不打印字符串，但把错误码做成一字节编号是零成本的。升级失败后，上位机读到的应答帧里直接带着错误码，一张表就能查出问题，不用再去翻代码。

6. 一些补充思考与后续扩展

CAN Bootloader跑通之后，再往上走其实还有不少可玩的空间。我这里列几个我认为比较贴近实际的方向。

多节点批量升级是最顺理成章的扩展。一条CAN总线上挂了十几台设备，如果不想一台一台插线，可以在握手命令里带上“目标节点ID”，所有节点都接收指令但只有匹配ID的节点回应并进入升级流程。这里要注意CAN的应答冲突问题：如果几十个节点同时回应答，总线上会因ID仲裁发生一锅粥。我建议让每个节点根据自身ID错开几十毫秒再回包，上位机轮询式地逐个握手、逐个擦写、逐个跳转。

断点续传也值得考虑。升级过程中如果现场突然断电，重新上电后往往要从头刷一遍。要实现断点续传，可以在Flash末尾专门留一个256字节的状态区，保存“当前已写入地址、固件总长度、固件校验值”这一组信息。下次握手时上位机读到这个进度，直接从断点继续发，省掉重复传输。

双区备份是更接近工业产品的方案。把Flash分成APP主分区和备份分区，新固件先写入备份分区，全部校验通过后再把启动标志切换为新分区。这样万一新固件自身有问题，设备还能回退到旧固件，不会再出现“刷一次变砖”的事故。

就我个人体会来说，这套CAN Bootloader做得越久越觉得，真正花时间的不是那几十行Flash驱动，而是协议设计里的每一个小决定：数据帧带不带地址、应答里带什么信息、状态机里哪个环节允许超时重发。这些决定直接决定了后期调试的舒适度。

最后再分享一个小技巧。我每次发布固件前，都会先从HEX里解析出“固件大小”和“CRC校验值”，把这两个数字写进升级命令的握手请求里。下位机在升级完成后不光要校验“收到的字节数”，还会把写入内容的CRC发回来跟上位机对表。多这一个动作，基本可以杜绝“固件传完但内容不对”的隐蔽问题。这个小细节看起来不起眼，但曾帮我在现场避免过一次因为编译器优化配置不同导致固件校验不一致的返工。做Bootloader这件事，本质就是让“把程序安全可靠地放进芯片”这个动作自动化，而安全的功夫，全都在这些细节里。