从零构建STM32 Bootloader：集成bsdiff差分升级的实战指南

1. 为什么我们需要一个“聪明”的Bootloader？

大家好，我是老李，在嵌入式这行摸爬滚打十几年了。今天想和大家聊聊一个几乎所有做物联网设备的朋友都会遇到的“老大难”问题：固件升级。你想想看，你的设备卖出去，部署在几百公里外，突然发现一个紧急的Bug需要修复，或者要增加一个酷炫的新功能，你总不能派工程师一个个跑去现场拆机、烧录吧？这时候，OTA（空中升级）就成了救命稻草。

但OTA说起来简单，做起来坑可不少。最直接的办法就是把整个新固件包（比如1MB）通过网络传下去。听起来还行？但如果你用的是窄带物联网，比如NB-IoT，或者信号不稳定的GPRS，这1MB的数据可能传半小时都传不完，流量费心疼不说，中途一旦断线还得重来，用户体验极差。更关键的是，我们的芯片内部Flash（闪存）空间往往很金贵，Bootloader、应用程序、用户数据分区已经挤得满满当当，哪还有地方临时存放一个完整的新固件包？

所以，我们需要一个更“聪明”的升级方案。这就是今天要聊的差分升级。它的核心思想特别像我们打补丁：我不需要把整件新衣服都发给你，我只需要发一个“补丁”，告诉你新衣服和旧衣服哪里不一样，你照着这个“补丁”在自己旧衣服上缝缝补补，就能得到一件新衣服。这个“补丁”就是差分包，它通常只有完整新固件的10%甚至1%大小。而负责接收这个“补丁”，并在设备上执行“缝补”工作的那个最核心的程序，就是我们的Bootloader。

这次，我们就来手把手，从零开始，构建一个专为STM32设计的、集成了bsdiff差分算法的Bootloader。我会把我自己踩过的坑、调试时掉的头发，都变成清晰的步骤分享给你。目标很简单：让你看完就能动手，做出一个既省流量又省空间，还稳定可靠的OTA升级方案。

2. 动手之前：核心概念与整体设计

在撸起袖子写代码之前，我们得先把几个关键概念和整体架构理清楚。磨刀不误砍柴工，这里想明白了，后面能避开一大堆弯路。

2.1 认识两位“主角”：Bootloader 与 bsdiff

首先说说Bootloader。你可以把它想象成电脑的BIOS。一上电，它第一个跑起来，它的任务不是执行你的主要业务逻辑（比如控制电机、采集传感器数据），而是负责检查“有没有新版本的程序需要安装”？如果有，它就负责把新程序“安装”到指定的Flash位置；如果没有，或者安装完了，它就“跳转”到主应用程序那里，把CPU的控制权交出去。它的代码必须非常精简、健壮，因为一旦它出问题，设备就“变砖”了。

然后是bsdiff。这是一个非常经典且高效的二进制差分算法，由Colin Percival开发。它比很多简单的“逐字节比较”算法要聪明得多。bsdiff算法会先对旧文件和新文件进行类似后缀排序的处理，找到两者之间匹配和不匹配的区块，然后生成三部分数据：一个控制指令集（告诉你怎么操作）、一个差异数据块（新增的内容）、一个额外数据块（需要从旧文件复制过来再修改的内容）。最终生成的补丁文件（patch）非常小。而且它还有一个好搭档叫bspatch，就是专门用来根据旧文件和补丁文件，合成出新文件的。在我们的Bootloader里，就需要集成这个bspatch的功能。

2.2 规划我们的Flash地图

Flash空间就像一块有限的地皮，我们必须提前规划好每个区域是干什么的，不能打架。参考很多成熟方案（比如ARM的MCUboot），我设计了一个比较通用的四分区布局，以一颗拥有512KB Flash的STM32F103VE为例：

注意：这里的地址和大小需要根据你芯片的具体Flash容量来调整，并且要严格遵守你的链接脚本（.ld文件）中的定义，后面会详细讲。下载缓冲区（96KB）的大小设计是有讲究的，它需要能放得下可能出现的最大差分包，通常这远小于完整固件，所以96KB是足够的。

