STM32F103 HAL库实战：IAP固件升级全流程解析-育师

1. 为什么你的产品需要IAP？从“板砖”到“智能”的蜕变

我做了这么多年嵌入式开发，最怕的就是产品出厂后软件出问题。早年我们做智能家居的温控器，有一次发现算法有个小bug，会导致温度控制偶尔失灵。你猜怎么着？我们只能让客户把设备寄回来，工程师一个个用烧录器重新刷程序，那场面简直是一场灾难，成本高、效率低，客户体验更是差到极点。后来我们开始用IAP技术，同样的问题，通过设备自带的Wi-Fi模块，后台推送一个新固件包，用户啥也不用管，睡一觉设备就自己更新好了。这就是IAP（In Application Programming，在应用编程）的魅力——让你的硬件产品从“一锤子买卖”变成可以持续成长、远程修复的智能设备。

对于STM32开发者来说，IAP不是一个遥不可及的高深技术，它更像是一个必备的生存技能。尤其是使用像STM32F103这类经典芯片的项目，产品生命周期长，后期功能升级、漏洞修复是常态。很多新手朋友一听到要动Flash分区、改中断向量表就头大，觉得是芯片厂商或者RTOS才该操心的事。其实不然，用HAL库来操作，整个流程可以被拆解得非常清晰。简单来说，IAP就是在你的Flash里划出两块地：一块地住着一位永远醒着的“守门人”（Bootloader），另一块地住着干活的“工人”（APP）。平时工人干活，一旦需要升级，守门人就会接收新的工人（新固件），把他领到工人的住处安顿好，然后让他接着干活。你不需要每次都把芯片拆下来用烧录器，通过网络、串口、USB，甚至蓝牙，都能完成这个“交接班”的过程。

这篇文章，我就以最经典的STM32F103C8T6（俗称“蓝莓派”）为例，手把手带你用HAL库实现一个通过串口升级的IAP方案。我会把我在实际项目中踩过的坑、总结的技巧都揉碎了讲给你听，目标是让你看完就能在自己的板子上跑起来。我们不光讲原理，更侧重实战，代码都是经过项目验证的，你可以直接拿去用或者修改。放心，过程没你想的那么复杂。

2. 动手之前：彻底搞懂IAP的底层运行逻辑

很多教程一上来就让你改地址、写代码，但如果你没理解STM32启动和运行的本质，后面出问题绝对会一头雾水。我这里用最直白的方式给你捋一捋。

想象一下，STM32的Flash（从0x0800 0000开始）就是一栋大楼，里面住着程序。芯片一上电，CPU这个“管家”会机械地跑到这栋楼的0x0800 0004这个房间门口，看看门上贴的纸条（复位中断向量）。纸条上写着一个地址，告诉管家“复位中断服务程序”在哪个房间。管家就跑去那个房间执行复位程序，完事了之后，纸条上又指示了“main函数”的房间号，管家就跑去main函数房间开始干活。main函数通常是个大循环，一直运行。如果这时有客人敲门（中断发生），管家会立刻放下手里的活，再次跑回0x0800 0004这个总服务台，根据不同的客人类型（中断源），查看对应的服务房间号（中断向量），然后跑去处理。处理完了，再回到main函数房间继续循环。

那么，加入IAP后，这栋楼的结构变了。我们把这栋楼分成两户：Bootloader（守门人）住在一楼（0x0800 0000开始），APP（工人）住在二楼（比如从0x0800 4000开始）。每户人家都有自己的“总服务台”（中断向量表），分别放在自己家的门口。

芯片上电，管家依然习惯性地跑到整栋楼的原总服务台（0x0800 0004），但这次这个服务台是属于一楼Bootloader的。所以管家执行的是Bootloader的复位程序，然后进入Bootloader的main函数。在这个函数里，Bootloader会检查：“有没有新工人（新固件）要来？”如果没有，它就走到楼梯口，对着二楼喊：“工人，起来干活了！”然后通过一个跳转指令，把管家的指引权交给二楼APP的中断向量表。从此，管家就只在二楼活动了，main循环是APP的，中断来了也是去二楼自家的服务台查表。

这里有两个至关重要的技术点，是成败的关键：

