简介面向中高级嵌入式开发者的STM32 UART双APP IAP升级完整工程资源讲解如何基于UART实现双APP区固件在线更新帮助理解IAP应用程序内编程原理。包体共272个文件以150个.h头文件与78个.c源文件为主另有11个.bin固件、6个.ld链接脚本及STM32CubeMX配置.ioc等整体仅1.86MB结构紧凑。附带的bin固件含多个版本号便于烧录验证升级流程。已有1716人浏览学习。工程不仅提供可直接烧录的双APP固件还包含完整源码与链接脚本便于二次开发开发者可借此通过UART、4G/WiFi模块或U盘/TF卡等通信接口升级固件为OTA/OTG升级提供落地参考。 这个工程包的名字一看就很典型——STM32 UART双APP的IAP。前阵子刚好帮客户调过一套类似的方案从Bootloader设计到双分区切换再到串口协议联调踩了不少坑。今天就把这套东西掰开揉碎讲清楚项目本身不算复杂但里面藏着的细节足够让新手在原地转三天。如果你正准备做串口升级、远程固件更新或者被IAP跳转后卡死折磨过这篇应该能帮你省下不少时间。1. 项目定位与双APP升级方案的整体设计1.1 双APP方案到底解决了什么问题先明确一个概念这里说的双APP不是指Bootloader加一个APP而是Bootloader加两个独立的APP分区。常见的IAP方案是Bootloader加单APP升级时把新固件直接覆盖到APP区万一写入过程中断电或者固件传输出错板子就真成砖了只能拿下载器重新烧。双APP方案的核心价值就是解决这个变砖焦虑。双APP的机制可以理解为A/B分区也叫备份升级、回滚升级。两份APP固件分别放在两个独立的Flash区域Bootloader通过标志位或者状态字来决定从哪个分区启动。正常情况下运行A区升级时把新固件写入B区写完校验通过再切换启动标志下次启动就跑B区。如果B区校验失败或者运行不起来Bootloader自动退回A区设备依然可用。这个思路在实际项目里非常实用。我之前做过一个现场设备客户分布在各地固件升级全靠串口以前单APP方案只要断电一次就得出差救砖换成双APP之后再也没有这种烦恼。对于需要长期稳定运行、升级链路不可靠的产品这套机制几乎是标配。1.2 双APP IAP的启动流程与分区规划整个系统的启动链路大概是这样的上电后Bootloader先跑起来读取参数区的状态标志判断当前应该启动哪个APP。如果标志正常校验对应分区的跳转条件比如栈顶地址合法、固件CRC通过直接跳转执行如果跳转条件不满足或者升级标志要求切换就进入升级流程等待数据。Flash分区的规划直接决定了这套方案能不能落地。以STM32F103系列为例我通常按下面的方式切分分区起始地址大小说明Bootloader区0x0800000032KB启动、升级、回滚逻辑APP_A区0x0800800032KB正常运行区APP_B区0x0801000032KB备份/待升级区参数区0x0801F8002KB启动标志、升级标志、版本号不同芯片的Flash大小不一样但核心思路不变Bootloader必须独立占一块两个APP各占一块参数区单独留出来。这里有个容易忽略的点——Bootloader区不能只按当前代码大小来分一定要留足余量。后面升级加功能时Bootloader代码也会膨胀如果分区卡得太死改一次就得重新规划整个内存布局牵扯到所有地址。启动标志的设计也很有讲究我用的是一个结构体包含两个魔法数、当前启动分区编号、升级目标分区编号、尝试次数等字段。每次启动都校验魔法数防止Flash内容被意外擦除后进入未知状态。有了这个参数区回滚逻辑就有了可靠的判断依据。2. 串口升级协议的细节设计2.1 为什么选择UART作为升级通道很多人在选升级通道时会纠结SPI、I2C、CAN、以太网都能做为什么这里选UART答案很简单通用性。UART几乎是所有MCU的标配外设不需要额外硬件一根USB转串口线就能和电脑连上现场维护人员的操作门槛最低。UART的波特率选择要权衡速度和稳定性。115200是最常见的Flash写入速度能跟上传输1MB固件大约需要90秒如果现场环境干扰大或者线比较长降到57600甚至19200更稳。我做过一个产品用9600波特率线长超过2米实测也稳定但升级速度确实捉急。核心原则是速度够用就行别盲目追求快。还有一个实操细节USB转串口芯片的驱动问题太常见了。FT231X、FT232R这类芯片如果在电脑上显示感叹号基本是驱动版本和系统不匹配。我在工程里附加了驱动安装说明让现场人员先确认设备管理器里COM口号正常再打开升级工具省得排查半天发现在最底层翻车。2.2 帧结构设计与状态机串口升级协议不建议搞得很复杂但基本的帧格式必须有否则接收方根本没法判断一帧数据从哪里开始、到哪里结束、有没有出错。我常用的帧结构长这样字段长度说明帧头2字节固定0xAA 0x55命令字1字节握手/数据/结束/应答数据长度2字节小端模式数据域N字节固件分块数据CRC162字节校验数据域帧尾1字节0x0D 0x0A命令字我定义了几类0x01握手请求、0x02握手应答、0x03数据帧、0x04结束帧、0x05升级成功标志、0x06错误应答。固件数据按256字节一帧拆分每帧都带独立的CRC16校验接收方校验通过才回ACK校验失败回NACK发送方超时未收到ACK就重传当前帧。状态机是这套协议的核心我把它分成几个状态等待握手、接收数据、等待结束帧、校验固件、更新标志。状态转换条件清楚代码也容易维护。这里有个经验不要在中断回调里做复杂的协议解析只做字节接收和环形缓冲区写入主循环里再按状态机逐帧解析逻辑清晰也不容易出错。2.3 双APP场景下的升级回滚策略搞清楚了协议再看双APP和协议怎么配合。升级流程通常是这样的上位机先发握手命令Bootloader应答后进入接收模式接着按帧发送固件数据。所有帧都收完后Bootloader先对比CRC校验值和固件长度——这两个信息在握手阶段就已经传递过来——全部通过再更新启动标志最后跳转到新APP。回滚策略的关键在于新APP是否真正可用这个判断。我是这样设计的切换前把尝试次数计数器加一如果新APP在启动后成功运行并主动清除尝试次数说明升级成功如果新APP启动后异常复位下次Bootloader发现尝试次数非零就认定新固件不可用自动回滚到另一个分区同时把计数器清零。这里有一个反馈环需要APP配合APP在main函数开头调一个接口通知Bootloader我已经正常运行了Bootloader才能确认升级有效。否则即使APP跑起来但如果里面逻辑有问题导致看门狗不断复位Bootloader不知道还会一直从坏分区启动。不要觉得这部分多余实际现场出问题最多的地方往往就在这里。3. 核心代码实现与踩坑记录3.1 Bootloader跳转前必须做的清理跳转这块是很多人的噩梦代码本身没几行但顺序错了就是起不来。我贴一个简化但完整的跳转函数typedef void (*pFunction)(void); void jump_to_app(uint32_t app_addr) { uint32_t app_stack_addr *(volatile uint32_t *)app_addr; pFunction app_entry (pFunction)(*(volatile uint32_t *)(app_addr 4)); if ((app_stack_addr 0x2FFE0000) ! 0x20000000) { return; /* 栈顶地址不合法拒绝跳转 */ } __disable_irq(); /* 关闭全局中断 */ HAL_UART_DeInit(huart1); /* 反初始化外设 */ HAL_RCC_DeInit(); /* 恢复时钟到默认状态 */ SysTick-CTRL 0; SysTick-LOAD 0; SysTick-VAL 0; __set_MSP(app_stack_addr); /* 设置主栈指针 */ app_entry(); /* 跳转到APP入口 */ }跳转前的清理是重点。关中断是为了防止跳转过程中有中断触发然后跑进了Bootloader的中断处理函数导致系统崩溃反初始化外设是防止外设状态残留干扰APP恢复时钟很重要因为Bootloader里可能把PLL配到72MHzAPP初始化时会重新配置时钟两个阶段的时钟配置不衔接会出问题。有些经验不足的开发者会在跳转前调用HAL_DeInit之类的一堆函数把外设全部复位一遍。实际上只需要确保和你Bootloader里初始化过的外设反初始化尤其是UART、定时器和DMA。反初始化之后才能保证复位状态干净。3.2 跳转后卡死的真正根源IAP跳转后卡死这几乎是每个做IAP的人都会遇到的现象最典型的是程序跑到了APP的main函数但Hal_Delay一调用就死机。这个问题本质上牵扯到两个点SysTick和中断向量表。先说SysTick。HAL库的HAL_Delay依赖SysTick中断来计时。如果Bootloader里把SysTick关了APP里没有重新初始化HAL_Delay自然就卡死。但还有另一种隐蔽情况Bootloader里SysTick中断一直在跑跳转时没有关干净APP初始化时又去配置SysTick两边优先级打架中断进不去也出不来。解决方法是跳转前把SysTick彻底停掉代码里已经写了然后在APP的main函数里重新初始化SysTick并且把中断优先级分组设置成和Bootloader一致。再说中断向量表。Cortex-M3/M4的中断向量表默认放在0x08000000如果把APP放在0x08008000跳转之后中断来了硬件还是从0x08000000取中断处理函数地址拿到的是Bootloader的向量表APP里配置的中断永远触发不了。解决办法是在APP的main函数最前面重映射向量表SCB-VTOR APP_BASE_ADDRESS;对于STM32F103来说基地址是0x08000000APP_BASE_ADDRESS要按实际分区地址对齐。通常设置完之后再把所有外设中断重新初始化一遍系统就能正常跑了。这两个坑一填上跳转后的卡死问题基本就消失。3.3 Flash写入与双APP切换的代码骨架Flash写入这块有一些固定的注意事项。STM32的Flash必须以页为单位擦除写的时候可以按16位或32位写入但写入前必须确保目标地址已经擦除过。常用的写入函数大概长这样void flash_write_buffer(uint32_t addr, uint8_t *buf, uint32_t len) { FLASH_EraseInitTypeDef erase_cfg; uint32_t page_error 0; uint32_t num_pages (len FLASH_PAGE_SIZE - 1) / FLASH_PAGE_SIZE; erase_cfg.TypeErase FLASH_TYPEERASE_PAGES; erase_cfg.PageAddress addr; erase_cfg.NbPages num_pages; HAL_FLASH_Unlock(); HAL_FLASHEx_Erase(erase_cfg, page_error); for (uint32_t i 0; i len; i 4) { uint32_t word *(uint32_t *)(buf i); HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, addr i, word); } HAL_FLASH_Lock(); }擦除之前还有一个关键检查要做如果目标区域已经有有效数据直接擦除可能导致升级过程中断电就丢失旧固件。所以我通常把写入流程设计成先擦除待升级分区再逐帧写入全部完成并校验通过后才修改启动标志。如果中途断电另一个分区的旧固件还是完好的Bootloader发现标志未更新继续从旧分区启动这就是双APP方案最理想的保障。双分区切换的核心逻辑其实就是一个简单的标志判断。我在参数区存了当前启动分区和升级目标分区Bootloader每次启动都检查这些值然后决定从哪个地址跳转。代码上没有太多花样真正常出问题的是参数区本身的读写保护比如意外进入写保护状态导致升级永久失败排查起来很隐蔽。3.4 Keil工程配置IROM1偏移是关键一步Flash分区规划好了代码写好了还差最后一步让编译器按正确的地址生成固件。这一步在Keil MDK里很容易被忽略。两个APP工程在Options for Target的Target选项卡里IROM1的起始地址必须和实际分区地址一致。APP_A的IROM1设为0x08008000Size设为0x8000APP_B设为0x08010000Size也是0x8000。IRAM1保持默认的0x20000000起始即可。如果IROM1地址设置错误程序编译能通过链接也能通过但生成的bin文件地址就是错的下载到板子上要么完全跑不起来要么跑起来后中断全乱。我早期调IAP时在这个问题上耗了半天最后用ST-LINK Utility把Flash内容读回来一对比才发现地址全乱了。生成bin文件的方法也值得说一句。Keil里在User选项卡的After Build/Rebuild里加一行调用fromelf.exe --bin -o $LL.bin #L这样编译完自动生成bin文件省的每次手动用工具转换。注意fromelf.exe的路径要在Keil安装目录下不同版本的路径可能有差异。4. 调试与排查从升级失败到安全降落4.1 常见问题速查表把这段时间遇到过的坑整理成一张表方便你排查时对照现象可能原因排查方向跳转后程序跑飞中断向量表没有重映射检查APP里SCB-VTOR设置跳转后HAL_Delay卡死SysTick没有重新初始化检查跳转前是否彻底关闭SysTick串口收不到数据USB转串口驱动异常设备管理器看COM口是否正常握手成功但数据帧CRC全错波特率不稳定或线材过长降低波特率检查线缆质量Flash写入后校验失败写入地址越界或未擦除检查分区地址和擦除逻辑升级完成后还是旧程序启动标志没有正确更新检查参数区写入是否成功反复重启无法进入APP看门狗在APP里没有及时喂确认APP启动后看门狗初始化顺序升级中途断电再上电变砖单APP方案没有回滚能力切换到双APP架构4.2 调试工具与升级联调的经验联调阶段用好工具能事半功倍。ST-Link Utility是最基本的可以查看整片Flash内容升级完成后把两个分区的数据读出来对照源文件能快速确认写入是否正确。J-Flash也能读bin文件但我个人觉得ST-Link Utility对STM32更顺手。还有一个很容易被忽略的工具是串口打印。Bootloader阶段加一个简单的日志输出把关键节点信息打出来——从哪个地址启动、升级了多少帧、校验结果是什么——调试效率提升不止一个档次。我在Bootloader和APP里都加了日志开关正式发布时默认关闭需要时通过编译宏打开。实际联调时我建议按这个顺序走先用ST-Link把Bootloader和旧版APP烧进去确认首次上电能正常从APP启动然后打开升级工具发送一个新版固件进去升级完成后确认程序切换到了新分区最后主动断电再上电确认Bootloader还能从正确分区启动。三步都通了再考虑加各种异常场景。4.3 现场升级的流程设计与体验现场升级的体验往往决定了这套方案能不能被接受。系统设计成上电后等待1秒如果上位机发来升级请求就进入Bootloader升级模式否则直接启动APP。配合按键的话可以做成按住某个按键上电强制进入升级模式两种方式都保留灵活应对不同场景。升级过程中加一个状态LED未连接时慢闪升级中快闪完成后常亮。别小看这个细节现场升级时用户能直观看到进度不会以为死机了去断电减少不必要的风险。还有一点要提醒如果产品里同时有应用固件和字库之类的独立数据块升级协议里最好把数据块也纳入升级流程否则现场更换固件版本时数据不匹配一样会出现莫名其妙的问题。5. 写在最后的一点体会这套双APP IAP方案我在两个量产项目里跑过了最大的感触是协议设计不要太复杂但Flash分区规划和标志位设计一定要想清楚这两部分是整个系统的地基。升级回滚能力看起来是多写了不少代码但它在现场帮你避免的灾难性故障完全值回这些工作量。如果你正在调IAP并且卡在某个细节上建议先别急着翻库函数手册先把跳转路径捋一遍——从哪里来、经过哪里、到哪里去三个节点的状态搞清楚了问题往往就自然暴露了。本文还有配套的精品资源点击获取