这个设计的好处是清晰、安全。Bootloader和主程序物理隔离，互不影响。下载区专包专用，即使升级中途断电，也只是下载区的数据损坏，不会影响到正在运行的程序区。状态标志区记录了升级的“进度条”，让Bootloader知道上次升级做到哪一步了，方便实现断点续传（这是一个进阶功能，我们今天先聚焦基础）。

3. 搭建Bootloader的基础骨架

好了，理论准备就绪，我们打开STM32CubeIDE或者你熟悉的Keil、IAR，开始创建工程。

3.1 创建工程与关键配置

首先，新建一个STM32的工程，芯片选型对应好。这里有几个关键配置点，我一个个说：

1. 设置中断向量表偏移：这是最关键的一步！因为我们的应用程序不是从0x08000000开始，而是从0x08008000开始。所以，在Bootloader工程的system_stm32f1xx.c（或其他系列对应文件）中，或者直接在main.c初始化时，我们需要通过SCB->VTOR寄存器，设置中断向量表的偏移量。对于Bootloader本身，偏移量是0。但更重要的是，当Bootloader跳转到应用程序前，它必须把应用程序的向量表偏移设置好。我们会在跳转代码里做这件事。

   // 在Bootloader中，跳转到应用程序前的操作 void jump_to_application(uint32_t app_address) { typedef void (*pFunction)(void); pFunction jump_to_app; // 1. 设置应用程序的堆栈指针（MSP） __set_MSP(*(__IO uint32_t*)app_address); // 2. 设置应用程序的中断向量表偏移 SCB->VTOR = app_address; // 3. 获取应用程序的复位中断服务程序地址，并跳转 jump_to_app = (pFunction)*(__IO uint32_t*)(app_address + 4); jump_to_app(); }

2. 修改链接脚本（.ld文件）：我们需要告诉编译器，我们的Bootloader代码只能放在前32KB的空间里。以GCC链接脚本为例，你需要修改MEMORY部分和SECTIONS部分，确保FLASH的ORIGIN是0x08000000，LENGTH是32K。并且检查生成的.map文件，确认代码大小没有超出。

3. 初始化基本的硬件：Bootloader需要最基本的系统时钟、GPIO（可能用于状态指示灯）、串口（用于打印日志和通信）、Flash编程接口（用于擦写其他分区）。切记，只初始化必要的部分，像USB、以太网、复杂的文件系统等，除非升级流程必需，否则不要初始化，以保持代码精简。

3.2 实现Bootloader的主逻辑流程

Bootloader的main函数逻辑应该像下面这样清晰：