APP的起始地址必须偏移：你不能让APP也住在0x0800 0000，那就和Bootloader打架了。必须定义一个偏移量，比如0x4000。
中断向量表必须重定位：APP搬了新家，它的“总服务台”（中断向量表）也得跟着搬到新家的门口（0x0800 0000 + 偏移量）。否则，中断发生时，管家跑回一楼的服务台，就找不到对应APP的中断处理程序了。在HAL库工程里，这个操作非常简单，通常只需要在IDE的配置中修改一个链接脚本参数，或者在代码里设置一个寄存器（SCB->VTOR）。

我见过不少朋友Bootloader能跳转到APP，但APP一开中断就死机，十有八九就是第二个问题没处理好。理解了这个“大楼-管家-服务台”的模型，后面的代码编写就是按图索骥了。

3. 打造可靠的Bootloader：不仅仅是数据搬运工

Bootloader是IAP系统的基石，它的稳定性和健壮性直接决定了升级的成败。一个好的Bootloader不能只是个简单的数据搬运工，它需要具备错误处理、超时机制、完整性校验和安全的跳转逻辑。

3.1 工程配置与内存划分

首先，我们为Bootloader创建一个独立的STM32CubeIDE或者Keil工程。关键的第一步是告诉编译器：“我们这个程序只占用Flash开头的一小块地方”。

修改链接脚本（.ld文件或分散加载文件）：将Flash的起始地址设置为0x0800 0000，长度根据你的需要设置。对于STM32F103C8T6（64KB Flash），我通常给Bootloader分配16KB（0x4000字节）空间，这足够实现一个功能丰富的串口Bootloader了。所以，Bootloader的Flash区域就是0x0800 0000 ~ 0x0800 3FFF。APP的起始地址自然就是0x0800 4000。

在代码中定义APP地址：在bsp_iap.h中，我们需要明确定义这个分界点。

// bsp_iap.h #define FLASH_BASE 0x08000000 #define BOOTLOADER_SIZE (16 * 1024) // 16KB #define APP_START_ADDR (FLASH_BASE + BOOTLOADER_SIZE) // 0x08004000 #define APP_FLASH_MAX_SIZE (64 * 1024 - BOOTLOADER_SIZE) // 剩余空间给APP

3.2 核心代码解析：写入、校验与跳转

Bootloader的主循环逻辑很简单：初始化外设（如串口）-> 检查升级标志 -> 等待/接收固件 -> 写入Flash -> 校验 -> 清除标志 -> 跳转。我们重点看几个核心函数。

固件写入函数IAP_Write_App_Bin：这个函数负责将接收到的二进制数据（BIN文件）写入到指定的Flash地址。这里有个细节，STM32的Flash写入必须以半字（16位）、字（32位）为单位，并且写入前必须先擦除（擦除以页为单位，F103一页是1KB或2KB）。原始文章中的函数已经实现了带擦除的写入，但我们可以让它更健壮。

// bsp_iap.c (优化版) HAL_StatusTypeDef IAP_Write_App_Bin(uint32_t ulStartAddr, uint8_t *pData, uint32_t ulLen) { uint32_t i; uint32_t write_addr = ulStartAddr; uint32_t sector_error = 0; FLASH_EraseInitTypeDef erase_init; // 1. 地址合法性检查（非常重要！） if (ulStartAddr < APP_START_ADDR || ulStartAddr >= (FLASH_BASE + 64*1024) || (ulStartAddr + ulLen) > (FLASH_BASE + 64*1024)) { return HAL_ERROR; } // 2. 解锁Flash HAL_FLASH_Unlock(); // 3. 计算需要擦除的页 uint32_t first_sector = (ulStartAddr - FLASH_BASE) / FLASH_PAGE_SIZE; uint32_t num_sectors = (ulLen + FLASH_PAGE_SIZE - 1) / FLASH_PAGE_SIZE; // 向上取整 erase_init.TypeErase = FLASH_TYPEERASE_PAGES; erase_init.PageAddress = FLASH_BASE + first_sector * FLASH_PAGE_SIZE; erase_init.NbPages = num_sectors; if (HAL_FLASHEx_Erase(&erase_init, &sector_error) != HAL_OK) { HAL_FLASH_Lock(); return HAL_ERROR; // 擦除失败 } // 4. 以字（32位）为单位写入，效率更高 uint32_t *p_word = (uint32_t*)pData; uint32_t word_len = ulLen / 4; for (i = 0; i < word_len; i++) { if (HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, write_addr, p_word[i]) != HAL_OK) { HAL_FLASH_Lock(); return HAL_ERROR; // 写入失败 } write_addr += 4; } // 处理可能剩余的字节（不足4字节） // ... (略，可用半字编程) // 5. 上锁Flash HAL_FLASH_Lock(); return HAL_OK; }

