STM32F103 IAP升级实战：官方AN2557例程拆解与避坑指南

简介STM32F10x系列官方IAP升级程序面向嵌入式开发与维护人员提供基于Cortex-M3内核微控制器的在应用编程方案用户无需外部编程器即可通过串口完成固件更新与远程维护。压缩包共350个文件大小约1.63MB以C/H源文件、汇编启动文件、Keil与IAR工程文件及链接脚本为主覆盖从启动代码到应用层的主要模块方便直接对照工程进行二次开发。程序支持Ymodem协议传输固件可读取现有闪存内容并配合中断向量表重定位、闪存分区等机制为升级过程提供错误检测与稳定保障。工程包内包含AN2557相关参考配置适合正在搭建IAP引导程序或需要处理固件升级流程的开发者参考。该方案的常见使用场景包括产品量产时的固件灌装、设备现场升级与远程维护开发者可从中获得完整的串口IAP实现思路。目前已有622人学习下载适合熟悉STM32基础开发、希望进阶掌握Bootloader与固件更新技术的读者。 做单片机开发的人迟早要面对一个问题设备已经发出去了客户现场说程序要加功能怎么办派人出差刷写固件成本高得离谱让客户自己拿调试器烧客户不会也不放心。这时候Stm32F10x系列官方IAP升级程序就是最经典的解法。IAPIn-Application Programming让设备通过串口、CAN、USB这些现成接口在运行状态下完成固件自升级不用拆机不用调试器整个流程对操作人员的要求也极低。这篇文章我就拿STM32F103这个最普及的型号开刀把官方AN2557例程的工程结构、Flash分区、中断向量表、YMODEM协议这些核心东西全部拆开讲清楚再附上我自己移植和量产过程中踩过的坑。适合刚接触IAP的嵌入式新人也适合正在把IAP往产品里落地的老手参考。1. 项目价值拆解为什么盯着官方IAP例程不放1.1 IAP到底解决什么问题现场升级不再拆机IAP的核心思想是在设备里烧两段程序一段是Bootloader负责接收升级数据并写入Flash一段是真正的App应用代码负责干实际业务。设备上电后先跑Bootloader判断有没有升级需求没有就直接跳转到App执行。以后要升级只需要把新固件通过串口发过去重启之后设备就跑新程序了。我见过不少团队一开始自己写升级逻辑结果各种翻车有的把Flash擦写时序搞错有的忘了处理中断向量表升级一次死一次。其实ST官方早就把整套方案做成了一对现成的例程配套应用笔记AN2557代码量不大但该有的环节全都覆盖了。对绝大多数产品来说与其自己从零写不如先在官方例程基础上跑通再按产品需求做裁剪和加固。1.2 “官方”二字的价值文档、协议、代码都能兜底官方例程最大的优势不是代码写得有多华丽而是它把“正确性”替你验证过了。ST给的这套IAP方案默认走USART1使用YMODEM协议做文件传输Flash写入、擦除、跳转逻辑全部基于标准外设库实现。YMODEM是个带CRC校验的文件传输协议能传文件名、文件大小还支持128字节和1024字节两种包长比裸传裸收要可靠得多。另外这套例程对STM32F10x全系列F103、F105、F107等都做了兼容不同容量的Flash扇区大小也仔细处理过。你不需要自己翻几百页参考手册去看扇区结构代码里已经替你整理好了。这一点在量产项目中非常值钱因为代码出错可以改硬件上电变砖的代价可没人愿意承担。1.3 从标准外设库到Cube生态这一套还值得学吗我估计有人会问ST现在主推的是STM32CubeMX加HAL库标准外设库都停止维护了学这套老例程还有意义吗我的看法是对F103这个型号来说这套例程仍然是绕不开的参考。Cube生态里对应的东西叫X-CUBE-IAP是个基于HAL库的IAP扩展包支持F4、F7、L4这些后来的型号你下载X-CUBE-IAP之后可以找到不少新的示例工程。但对F1系列很多人还在用标准外设库维护存量产品AN2557这套例程的协议流程、Flash操作逻辑、跳转细节依然值得逐行读一遍。更重要的是你如果理解了这套老代码里的原理再去看X-CUBE-IAP会轻松很多。IAP这个东西的难点从来不在哪个库而在分区规划、中断向量表、通信协议稳定性和异常兜底这些知识是通用的。2. 核心原理看懂这三个点IAP就通了一半2.1 Flash分区给Bootloader和App划好地盘STM32F103的Flash从0x08000000开始容量根据型号从16KB到512KB不等。做IAP第一件事就是把这片空间切成几个区常见分区是Bootloader区、App区和预留数据区。Bootloader区放升级程序本身App区放业务代码中间最好留出一点空间不分配防止边界溢出互相踩踏。我举个例子假设芯片是STM32F103ZET6512KB FlashFlash起始0x08000000。Bootloader一般给16KB到32KB就足够了因为升级逻辑本身不复杂加上协议和串口驱动也就几KB。App区从0x08004000偏移16KB或0x08008000偏移32KB开始剩下的空间全部给App。如果还想做“先下载到暂存区校验通过后再搬移”的安全策略还得专门留一个备份区。分区起始地址大小用途Bootloader0x0800000016KB~32KB引导、接收升级包、Flash写入App0x08004000或0x08008000剩余Flash的前大部分业务应用代码备份区/参数区Flash末尾可选暂存升级包、保存版本号等参数分区大小这里面有个细节STM32F10x不同容量的Flash扇区大小不一样。小容量和中容量的扇区是1KB大容量和互联型是2KB。擦除只能按扇区整块擦所以App区和Bootloader区的边界最好对齐到扇区边界否则你擦一个扇区会把邻居的代码也擦掉。官方例程在flash_if.c里放了一个扇区大小表不同型号会自动匹配这是它想得周到的地方。2.2 中断向量表重映射让App“认住”新家这是IAP最容易出事的地方我当年第一次移植就被这个坑搞到怀疑人生。Cortex-M3内核的中断机制是每次中断响应CPU都去地址0x00000000区域读取中断向量表找到对应的中断处理函数入口。在STM32F10x上0x00000000默认映射的是主Flash也就是0x08000000。问题来了如果App编译时设置起始地址为0x08004000它的中断向量表也编译到了0x08004000但CPU发生中断时还是去0x08000000找向量表。这个地址放的是Bootloader的向量表里面根本没有App的中断处理函数地址结果就是中断一触发程序直接跑飞或者进HardFault。解决办法是在App启动早期把向量表偏移到App区。标准外设库的misc.c里提供了NVIC_SetVectorTable函数本质是操作SCB-VTOR寄存器。在实际的F103工程里我一般直接在SystemInit或main最开头写上#define APPLICATION_ADDR 0x08004000 SCB-VTOR APPLICATION_ADDR;这就是把CPU的中断向量表从默认的0x08000000指向App区。需要提醒的是F1是老内核早期某些A版、B版芯片对VTOR的支持不完美如果遇到设置VTOR仍然不起作用的情况就得考虑在Bootloader里做中断转发或者干脆把App设计成尽量少用中断。不过我在后期C版芯片上实测SCB-VTOR写法是稳定有效的。2.3 升级流程设计与YMODEM协议数据怎么安全地流进Flash官方AN2557的升级流程总体分四步Bootloader启动后初始化串口并主动发送字符C等待握手上位机用支持YMODEM的软件打开文件并发送Bootloader逐包接收、校验CRC、擦写Flash全部收完后跳转App。这套流程里YMODEM协议承担了“可靠传输”的职责。它把一个文件拆成128字节或1024字节的块每块都带块编号、块编号反码和CRC校验。接收方收到一个包后先验证块编号连续再算CRC任何一个环节不对就回复NAK要求发送方重传。YMODEM还在正式数据之前先传一个包含文件名和文件大小的头部信息包Bootloader可以利用这包信息判断固件大小是否超过App区容量提前拦截错误升级。官方跳转函数的实现很经典直接看代码typedef void (*pFunction)(void); void Jump_To_Application(uint32_t app_addr) { uint32_t JumpAddress; pFunction Jump_To_Application; /* 检查栈顶指针是否落在SRAM区间防止App区为空导致跳飞 */ if (((*(__IO uint32_t*)app_addr) 0x2FFE0000) 0x20000000) { JumpAddress *(__IO uint32_t*)(app_addr 4); Jump_To_Application (pFunction)JumpAddress; /* 先关闭全局中断再设置MSP栈指针 */ __disable_irq(); __set_MSP(*(__IO uint32_t*)app_addr); Jump_To_Application(); } }跳转前的那个if判断很多人不理解其实它是在检查App起始地址处的第一个4字节值。如果App区真有程序这个位置存放的是初始栈顶指针必然落在SRAM地址范围内0x20000000开头如果App区是空的或者数据无效这个值就大概率不是合法的SRAM地址。这个判断能有效避免程序跳到一个空白区域然后跑飞是官方例程里非常实用的一笔。3. 实操用官方例程搭建最小可用的IAP升级3.1 官方工程结构梳理先搞清楚每个文件的作用从ST官网下载AN2557的配套例程后解压看到的工程是以标准外设库为基础的多个子工程。核心文件其实就四个common.c负责公共数据结构和串口收发辅助函数iap.c是Flash擦写和跳转的主逻辑ymodem.c是实现YMODEM协议收包和解包的协议栈main.c是串口初始化和升级状态机的入口。文件职责学习优先级common.h / common.c文件信息结构体、串口字节收发高iap.h / iap.cFlash扇区擦除、写入、跳转App高ymodem.h / ymodem.cYMODEM协议处理、CRC校验、分包组包高main.c初始化、主循环状态机高flash_if.h / flash_if.c部分版本提供Flash底层操作封装中stm32f10x_xx.c标准外设库外设驱动低很多人刚开始看ymodem.c会被变量名和状态分支搞得头晕我的经验是先不要逐行抠协议代码先把main.c的流程走通再回头理解YMODEM的收包状态机效率会高很多。协议本身只是工具真正的核心是Flash操作和跳转逻辑。3.2 关键代码逐段拆解跳转、擦写、接收一个都不能少看芯片手写Flash是这个例程最核心的动作。STM32F103的Flash写入前必须先解锁、擦除扇区再按16位半字为单位写入。官方封装好的写函数思路非常清晰最终调用库函数完成写入uint32_t FLASH_If_Write(uint32_t destination, uint8_t *p_source, uint32_t length) { uint32_t i; FLASH_Status status FLASH_COMPLETE; FLASH_Unlock(); for (i 0; (i length) (status FLASH_COMPLETE); i 2) { status FLASH_ProgramHalfWord(destination, *(uint16_t *)p_source); destination 2; p_source 2; } FLASH_Lock(); return 0; }写Flash有几个硬性规则写入地址必须是偶数写入数据长度必须是半字对齐写入区域必须是已经擦除过的状态否则结果不可预期。官方例程在接收YMODEM包之前会先把目标扇区全部擦掉这是正确姿势千万不要图省事跳过擦除。再往深处讲接收循环是在main.c里完成的。主循环里调用了YMODEM协议的接收函数每拿到一批数据就通过FLASH_If_Write写入到App区地址。这里有个很多人忽略的小技巧YMODEM的包大小是128字节或1024字节但Flash最小擦除单位是扇区所以最好把接收缓冲区大小设置为扇区大小的整数倍避免每次收到一个包就频繁切换擦写状态影响效率和Flash寿命。整个升级完成后上位机软件会发送一个EOT结束符YMODEM协议栈处理完EOT后会把文件的信息填入一个结构体里。Bootloader拿到这个结构体确认文件长度和校验都没问题就可以执行跳转了。官方代码里还给了一层CRC校验做确认这是量产固件最后的一道保险。3.3 App工程配合修改链接地址和中断向量偏移Bootloader单独能跑还不够App工程那边也必须配合改两个地方否则跳转过去还是白搭。第一处是链接脚本或者IDE里的ROM起始地址第二处是中断向量表偏移。在Keil MDK里App工程的Options for Target中Linker标签页里要把IROM1的Start地址从0x08000000改成0x08004000对应你Bootloader的实际占用大小Size相应改小。如果用的是STM32CubeIDE或GCC就改链接脚本.icf或.ld文件里的Flash起始地址。这一步是告诉编译器App的代码和只读数据都要放到偏移后的地址上。改完链接地址还要在App初始化代码里加上向量表重定向。最简单的办法是在SystemInit函数开始处直接调用标准外设库的NVIC_SetVectorTableNVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x4000);第二个参数就是App区相对Flash起始地址的偏移量。如果你的芯片版本对VTOR支持不友好就要考虑把向量表复制到SRAM再用SYSCFG重映射到0x00000000这样做兼容性更好但代码复杂度更高。基础产品建议先试SCB-VTOR方案跑不通再上SRAM映射或者中断跳板。还有一件事容易被忽略Bootloader跳转前要关闭自己用到的外设时钟和中断别把一堆打开的串口、定时器状态带给App。官方例程的跳转函数里虽然只做了关中断和重设MSP我的习惯是在跳转前把用到的串口显式去初始化把外设中断标志位全部清掉确保App起来时外设是干净状态。4. 常见问题与排查经验4.1 跳转后死机先查向量表再查时钟和外设跳转后死机是IAP最典型的问题我在无数论坛帖子里看到过这种求助最后九成都是向量表偏移没设置对。判断方法很简单把App单独直接烧到0x08000000地址如果App能正常运行说明代码自身没问题问题出在Bootloader跳转或者向量表偏移上。排查顺序我一般是这样先确认App链接地址和Bootloader分区边界是否一致再确认App里是否确实执行了SCB-VTOR偏移最后检查Bootloader跳转时是否关闭了外设中断。另外如果Bootloader里用了操作系统或者复杂的定时器跳转前光关全局中断还不够一定要把SysTick和NVIC里挂的异常入口都清理干净。4.2 升级中途变砖分区策略和校验兜底官方例程的升级策略是直接往App区写这有一个隐患如果升级到一半串线断了、断电了App区已经被擦掉一部分设备就变砖了。官方代码在演示场景没问题但量产产品不能这样裸奔。我的做法是把Flash多分一个备份区升级包先完整下载到备份区接收过程中每个包都做CRC校验全部接收完成后再对整体做校验校验通过才把备份区的内容整体搬到App区。代价是App可用空间会少了备份区那一块换来的是“升级失败设备还能接着跑老程序”的安全体验。如果硬件允许也可以用外部Flash存升级包逻辑一样。4.3 YMODEM传输异常115200只是看起来稳不少人复现官方例程时发现用SecureCRT或XShell发送文件有时候传输到一半就卡住或者提示CRC错误。这种问题绝大多数不是协议本身的问题而是上位机软件没有选对YMODEM模式。一定要确认发送端选的是YMODEM而不是XMODEM或ZMODEM三者的帧格式和握手方式差异很大。波特率方面官方默认115200但具体能不能稳定跑还得看你板子的晶振精度和串口线质量。ST-Link的虚拟串口一般没问题但一些PL2303、CH340山寨线在高波特率下丢包率很高。我一般量产产品用115200如果发现丢包严重就降一档到57600或38400IAP本来就不是追求速度的场景稳定压倒一切。问题现象常见原因解决办法发送文件后Bootloader无反应握手字符C发送时序不匹配确认上位机选YMODEM先手动发送一次字符C传一半卡死串口丢包或USB转串口线质量问题降低波特率、换线检查接线距离CRC错误频繁波特率误差大、数据线干扰用外置晶振检查地线降低波特率接收完成后跳转死机向量表偏移未设置App内加SCB-VTOR确认链接地址升级失败重启跑不了老程序直接写App区无备份策略增加备份分区先校验后搬移4.4 从例程迁移到产品时要注意的几件事官方例程本身就只是“最小可用”的参考实现离产品还有几段路要走。第一串口协议要加固YMODEM虽然自带CRC但最好在应用层再加一包版本信息和固件大小校验防止客户传错文件。第二固件版本管理要做起来Flash里存一个版本号Bootloader升级时判断新版本是否比当前版本新太老的要拒绝。第三升级入口要设计好常见做法是App运行中收到升级指令设置一个标志位到备份寄存器或Flash然后软复位进Bootloader而不是每次上电都傻等几秒让Bootloader超时再跳App后者在开机速度敏感的产品上体验很差。最后再补充一点个人经验我们在一款F103的仪表产品上用了这套方案最初也是直接在官方例程上改后来发现量产时有两台设备升级完卡死。排查到最后原因是那批芯片的Flash扇区边界和我在代码里写的扇区表不完全一致因为Bootloader容量占得比较小App区的起始扇区算错了一位。从那以后我给自己定了个规矩开发阶段一定先把扇区表用调试器读出来核对一遍不要盲目相信记忆里的编号。IAP这种功能平时用不上一用就是远程救命的通道值得把每一处细节都较真到底。本文还有配套的精品资源点击获取