int main(void) { // 1. 基础硬件初始化（时钟、GPIO、串口、Flash） hardware_init(); // 2. 打印启动信息（方便调试） printf("Bootloader v1.0 Started.\r\n"); // 3. 检查状态标志区，判断是否有待处理的升级任务 upgrade_status_t status = read_upgrade_status(); switch(status) { case STATUS_NEW_PACKAGE_READY: // 4. 有升级包，开始升级流程 process_upgrade_package(); // 升级完成后，更新状态为成功或失败 write_upgrade_status(STATUS_UPGRADE_COMPLETE); break; case STATUS_UPGRADE_COMPLETE: case STATUS_NO_UPGRADE: default: // 5. 无升级任务，直接尝试跳转到应用程序 break; } // 6. 跳转到应用程序 if (is_application_valid(APPLICATION_START_ADDRESS)) { jump_to_application(APPLICATION_START_ADDRESS); } else { // 7. 应用程序无效，进入命令行模式或等待升级 printf("No valid App. Enter command mode.\r\n"); command_line_loop(); } // 不应该执行到这里 while(1); }

这个流程框图中，process_upgrade_package()是核心，我们下一章会重点填充它。command_line_loop()可以是一个简单的串口命令行，支持手动触发升级、查看信息等，对于调试非常有用。

4. 移植与集成bsdiff/bspatch算法库

现在来到最具技术挑战，但也最能体现方案价值的部分：把bsdiff/bspatch算法库搬到我们的STM32上。

4.1 获取源码与理解结构

bsdiff的官方源码可以在它的官网找到。但更常见的是使用GitHub上一些优化后的版本，比如用C语言重写的，更适合嵌入式环境。你可以搜索“bsdiff C port”。我当年用的是一个大神移植到C的版本，它通常包含以下几个核心文件：

• bsdiff.c：生成差分包的工具源码（这个我们在PC端用，不用放进MCU）。
• bspatch.c：合成新文件的工具源码（这个才是要移植进Bootloader的关键！）。
• bsdiff.h/bspatch.h：头文件。

bspatch.c是整个库的灵魂，它依赖bzip2库进行数据解压（因为bsdiff生成的补丁是经过bzip2压缩的）。这就带来了第一个难题：bzip2库对于资源紧张的MCU来说有点庞大。

4.2 瘦身与适配：让bspatch能在MCU上跑起来

直接编译bspatch.c和bzip2库，代码体积可能会爆炸。我们必须进行“瘦身”：

1. 简化或替换bzip2：这是最大的优化点。bsdiff使用bzip2是为了让补丁更小。但在MCU端，我们可以考虑：

   • 使用更轻量的压缩算法：比如LZ4、MiniLZO。但这需要你同时修改PC端生成差分包的工具（bsdiff），让它也用对应的算法压缩，保证两端匹配。工作量较大，但收益也高。
   • 使用bsdiff的“不压缩”模式：有些bsdiff实现支持生成未压缩的补丁。补丁体积会大一些，但完全省去了解压库。这对于内部Flash空间极度紧张，但下载缓冲区相对宽松的场景是一个选择。
   • 保留bzip2，但极致裁剪：只编译bspatch.c所需的最少的bzip2源文件（如blocksort.c,huffman.c,crctable.c,randtable.c,compress.c,decompress.c等），并关闭所有非必需的特性。在编译器中设置最高级别的空间优化（-Os）。

2. 优化内存使用：bspatch函数执行时需要内存来存放旧数据、新数据和控制数据。它内部会调用malloc。在MCU上，我们必须用静态数组或自己的内存池来替代。

   // 示例：定义一块静态内存作为bspatch的工作缓冲区 #define PATCH_WORK_BUFFER_SIZE (20 * 1024) // 20KB static uint8_t work_buffer[PATCH_WORK_BUFFER_SIZE]; // 然后你需要修改bspatch.c中的内存分配函数，或者实现一个自定义的my_malloc，从work_buffer中分配。

   你需要仔细阅读bspatch.c的代码，估算它所需的最大内存。一个技巧是，在PC上先用一个大日志模式运行bspatch，观察其内存分配峰值。

3. 文件操作接口替换：原始的bspatch是从文件读取旧文件、补丁文件，并写入新文件。在MCU上，我们没有文件系统，数据都在Flash里。我们需要把open,read,lseek,write这些函数调用，替换成对Flash的直接读（memcpy）和写（HAL_FLASH_Program）操作。

4.3 封装一个MCU友好的bspatch接口

经过一番改造，我们最终希望提供一个这样的函数给Bootloader主流程调用：

/** * @brief 在MCU上应用差分补丁 * @param old_data_ptr: 指向旧固件（当前APP）的指针 * @param old_data_len: 旧固件的长度 * @param patch_data_ptr: 指向差分补丁包的指针 * @param patch_data_len: 差分补丁包的长度 * @param new_data_ptr: 指向存放新固件缓冲区的指针（通常就是下载缓冲区或应用程序备份区） * @retval int: 0成功，其他为错误码 */ int mcu_bspatch(const uint8_t* old_data_ptr, uint32_t old_data_len, const uint8_t* patch_data_ptr, uint32_t patch_data_len, uint8_t* new_data_ptr);

这个函数内部，就是对改造后的bspatch逻辑的封装，处理内存管理、Flash访问和错误处理。实现它，是整个项目最硬核的一步。当你第一次在串口日志里看到“bspatch apply success”时，那种成就感是无与伦比的。

5. 构建完整的差分升级工作流

算法集成好了，我们现在来串起整个流程。一个完整的差分升级，涉及PC端工具链和设备端Bootloader的协同。

5.1 PC端：生成差分升级包

设备端的bspatch需要一个补丁包，这个包得在PC上生成。你需要编译我们之前提到的bsdiff工具（或者用Python版本的bsdiff4库）。流程很简单：

1. 准备好旧版本固件app_v1.0.bin和新版本固件app_v1.1.bin。
2. 执行命令：bsdiff app_v1.0.bin app_v1.1.bin patch_v1.0_to_v1.1.bin。
3. 得到差分包patch_v1.0_to_v1.1.bin。比较一下大小，你会发现它可能只有完整新固件的5%-20%。

但是，直接把这个bin文件发给设备是不够的。设备需要知道这个包的信息：比如这是差分包还是全量包？包的长度是多少？CRC校验值是多少？版本号是什么？所以我们需要给这个原始的补丁包加一个“信封”，也就是镜像头。

我们可以写一个简单的Python脚本mkpatch.py来做这件事：

# 示例，非完整代码 import struct, hashlib, zlib def add_image_header(patch_bin_path, output_path, version='1.1.0'): with open(patch_bin_path, 'rb') as f: patch_data = f.read() # 计算CRC32或SHA256 crc32 = zlib.crc32(patch_data) & 0xffffffff # 构建一个自定义头结构，例如：魔数(4B) + 类型(1B) + 版本(4B) + 数据长度(4B) + CRC32(4B) header = struct.pack('<4sB4sII', b'PATC', 0x02, version.encode(), len(patch_data), crc32) with open(output_path, 'wb') as f: f.write(header) f.write(patch_data)

这样，最终发给设备的是patch_v1.0_to_v1.1_with_header.bin。Bootloader会先解析这个头，确认类型是“差分包”(0x02)，然后才把后面的数据交给mcu_bspatch函数处理。

5.2 设备端：Bootloader的升级处理流程

现在，我们来完善第3章里留下的process_upgrade_package()函数。假设升级包已经通过串口Ymodem（或HTTP、MQTT等）下载到了“下载缓冲区”。

static void process_upgrade_package(void) { image_header_t header; uint8_t* download_buffer = (uint8_t*)DOWNLOAD_BUFFER_START; // 1. 从下载缓冲区起始位置读取镜像头 memcpy(&header, download_buffer, sizeof(image_header_t)); // 2. 验证魔数、CRC等 if (header.magic != IMAGE_MAGIC) { printf("Error: Invalid image magic.\r\n"); return; } if (!verify_crc(&header, download_buffer + sizeof(header))) { printf("Error: Image CRC mismatch.\r\n"); return; } // 3. 根据镜像类型分派处理 switch(header.image_type) { case IMAGE_TYPE_FULL: // 全量升级包 flash_erase(APPLICATION_START_ADDRESS, header.data_len); flash_write(APPLICATION_START_ADDRESS, download_buffer + sizeof(header), header.data_len); break; case IMAGE_TYPE_DIFF: // 差分升级包 { uint8_t* patch_data = download_buffer + sizeof(header); uint32_t patch_len = header.data_len; // 3.1 将当前应用程序区的内容作为“旧固件”读出来 // 注意：为了安全，最好先备份到下载缓冲区的另一块区域，防止操作中断。 uint8_t* old_app = (uint8_t*)malloc(OLD_APP_SIZE); memcpy(old_app, (void*)APPLICATION_START_ADDRESS, OLD_APP_SIZE); // 3.2 在下载缓冲区腾出一块空间，用于存放bspatch生成的新固件 uint8_t* new_app_buffer = download_buffer + sizeof(header) + patch_len + 1024; // 留点余量 // 3.3 调用我们千辛万苦移植好的函数 int ret = mcu_bspatch(old_app, OLD_APP_SIZE, patch_data, patch_len, new_app_buffer); free(old_app); if (ret != 0) { printf("bspatch failed: %d\r\n", ret); return; } // 3.4 将合成的新固件写入应用程序区 flash_erase(APPLICATION_START_ADDRESS, header.new_image_size); // 头里需要包含新固件大小 flash_write(APPLICATION_START_ADDRESS, new_app_buffer, header.new_image_size); } break; default: printf("Error: Unknown image type.\r\n"); break; } // 4. 验证新写入的应用程序（可选，但推荐） if (verify_application(APPLICATION_START_ADDRESS)) { printf("Upgrade successful!\r\n"); // 更新状态标志区，标记升级成功 write_upgrade_status(STATUS_UPGRADE_COMPLETE); } else { printf("Upgrade verification failed!\r\n"); // 标记升级失败，可能触发回滚机制（进阶话题） } }

5.3 实战：通过串口Ymodem进行升级

对于开发和调试，串口Ymodem是最直接的方式。我们可以利用像SecureCRT、Xshell或开源的lrzsz工具。在Bootloader的命令行模式下，实现一个ymodem命令：

1. Bootloader启动后，如果没有有效APP，进入命令行。
2. 用户输入ymodem download。
3. Bootloader通过串口发送Ymodem协议起始字符（如‘C’）。
4. 用户在终端选择要发送的、带镜像头的差分包文件。
5. Bootloader按Ymodem协议接收数据，存入“下载缓冲区”，并实时计算CRC校验。
6. 接收完成后，自动设置状态标志，并重启。重启后Bootloader检测到有新包，自动触发上述process_upgrade_package()流程。

这个过程非常直观，是前期测试和演示的利器。我在项目初期，就是通过这种方式，一遍遍验证bspatch的合成是否正确的。

6. 进阶优化与避坑指南

做到上面那一步，一个可用的差分升级Bootloader已经成型了。但想让它更健壮、更实用，还需要考虑更多。

6.1 安全性与可靠性设计

• 升级包验签：仅仅校验CRC是不够的，为了防止恶意固件被刷入，必须进行数字签名验证。可以在镜像头里加入RSA或ECC签名，Bootloader端集成对应的验签算法（如TinyCrypt）。虽然增加了一些代码体积，但对于安全要求高的设备是必须的。
• 断电保护与断点续传：在状态标志区详细记录升级阶段（如：开始擦除、开始写入、校验中等）。万一升级中途断电，重启后Bootloader能根据状态决定是继续、回滚还是放弃。对于差分升级，尤其要保护好“旧固件”的备份，确保合成过程可恢复。
• 回滚机制：升级后，如果新APP无法正常启动（比如启动后5秒内没有给Bootloader发送“心跳”信号），Bootloader应能自动回滚到上一个已知的好版本。这通常需要在Flash里多备份一份之前的固件。

6.2 性能与资源平衡

• 差分包大小的权衡：bsdiff生成的包虽然小，但bspatch合成时需要内存和CPU时间。对于低速MCU（如Cortex-M0），合成一个几百KB的固件可能需要几秒到十几秒。要测试这个时间是否在设备可接受的“重启升级时间”内。
• Flash寿命：频繁的擦写会损耗Flash。要优化升级流程，尽量减少不必要的擦除操作。例如，差分升级时，如果确认新固件合成成功，再一次性擦除旧程序区并写入，而不是边合成边写入。

6.3 调试技巧与常见问题

• 丰富的日志输出：在Bootloader的各个关键节点（开始升级、解析头、开始bspatch、写入Flash、跳转前）都通过串口打印信息。这是你调试时最重要的眼睛。
• 模拟测试：在PC上，用单元测试模拟整个流程：读取旧bin、旧bin打补丁生成新bin、比较新bin和真实新bin是否完全一致。这能极大提高开发效率，避免每次测试都烧录芯片。
• 地址对齐：STM32的Flash编程通常要求64位或128位对齐，擦除以扇区为单位。务必确保你的写入地址和长度都符合硬件要求，否则会导致编程失败。
• 中断处理：Bootloader中如果使用了中断，在跳转到APP前一定要妥善关闭或转移。一个干净的跳转是成功的一半。

7. 把这一切变成你的项目

纸上得来终觉浅，绝知此事要躬行。我强烈建议你按照这个指南，从创建一个最简单的、只能跳转的Bootloader开始，然后一步步添加功能：先实现全量升级，再啃下bspatch移植这块硬骨头，最后完善整个流程。

你可以参考我当年学习时借鉴的一些优秀开源项目，比如MCUboot，它是一个工业级的开源安全Bootloader，支持差分升级（使用TLV格式和自定义的差分算法），其代码结构和设计思想非常值得学习。当然，MCUboot功能庞大，直接用在STM32上可能需要裁剪。我们的这个实战指南，可以看作是一个高度定制化、聚焦于bsdiff的简化版实现。

最后，嵌入式开发没有银弹。你的设备通信方式（4G/Wi-Fi/蓝牙）、Flash类型（内部/外部SPI Flash）、安全要求、成本约束，都会影响最终方案的选择。但只要你理解了Bootloader的分区设计、差分升级的原理、以及bspatch集成的关键点，你就拥有了解决这个问题的核心能力。剩下的，就是根据你的具体场景，做调整和优化了。希望这篇长文能帮你少走些弯路，祝你一次点亮，升级顺利！