我强烈建议加入返回值判断，并在每个关键步骤（擦除、写入）后都进行错误处理。在实际项目中，我还会在写入完成后，立刻读回数据进行比较，做一次完整性校验，确保数据万无一失。

应用程序跳转函数IAP_ExecuteApp：这是魔法发生的地方。它的作用是把CPU的执行权交给APP。原理是模拟一次“复位”后的CPU行为：设置主栈指针（MSP）到APP区域的第一个字，然后跳转到APP复位向量（第二个字）指向的地址。

// bsp_iap.c typedef void (*pFunction)(void); // 定义函数指针类型 void IAP_ExecuteApp(uint32_t app_addr) { pFunction jump_to_app; uint32_t app_stack_pointer; // 1. 检查APP栈顶地址是否合法（在RAM范围内） app_stack_pointer = *(volatile uint32_t*)app_addr; if ((app_stack_pointer & 0x2FFE0000) != 0x20000000) { // 栈顶地址非法，可能APP区域是空的或损坏 // 这里可以触发错误处理，比如长亮LED或重启 Error_Handler(); return; } // 2. 关闭所有中断！这是跳转前必须做的 __disable_irq(); // 3. 设置主栈指针为APP的栈顶 __set_MSP(app_stack_pointer); // 4. 获取APP的复位中断服务程序地址（复位向量） jump_to_app = (pFunction)*(volatile uint32_t*)(app_addr + 4); // 5. 设置向量表偏移寄存器（VTOR）到APP的向量表 // 对于Cortex-M3，这个寄存器在SCB模块中 SCB->VTOR = app_addr; // 6. 跳转到APP jump_to_app(); // 跳转后，这里的代码永远不会执行 }

注意第2步和第5步：__disable_irq()至关重要，防止在跳转过程中被中断打断，导致状态混乱。设置SCB->VTOR是让CPU知道APP的中断向量表已经搬家了，以后中断来了就去新的地址查表。原始文章的代码有时会漏掉这一步，导致APP无法正常响应中断。

4. 改造你的APP：让它“认得回家的路”

Bootloader准备好了，APP也得配合搬家。APP工程需要做两处关键修改，让它知道自己不是从0x0800 0000启动的。

4.1 修改APP工程的存储器配置

这步是在IDE中完成的，目的是让编译器/链接器把代码和数据放到我们为APP预留的Flash区域（例如0x0800 4000开始）。

在Keil MDK中：打开Options for Target->Target选项卡，将IROM1的起始地址Start改为0x08004000，大小Size改为剩余的空间（如0xC000代表48KB）。
在STM32CubeIDE中：在.ld链接脚本文件中，修改FLASH区域的ORIGIN和LENGTH。同时，你需要修改vector table的定位。更简单的方法是使用CubeMX生成代码时，在Project Manager->Linker Settings中，直接修改Flash的起始地址和大小。

4.2 在APP的SystemInit中重定位中断向量表

仅仅修改了链接地址还不够，程序运行时还需要告诉内核中断向量表的新位置。通常我们在main()函数最开始，调用HAL_Init()之后，就做这件事。

// main.c (APP工程) int main(void) { // HAL库初始化 HAL_Init(); /* 重设向量表偏移量到APP的起始地址 */ // 方法一：直接操作寄存器（通用） SCB->VTOR = FLASH_BASE | 0x4000; // 假设APP起始于0x08004000 // 方法二：使用HAL库提供的宏（如果HAL库版本支持） // __HAL_SYSCFG_REMAPMEMORY_FLASH(); // 这个通常是用于重映射到别处，不适用 // 更常见的做法是直接设置VTOR，如方法一。 // 后续的系统时钟配置、外设初始化等 SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); // ... while (1) { // 你的应用代码 } }

