简介基于STM32的网络远程升级方案资料面向需要实现FOTA/IAP功能的嵌入式开发者。内容聚焦IAP应用编程涵盖中断向量表重定位、闪存扇区擦写、固件校验、网络通信及安全验签等关键机制并涉及异常回滚策略适合具备一定STM32基础、希望上手远程固件更新项目的学习者。压缩包内共3个文件均为C源码包体约30KB结构紧凑便于直接分析核心逻辑。目前已有1047人浏览学习。该资源的价值在于用少量代码搭建了较完整的IAP程序框架包含网络服务相关模块可帮助读者理解远程升级的工程实现细节与模块组织方式减少从零搭建的时间成本。 我在产品上第一回被远程升级折腾是在一个部署在厂区里的采集设备上。设备用的STM32F103已经稳定跑了半年结果客户反馈偶发死机查下来是App里的一个状态机bug必须到现场重新烧固件。工程师搭高铁过去连上ST-LINK烧完再回来前后三天。那次之后我就下决心凡是有网络接口的STM32设备都必须具备IAP能力——也就是把固件下载和更新这件事从烧录器手里接过来改成设备自己通过网络远程完成。这篇文章就把一套可落地的STM32网络远程升级IAP方案拆开讲从Flash分区、升级包协议、Bootloader跳转到常见的卡死问题和恢复策略都会覆盖。不管你是刚接触Bootloader的初学者还是已经做过几版IAP想补细节的老手都可以照着思路去落地。1. 网络IAP的整体链路设计谁在负责下载谁在负责启动1.1 两条程序的职责边界IAP方案的第一个认知是设备里有两份程序一份叫Bootloader一份叫App。很多人习惯把升级理解成App的事情这是第一个误区。真正稳定可靠的方案升级流程是App发起、Bootloader执行。App收到服务器下发的固件数据后只负责把它写到备份区或者临时区然后置一个升级标志软复位。Bootloader上电后第一件事就是检查这个标志如果存在就执行下载、校验、搬迁全部成功后再跳转新App。Bootloader里不要放业务逻辑能多简单就多简单。我见过有人在Bootloader里加了传感器采集、LED状态灯、甚至部分业务逻辑结果Bootloader越写越大最后自身升级风险成倍增加。Bootloader只做好四件事就够了初始化最小外设、检查升级标志、接收并校验新固件、跳转App。网络协议栈、文件系统这种吃Flash和RAM的组件能不进Bootloader就不进除非你的Flash实在大到没地方花。1.2 网络通道选型与场景适配网络通道的选择直接影响Bootloader的复杂度。这块没有绝对优劣只有适不适合你的产品场景。传输方式典型硬件Bootloader实现成本适用场景以太网W5500 SPI / MCU内置MACPHY低硬件协议栈或lwIP工业设备、网关、固定安装WiFiESP8266 / ESP32 透传低AT指令即可智能家居、消费类产品4G Cat.14G模块串口AT指令中需处理长连接和断线户外设备、移动场景通道不同但IAP的核心逻辑几乎不变拿到的都是一串字节流只是这串字节的来源不同。我自己最常用的是W5500SOCKET裸机实现Bootloader里不需要跑完整TCP/IP协议栈W5500硬件协议栈直接把TCP分包处理好MCU侧只负责把数据按帧解析、写Flash。如果你的产品已经用了ESP8266注意AT指令返回的不定长数据要小心处理我遇到过AT固件版本不同导致返回字符串格式变化解析代码直接崩掉的情况。1.3 一次升级的完整运行时序把整条链路在时间上理顺很多设计决策就自然有答案了。完整时序大致是这样设备上电Bootloader检查升级标志。没有则直接跳转App有则进入网络下载流程。App运行中周期向服务器查询新版本服务器下发固件元信息版本号、固件大小、CRC。App开始分包下载固件写入备份区进度上报服务器。全部写完后App对备份区固件做整包CRC校验成功则写升级标志执行NVIC_SystemReset()复位。Bootloader启动看到升级标志检查备份区固件合法擦除App区把备份区固件搬运过去再次CRC校验。校验通过后清除升级标志跳转新App。失败则保留旧App直接跳旧App运行。这个时序里最关键的一点是新固件先写在备份区而不是直接覆盖当前运行的App。这样即使下载了一半断电旧App依然完好Bootloader一判断标志不完整就直接跑旧App设备功能不中断。这是远程升级的第一原则——永远确保有一份能跑的固件。2. Flash分区规划与工程配置从地址0x08000000开始算清楚2.1 实例F103C8T6上的推荐分区在做任何IAP开发前第一步永远是画Flash分区图。这一步没做好后面所有地址偏移都是空中楼阁。以常见的STM32F103C8T6为例它只有64KB内部Flash起始地址0x08000000每页1KB。如果还要在Bootloader里塞以太网收包逻辑空间会很紧所以分区要精打细算。区域起始地址大小内容Bootloader0x0800000016KB0x4000IAP升级程序小功能代码App区0x0800400047KB0xBC00应用固件配置区0x0800FC001KB升级标志、当前版本号、包序号记录App区只留47KB会限制应用功能扩展所以实际产品我更推荐F103RCT6或F103ZET6这种256KB/512KB大容量芯片。Flash越大越有条件做双分区A/B备份升级可靠性高不止一个量级。分区时注意两点一是App起始地址要4KB对齐或者至少2KB对齐这样后续做写保护、页擦除都方便二是配置区放在单独的页里避免每次写标志都要擦除整个扇区把别的东西擦掉。2.2 Keil / IAR / GCC下如何修改App工程链接地址App工程的起始地址不是随便写个偏移就行必须让链接器把App代码生成到指定地址。这里只动链接配置代码里不需要改。Keil MDK最简单Options for Target - Target页面把IROM1的Start改成0x08004000Size改成0x0000BC00。IRAM1一般不用改因为Bootloader和App共用同一片RAM只要App的RAM需求在芯片RAM范围内即可。IAR工程要改.icf链接脚本把place in Flash改成place at address mem: 0x08004000并约束长度。GCC则改链接脚本的FLASH起始地址和LENGTH。如果这一步忘了App编译后的入口地址还是0x08000000跳转过去就是死路。我调试时发现很多跳转后跑飞的案例一半原因是App工程的链接地址根本没改另一半原因才是跳转代码的问题。2.3 Flash擦写的底层细节Bootloader里写Flash最容易踩的坑是忘记解锁和跨页擦除。STM32的Flash在复位后默认上锁要往里面写数据必须按顺序执行解锁、擦除、编程、上锁。HAL库的流程大概是HAL_FLASH_Unlock(); __HAL_FLASH_CLEAR_FLAG(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPERR); FLASH_ErasePage(target_addr); // 按页擦除 HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, target_addr offset, data_word); HAL_FLASH_Lock();注意F103中容量产品一页1KB高容量产品一页2KB。如果你的升级包跨页了必须先擦除所有涉及到的页再逐字编程。擦除是整页整页来的不能单独擦某个地址。还有一点写Flash期间CPU不能从Flash取指执行否则会卡住。如果Bootloader里的写Flash循环里还有其他Flash区的函数调用最好把写数据那一段放到RAM里执行。HAL库内部已经处理了大部分这种情况但你自己写裸机底层时一定要想到这点。3. 升级包传输协议分包、校验、断点续传3.1 帧格式设计网络传输不像本地烧录TCP/UDP只保证把字节送到不保证内容完整。应用层必须自己设计协议帧。我用的帧格式很直白在Bootloader和服务器之间跑字段长度说明帧头2字节0xAA 0x55命令1字节0x01 升级请求0x02 数据帧0x03 完成确认包序号2字节0~65535循环数据长度2字节当前包有效字节数最大1024数据N字节固件内容或参数CRC324字节从命令到数据结束的整段校验数据长度最大1024字节是为了匹配网络MTU和Flash页大小。如果单包太大底层IP分片后丢包概率上升太小则传输次数过多升级时间长。1024字节是个经过实测的平衡点。3.2 ACK/NACK重传与断点续传每收到一个数据帧Bootloader写Flash成功后回一个ACK帧校验失败或者写Flash失败回NACK帧服务器只有收到ACK才发下一包。没有ACK就一直重发当前包重发超过5次判定链路异常Bootloader放弃升级并跳转旧App。断点续传用包序号实现Bootloader每成功写完一包就把下一个期望的包序号记录到配置区Flash里。中途断电重启后Bootloader从配置区读出包序号直接向服务器请求从该序号继续下载不用从头传。对百K级别的固件来说这个设计能把升级失败的成本降一个量级。注意配置区Flash有擦写寿命建议对包序号做写均衡或者在RAM里先累计、每16包落一次Flash避免频繁擦写。3.3 整包CRC校验最后一道防线每个帧的CRC32只能保证单包在传输过程中没出错不能保证整个固件完整。所以在升级完成前Bootloader会把所有收到的数据算出一个总CRC32和固件头里的CRC32比对。固件头建议这样设计typedef struct { uint32_t magic; // 魔数 0xDEADBEEF uint32_t version; // 固件版本号 uint32_t total_size; // 固件总字节数 uint32_t total_crc32; // 整包CRC32 uint8_t reserved[16]; // 保留可放签名信息 } FirmwareHeader;CRC32建议用查表法标准多项式0x04C11DB7网上随处可见现成实现。别用简单的求和校验我见过求和校验通过了但固件刷进去照样跑飞的情况因为数据错位时求和可能恰好一致。整包CRC通过后Bootloader才会擦除旧App区并搬移新固件。4. Bootloader跳转App向量表、栈指针与HAL_Delay卡死的真相4.1 三步跳转代码拆解从Bootloader跳转App的代码核心只有三步。第一步读App首地址的初始栈指针第二步读App的Reset_Handler入口地址第三步设置MSP并跳转。代码写出来是#define APP_FLASH_ADDR 0x08004000 typedef void (*pFunction)(void); void JumpToApp(void) { uint32_t app_stack *(volatile uint32_t *)APP_FLASH_ADDR; pFunction app_entry (pFunction)(*(volatile uint32_t *)(APP_FLASH_ADDR 4)); HAL_UART_DeInit(huart1); // 关闭Bootloader用过的外设 HAL_DeInit(); // 复位HAL库底层 HAL_RCC_DeInit(); // 复位时钟配置 SysTick-CTRL 0; // 停掉SysTick SysTick-LOAD 0; SysTick-VAL 0; __disable_irq(); // 关闭全局中断 __set_MSP(app_stack); // 切换到App的栈 app_entry(); // 跳转 while (1); }这三步的顺序不能乱。尤其是__disable_irq()必须放在__set_MSP()之前否则如果跳转前来了一个中断而这时栈还是Bootloader的中断处理可能把RAM数据搞乱。为什么上面要HAL_RCC_DeInit()因为我遇到过跳转后App重新初始化时钟但发现PLL状态不对直接死在时钟配置里的情况。把时钟恢复到复位默认值能让App的启动环境更干净。4.2 中断向量表重映射这是整个IAP里最容易被遗忘、出问题最隐蔽的一步。App链接地址已经改到0x08004000但CPU默认的中断向量表还在0x08000000。如果App里使能了UART中断中断一来CPU去0x08000000找向量表拿到的是Bootloader里的中断处理函数地址那后果可想而知。F103系列需要在App的main函数最前面或者SystemInit里显式设置向量表偏移SCB-VTOR 0x08004000;如果你是老标准库且CMSIS版本太老代码里可能没有SCB-VTOR定义。可以直接操作地址#define SCB_VTOR (*(volatile uint32_t *)0xE000ED08) SCB_VTOR 0x08004000;F1系列的VTOR不像F4那样要求严格对齐到中断向量表大小但建议App起始地址至少256字节对齐通常我们做的4KB对齐完全够用。向量表偏移没设对最典型的症状就是跳转进App了主循环在跑但一开中断就死机或者HAL_Delay卡住。4.3 为什么跳转后HAL_Delay会卡死跳转后卡死HAL_Delay几乎是每个IAP新手必踩的坑。它的根因在于HAL_Delay是依赖HAL_GetTick()的而HAL_GetTick()的值是在SysTick中断服务函数里递增的。换句话说HAL_Delay能正常工作前提是SysTick中断必须健壮地跑起来。跳转后卡死无非几种情况跳转前调用了__disable_irq()跳转后没人调用__enable_irq()SysTick中断永远进不去tick不更新HAL_Delay在while循环里干等。跳转前把SysTick停了但App在main很早期就调用HAL_Delay比如等电源稳定而App自己的HAL_Init还没执行到SysTick没有重新配置。向量表偏移没有设置SysTick中断触发了CPU却跳到0x08000000的向量表执行的是Bootloader的SysTick_Handler而这个Handler里没有维护App需要的tick变量。排查思路也简单在App的main入口处查看SysTick-CTRL和SysTick-LOAD的值确认SysTick已使能、中断已开启再看SCB-VTOR是否正确。我建议App里所有依赖延时的HAL_Delay调用尽量放在HAL_Init()之后并且在HAL_Init()之后手动调用HAL_InitTick(0)确保tick重新开始。我自己写的模板里还会在入口处加一行串口打印确认App真正启动到了哪一步。5. 远程升级调试实录ST-LINK Utility、串口日志与失败恢复5.1 用ST-LINK Utility和J-Flash检查分区内容跳转失败时第一件事不是改代码而是确认Flash里到底有什么。ST-LINK Utility连上板子后打开Target - Memory View手动填地址0x08004000你应当能直接看到App的二进制数据而不是一堆0xFF。如果全是0xFF说明App根本没写进去如果能看到代码但不是你预期的最新版本那就要查写入流程的源数据是否有误。另一个技巧是在Keil里编译App时生成bin文件用fromelf --bin --outputapp.bin app.axf。然后把这个bin用ST-LINK Utility手动烧到0x08004000再测试Bootloader跳转是否正常。这样可以把Bootloader跳转问题和网络传输问题分开排查手动烧进去能跑就是升级链路的问题手动烧进去都跑不了就是链接地址或跳转代码的问题。J-Flash的操作思路类似用J-Link的话打开bin后设置下载起始地址即可。5.2 三个典型故障和对应的定位链路现象大概率根因定位方法跳转后白屏跑飞HardFaultApp链接地址没改跳到一个空的向量地址反汇编查看0x08004000偏移处代码是否正常跳转后中断一开就死没有设置SCB-VTOR在App main第一行设VTOR再测试HAL_Delay卡死SysTick中断没跑或中断被全局关闭检查SysTick-CTRL、__enable_irq是否执行有一次我排查一个刷进去新固件后网络功能偶发异常的问题最后发现是跳转前跑着的TCP连接没关闭网卡DMA还在往RAM里写数据把App的变量区覆盖了。跳转前把所有外设真正DeInit干净不光是UART网卡、DMA、定时器全部关掉这个教训我记到现在。5.3 强制升级与Backdoor兜底设计网络远程升级最怕的一件事所有升级通道都依赖App但新App本身是坏的根本起不来。所以必须留一个和App状态无关的兜底入口。我常用的方案是Bootloader在跳转前检查两个条件——升级标志和尝试启动计数。每次Bootloader要跳App前把计数加1并写入配置区App正常启动跑过5分钟后清零。如果App启动就崩溃计数会不断累加累加到3次后Bootloader不再跳App而是留在Bootloader模式等待用户通过按键或者串口强制恢复。配合这个机制Bootloader里最好也保留最简单的串口XMODEM接收功能这样万一网络彻底废了工程师去现场用一条串口线也能救砖。这个Backdoor可能一辈子用不上但真要用的时候能救命。6. 固件安全防护与OTA工程化扩展6.1 给固件加上加密和签名校验产品一旦能远程升级就等于向外部敞开了写Flash的通道。网络抓包的人随时可能伪装服务器给设备下发恶意固件。所以从第一版设计起就该考虑安全而不是等出事再补。基础做法是加密加签名服务器用AES-128加密固件体再用RSA私钥对固件头做签名Bootloader内置AES密钥和RSA公钥下载完后先验签再解密、再写Flash。AES防止固件被直接抓包拿走后分析RSA签名防止伪造固件被灌进设备。密钥存哪是个问题我现在习惯把密钥拆成多段分散存在Bootloader代码和Flash选项字节里虽然不绝对安全但能挡住绝大多数业余抓包玩家。注意加密和签名都会让Bootloader变大F103C8T6的16KB Bootloader会非常紧张建议上大Flash芯片。6.2 双分区A/B备份与自动回滚备份区方案解决下载一半断电的问题A/B分区解决新固件本身是坏的的问题。A/B分区的思路是当前运行版本在A区新固件下到B区全部校验通过后把启动标志切到B。如果B区固件启动失败Bootloader在超时后把启动标志切回A设备自动回滚到老版本。这个方案需要至少两倍App大小的Flash。比如App实际50KB一版设计就要留出100KB。很多朋友第一反应是浪费了一半Flash但从运维角度看这个浪费买来的是升级失败零现场维护值不值你自己算。我早期在F103C8T6上做单分区方案上线后遇到一次传输中网络抖动升级失败第二天就出差了。换大芯片做双分区后再没为升级跑过现场。6.3 从IAP到完整的OTA设备管理把IAP链路做通之后你会发现代码只占三成工作量剩下七成是平台和流程服务器怎么管理固件版本、怎么记录每台设备的升级状态、怎么灰度发布、怎么回滚。我在Bootloader里每个关键节点开始下载、每收到10%、写Flash完成、CRC校验、跳转都发了状态上报帧服务器端落库这样出了问题能精确回溯到是网络断了还是写Flash失败。版本管理上固件头里的version字段建议分成主版本、次版本、修订版本三个字节服务器按策略决定是否允许降级。老设备经常会有必须保持旧版本不能升的场景没有版本控制就别谈远程升级落地。等把版本、日志、灰度、回滚这些补齐了这套系统的可靠性才算真正够得上生产环境。最后说一句个人经验IAP不是写完跳转函数就交付了真正决定项目成败的是失败恢复和可观测性。我后来在Bootloader里加了详细串口日志开关配合服务器端的升级进度记录90%的现场问题都能远程定位。如果你第一次做远程升级建议按有线以太网单App区按键强制升级起步跑通全链路后再逐步加签名、加密和双分区每一步都有明确收益不值得一次贪多。本文还有配套的精品资源点击获取