有些教程会告诉你在system_stm32f1xx.c文件的SystemInit()函数里修改VECT_TAB_OFFSET，这当然也可以。但我更喜欢在main里做，因为这样更清晰，而且SystemInit通常是在startup文件里早于main被调用的，有时顺序上需要注意。在main最开始设置，能确保在初始化任何可能使用中断的外设之前，向量表已经就位。

4.3 生成可供传输的BIN文件

最后，我们需要从APP工程生成一个纯二进制（BIN）文件，而不是默认的ELF或HEX文件，因为Bootloader需要处理的就是最原始的二进制数据。

Keil MDK：Options for Target->User选项卡，在After Build/Rebuild部分，勾选Run #1，并填入：fromelf --bin --output=@L.bin !L。这样编译后会在工程目录生成一个.bin文件。
STM32CubeIDE (GCC ARM)：在Project Properties->C/C++ Build->Settings->Tool Settings->MCU Post build outputs中，勾选Convert to binary file (-O binary)。编译后会在Debug或Release文件夹找到.bin文件。

这个.bin文件，就是你要通过串口、网络等方式发送给Bootloader的“新工人”。

5. 串口通信协议与上位机：让升级流程更稳健

Bootloader和上位机（比如你的电脑）之间需要一套简单的通信协议来握手、传输数据和校验。一个健壮的协议能极大提高升级成功率。

5.1 设计一个简单的帧协议

我们不能简单地把BIN文件一股脑地丢给单片机。我设计一个简单实用的协议帧格式，你可以参考：帧头（2字节）+命令字（1字节）+数据长度（2字节）+数据（N字节）+CRC16校验（2字节）+帧尾（2字节）

帧头帧尾：用于在串口数据流中识别一帧的开始和结束，例如用0xAA 0x55和0x55 0xAA。
命令字：定义不同的操作，比如0x01握手、0x02开始传输、0x03传输数据、0x04结束传输、0x05执行跳转。
CRC校验：这是必须的！我吃过亏，因为串口干扰导致数据传错一位，刷进去的程序跑不起来，查了半天才发现是传输问题。加上CRC后，Bootloader在收到每一帧数据时都计算校验和，不对就请求重发，可靠性大大提升。

在Bootloader中，你需要一个状态机来解析这个协议。通常状态包括：等待帧头、接收命令、接收长度、接收数据、校验、执行命令。

5.2 Bootloader中的协议处理与流控制

Bootloader的主循环大概长这样：

// main.c (Bootloader工程) int main(void) { HAL_Init(); SystemClock_Config(); MX_USART1_UART_Init(); MX_GPIO_Init(); // 可能用LED指示状态 // 检查是否需要升级（比如通过一个按键、Flash中的标志位） if (Check_Update_Flag() == UPDATE_REQUESTED) { // 进入升级模式 LED_Blink(FAST); // 快闪表示等待升级 UART_Send_String("Bootloader Ready\r\n"); while (1) { if (UART_Receive_Frame(&rx_frame) == HAL_OK) { switch (rx_frame.cmd) { case CMD_CONNECT: Send_Ack(CMD_ACK); break; case CMD_START: { // 解析文件总长度、CRC等元数据 total_len = Parse_Start_Cmd(rx_frame.data); Send_Ack(CMD_ACK); break; } case CMD_DATA: { // 将数据写入缓存，并更新接收进度 if (Write_Data_To_Flash_Buffer(rx_frame.data, rx_frame.len) == HAL_OK) { Send_Ack(CMD_ACK); } else { Send_Ack(CMD_NACK); // 请求重发 } break; } case CMD_END: { // 校验整个文件的CRC，与上位机发送的对比 if (Verify_Total_CRC() == HAL_OK) { // 将缓存数据正式写入APP区域 Flash_Program_App(); Send_Ack(CMD_SUCCESS); Set_Update_Flag(UPDATE_COMPLETE); // 设置标志，准备跳转 } else { Send_Ack(CMD_FAIL); } break; } case CMD_JUMP: // 清除升级标志，执行跳转 Clear_Update_Flag(); IAP_ExecuteApp(APP_START_ADDR); break; } } // 可以加入超时处理，比如30秒无操作则自动跳转APP if (timeout) { Clear_Update_Flag(); IAP_ExecuteApp(APP_START_ADDR); } } } else { // 无需升级，直接跳转到APP IAP_ExecuteApp(APP_START_ADDR); } // 理论上不会执行到这里 while (1); }

这个流程里，我加入了超时机制。这是为了防止升级过程意外中断（比如拔线）导致设备一直卡在Bootloader里。超时后自动尝试跳转旧的APP，至少保证设备还能用。

5.3 上位机工具的选择与使用

你可以用任何语言（Python、C#、QT等）编写一个简单的上位机。它的核心功能就是：打开串口 -> 读取BIN文件 -> 按协议分包发送 -> 等待并解析Bootloader的应答。

对于快速测试，我强烈推荐使用“串口助手+文件发送”功能。很多高级的串口助手（如XCOM、SSCOM）都支持直接发送BIN文件，并且可以设置分包大小（比如每包256字节）和发送间隔。你只需要在Bootloader里实现最基本的“收到一包，回一个ACK”的协议，就能完成升级。这是最快验证你Bootloader写入和跳转功能是否正常的方法。

当你的协议更复杂后，可以再用Python的pyserial库写个脚本，自动完成握手、发送、校验的全流程。我在实际项目中就这么干，非常灵活。

6. 进阶思考与避坑指南

做到前面几步，一个基本的IAP功能就已经实现了。但要想用在产品上，还需要考虑更多。

坑一：Bootloader自身的更新（Bootloader升级Bootloader）这是个高级话题。你的Bootloader也可能有bug需要修复。思路是：在Flash中划分第三块区域，存放新的Bootloader镜像。APP在运行时，通过某种方式（如收到特殊指令）将新Bootloader的数据写入这个区域。然后APP触发系统复位，在一个非常早期的初始化阶段（比如在SystemInit里，甚至用汇编在Reset_Handler里），将新Bootloader拷贝到0x0800 0000并跳转执行。这个过程风险极高，一旦失败设备可能变砖，所以必须有完整的备份和回滚机制，通常在产品成熟稳定后才考虑。

坑二：电源管理与看门狗升级过程中，最怕突然断电。对于重要的设备，可以考虑以下策略：

增加大电容：硬件上保证断电后还能维持几百毫秒的运行。
软件备份：采用A/B双备份系统。设备里永远保存两个APP（比如APP_A和APP_B）。Bootloader根据一个标志位决定运行哪个。升级时，把新固件写到非当前运行的那个区域，全部写完后，再修改标志位。这样即使升级中途断电，原来的APP仍然是完好的。
看门狗：在Bootloader和APP中都要合理使用看门狗。但在Bootloader进行Flash擦写操作时，必须暂时关闭独立看门狗（IWDG），因为擦写时间可能超过看门狗超时时间。可以使用窗口看门狗（WWDG）或者用定时器自己实现一个软狗。

坑三：Flash寿命与磨损均衡STM32F103的Flash典型擦写次数是1万次。如果产品需要频繁升级，比如一天几次，那就要小心了。虽然1万次看起来很多，但集中在某几个页反复擦写，也会导致该区域提前失效。对于需要频繁存储标志位或数据的情况（比如升级进度、设备状态），尽量使用EEPROM（外置或片内）或者将数据存放在Flash的不同页上轮换写入，实现简单的磨损均衡。

坑四：加密与安全如果你的固件有知识产权保护的需求，或者担心被恶意篡改，就需要在IAP流程中加入安全措施。

固件加密：上位机发送加密后的固件，Bootloader收到后先解密再写入。密钥可以存储在芯片的只读保护区域或安全芯片中。
固件签名验证：在固件末尾附加一个数字签名（比如RSA或ECC签名）。Bootloader在跳转前，先用公钥验证签名，只有验证通过的APP才被允许执行。这能有效防止恶意固件的植入。

实现一个稳定可靠的IAP功能，就像是给你的产品上了一道保险。第一次配置可能会觉得步骤繁琐，但一旦跑通，后续的开发和维护效率会得到质的提升。我最开始做的时候，也在向量表重定位和跳转那里卡了好几天，反复调试才搞明白。希望我上面分享的这些代码细节和避坑经验，能帮你少走些弯路。当你第一次通过串口，看着LED闪烁，然后程序自动更新并成功跳转运行的那一刻，那种成就感是非常棒的。