STM32 OTA远程升级实战：基于X-Ware与双Bank的固件安全回滚方案

1. X-Ware不是个噱头：这套RTOS组件栈到底解决了什么问题

如果手头有一批已经部署到现场的STM32设备，突然发现固件里有个偶发Bug，你会怎么处理？让客户寄回来？不太现实。派人带ST-Link跑现场？成本太高。我经历过一次这种事之后，就下决心必须把OTA做起来。而真正动手选型时，我最终把整个方案压在了X-Ware IoT Platform上，配合STM32原生的双Bank Flash机制，实现了完整的固件远程升级。

先说清楚X-Ware到底是什么。它本质上是微软Azure RTOS那一整套嵌入式中间件的集合，核心组件包括实时内核ThreadX、TCP/IP协议栈NetX Duo、文件系统FileX、Flash磨损均衡LevelX、USB协议栈USBX，以及GUI库GUIX。X-Ware IoT Platform就是在这些组件之上，把物联网设备最常见的需求——连接、传输、存储、安全、更新——打包成一套可复用的软件栈。这套东西后来移交给了Eclipse基金会管理，现在叫Eclipse ThreadX，但底层架构和API基本没变，项目里依然习惯叫它X-Ware。

那它到底解决了STM32设备升级的什么问题？最直观的一点，固件远程升级不是“把新固件下载下来写进Flash”这么简单，它需要一套完整的传输、存储、校验、回滚机制。自己做当然可以做，但你会发现工作量不止在下载那一步，而在周边：断线续传、Flash磨损、双区切换、安全引导、失败回滚。这些活每个都是深坑。X-Ware提供的是像NetX Duo这种成熟的协议栈和ThreadX这种强实时内核，配合STM32的硬件特性，把升级链路里能标准化的部分全部生态化，我只需要专注在业务层和Flash分区策略上。

适合谁来参考这套方案？如果你在做基于STM32的联网产品，比如智能网关、工业采集器、边缘控制器，还停留在“固件靠烧录器刷”的阶段，那这篇文章值得你看完。里面涉及的分区设计、升级状态机、回滚策略，不绑定具体商业SDK，拿到自己的项目里照样能落地。

2. 升级链路全局设计：云、网关、设备端各自该管哪一段

2.1 整体链路：从云端发布新版本到设备落地

整个升级链路，我从上到下分成三段：云端、下发通道、设备端执行。

• 云端负责版本管理、灰度发布、升级记录统计。我这边用的是自定义的IoT后端，跟X-Ware的Azure IoT嵌入式中继配合，负责把“有新版本”这个事件推送到设备端。

• 下发通道分两条线。命令通道走MQTT，设备端通过ThreadX里的MQTT客户端保持长连接，实时接收升级指令。固件数据通道走HTTPS，设备端用NetX Duo的HTTP客户端从对象存储拉取固件包。为什么不直接让MQTT把固件包整个推下来？因为MQTT传大文件，要Base64编码，体积膨胀三分之一，而且消息服务器有单条消息上限，拆包重组复杂度高，非常容易出错。HTTPS可以做分块下载、断点续传，对大文件友好得多。

• 设备端的执行链路就是本文的核心：收到了“有新固件”的通告之后，先确认当前版本号和目标版本号是否匹配，然后通过HTTPS把固件包拉到备用Flash区域，校验签名和完整性，再置位升级标志、复位进入Bootloader，由Bootloader完成最终启动切换。如果新固件起不来，自动回滚到旧固件。

设计这套链路时最重要的一件事，是把“升级决策”和“升级执行”彻底分开。设备端只负责执行，要不要升、升到哪个版本，由云端决定。这样设备端逻辑简单，出错的概率就低。

2.2 升级流程的状态机：用一张表把各状态定死

固件升级最忌讳的是“想到哪写到哪”。我第二次重写整个升级模块时，第一件事就是把状态机画在文档里，代码里只允许出现这几个状态，不允许状态跳来跳去。

这张表我在项目评审时贴出来，所有参与开发的同事都盯着它挑毛病。事实也证明，状态定死了，后面写代码、做测试用例都变得非常清晰。每次状态跳转都一定要考虑异常分支，这是我在这个项目里最大的感触之一。

2.3 为什么下载通道选HTTPS而不是MQTT直传

上面简单提过一句，这里展开说。原来我第一版方案确实尝试过MQTT直传，踩了一圈之后换成了HTTPS，理由很实在。

• 效率。MQTT是文本协议，固件二进制转Base64之后体积增加约33%。一块1MB的固件，实际传输1.33MB。在NB-IoT或者信号不稳定的Wi-Fi环境，这个开销非常明显。

• 控制粒度。MQTT Broker对单条消息有大小限制，固件得拆成几百条QoS 1消息逐条发送，接收端再拼装。中间任何一条丢了一旦不重试，整体就废了。HTTPS的HTTP Range头天然支持从任意偏移量接着下载，实现断点续传非常顺手。

• 服务器压力。MQTT是一条一条推，设备多了，消息量很容易打爆Broker。HTTPS是设备主动拉，配合CDN或者说对象存储，静态文件分发根本不是问题。

所以在我的最终方案里，MQTT只干两件事：告诉设备“有新固件了”和“新固件的信息是什么”。实际的固件数据，设备自己去HTTPS服务器拉。这个方案的压力模型很清晰，设备越多越好用。

3. STM32 Flash分区与双Bank切换的那些硬约束

3.1 Flash整体分区：Bootloader、App、备份、参数各占多少

STM32做OTA绕不开Flash规划。我这里以STM32H743为例，它有2MB内部Flash，双Bank结构，每个Bank 1MB。另一款常用的G4系列也支持双Bank，只是容量小一些，思路完全一样。

沿用双Bank机制的思路，我把2MB Flash分成四块：

有几个细节值得说。Bootloader区只放了128KB，看起来很大，但实际上Bootloader代码量一般控制在64KB以内。它不需要复杂的逻辑，只要能初始化时钟和Flash、完成校验、跳转App就够了。把Bootloader压缩小，就能腾出更多空间给App区。

参数区被我单独划出来，不放在App区也不放在Backup区。原因很简单：升级标志、回滚次数这些数据，在固件升级过程中要频繁读写，如果放在App区，App区反复擦写会加速Flash磨损，而且万一写入中途断电，容易把整个App区搞坏。独立参数区的好处是，无论Bootloader还是App，都可以随时读它、写它，互不干扰。

3.2 双Bank切换的硬件机制

STM32H7的双Bank机制，是这块芯片原生支持的Flash选项字配置。默认情况下Flash是单Bank模式，也就是说从软件角度看它是一整块2MB的连续存储。要启用双Bank模式，需要修改Flash选项字节中的DBANK位，把Flash切到双Bank模式。

切到双Bank模式之后，一个非常关键的能力就出来了：系统可以在Bank 1里执行代码的同时，对Bank 2进行擦除和编程操作。这就为OTA提供了极大的便利——App跑在Bank 1，新固件下载后直接写进Bank 2，写完校验、切启动地址、复位，Bootloader一看设置，直接从Bank 2启动。整个过程不需要停掉业务，也不需要外部存储芯片顶替过渡。

用CubeMX配一下也简单，在Flash编程接口里把双Bank选项打开，代码里通过HAL_FLASHEx_OBProgram修改选项字节，重启后生效。需要注意，修改选项字节本身会触发一次复位或者需要手动复位，所以这个配置通常在生产烧录阶段就设好，不要在运行时频繁改。

3.3 分区与中断向量表重映射的代码要点

代码层面的关键点有两个：Bootloader跳转App、App重映射中断向量表。

Bootloader在完成校验之后，要把CPU执行权交给App。这里有一个非常容易犯错的坑，就是直接调用App的main函数。正确做法是读取App区开头的栈顶地址和复位向量，先设置主栈指针MSP，再通过函数指针跳转到App的Reset_Handler。

typedef void (*pFunction)(void); uint32_t app_addr = APP_START_ADDRESS; // 0x08020000 uint32_t app_stack = *(volatile uint32_t *)app_addr; pFunction app_reset = (pFunction)(*(volatile uint32_t *)(app_addr + 4)); __set_MSP(app_stack); app_reset();

跳转之前还应该把SysTick、外设中断全部关掉，避免残留的中断在App里乱跳。

App这一侧，必须在进入main之后第一时间重映射中断向量表。STM32H7的中断向量表默认在0x08000000，如果App跑在0x08020000而不做重映射，任何一个中断触发，MCU都会跳去执行Bootloader区域的向量表，结果就是死机。

SCB->VTOR = APP_START_ADDRESS;

这行代码必须在App的main函数最前面执行，最好在时钟初始化之前。我在实测中遇到过一种诡异现象，App运行过程中串口完全正常，但一按按键触发外部中断就死机，最后定位就是中断向量表没有重映射，按键中断实际跳到了一个错误地址。

4. Bootloader和App怎么握手：升级状态机与回滚决策

4.1 升级标记与“启动成功”握手协议

升级标记放在参数区的固定地址，我定义了一个结构体，每次只写16字节，轮流用两个冗余Buffer，防止写入时掉电导致数据半新不旧。

typedef struct { uint32_t magic; // 固定值 0x5A5AA5A5，用于识别数据有效性 uint32_t version; // 目标固件版本号 uint32_t crc32; // 参数区的CRC校验 uint32_t flags; // 升级标志位 uint32_t boot_count; // 尝试启动次数 uint32_t boot_limit; // 允许尝试启动的最大次数 } upgrade_param_t;

握手协议是这样定义的：

• App进入正常运行状态后，会主动做一次“自检”。自检包括基础外设初始化、RTOS内核启动、关键业务线程跑起来。自检通过之后，App清除升级标志中的“待启动”标记，把状态改成“确认成功”。

• 如果App自检没通过，或者压根没跑起来，升级标志还停留在“待启动”状态，Bootloader在下次复位时会认为新固件启动失败，把boot_count加1，再次尝试启动新固件。

• 当boot_count累计达到boot_limit值，Bootloader就彻底放弃新固件，擦掉或者标记Backup区无效，回滚到旧固件继续运行。

4.2 Bootloader端启动决策流程

Bootloader的启动决策逻辑，用一句话概括就是：能跑旧固件就绝不冒险跑新固件，新固件没被确认成功之前，每次重启都给一次机会，但给了机会起不来就必须回滚。

启动流程如下：

1. 上电初始化时钟、配置Flash访问延迟，但不初始化任何外设。外设启动越少，Bootloader自身出问题的概率越低。

2. 读取参数区的升级标志。如果magic不对，说明参数区损坏，直接走旧固件启动。

3. 如果升级标志有效但状态是“待启动”，说明上一次新固件没有被确认成功，把boot_count加1。如果boot_count大于boot_limit，则回滚：将当前App启动地址指向Bank 1（旧固件），同时把Backup区标记为无效。

4. 如果升级标志显示“确认成功”，说明新固件已经跑起来了，那就继续从当前App区启动，并把Bootloader里的boot_count重置为0。

5. 从App区的起始地址读取栈顶指针和复位向量，执行跳转。

这套流程里最关键的判断逻辑是：Bootloader永远不验证新固件“是否健康”，它只验证新固件是否曾经被App自己确认过。因为Bootloader里没法跑业务，它不知道哪些外设必须正常、哪个业务线程必须存在。只有App自己才知道自己的启动是否完全成功。所以，握手协议是这个机制的灵魂，Bootloader只是执行器。

4.3 App端如何配合：上报进度、上报结果、主动请求回滚

App端在配合OTA时，要处理的逻辑比Bootloader多得多。我把它拆成三个角色：

• 下载执行者。App收到云端MQTT的升级指令后，启动一个独立的下载线程。线程里用NetX Duo的HTTP客户端按块下载固件，写入Bank 2区。每下载完一块，就上报一次进度给云端，云端可以在控制台上实时看到百分比。

• 自检裁判员。下载完成、重启、从Bank 2启动之后，App要在规定时间内完成自检。我设置的超时是15秒，15秒内所有关键线程都跑起来了，就写“确认成功”标志，然后上报云端“升级成功”。

• 失败申报员。如果自检超时或者某个关键线程起不来，App不能继续在故障状态里跑，应该主动写入“回滚请求”标志，然后软件复位。Bootloader看到这个标志，下一轮就会回滚到Bank 1的旧固件。

这套设计里，App和Bootloader的职责非常对称：App负责判断“我能不能活”，Bootloader负责执行“你活不了我就换一个”。职责清晰，逻辑就简单，Bug就少。

4.4 回滚的阈值设计：为什么试3次而不是1次

升级标志里有个boot_limit字段，我把它默认设成3。为什么是3次而不是1次？

原因是我实测发现，新固件启动失败的原因，并不全是固件本身有问题。有一次测试，新固件代码完全正常，但因为下载时网络抖动，最后1KB数据写坏了，Bootloader虽然做了SHA256校验却因为一个疏忽在校验逻辑里开了个小差，导致启动直接崩溃。这种情况如果只给1次机会，新固件根本没有重新下载修复的机会，直接回滚到旧版，等于白白浪费了一次升级。

给3次机会的含义是：第一次启动失败，设备重启；第二次还是同一份固件，还是失败；第三次还是同一份。如果连续3次都起不来，基本可以断定新固件有硬伤，回滚是止损。同时，3次重启的时间成本也就几十秒，对现场业务影响可以接受。

你也可以把boot_limit设成5或者更大，但每多1次，设备就多处于一段不可用状态。具体设多少，取决于产品对可用性的容忍度。我建议是3到5之间。

5. 用NetX Duo拉固件的实现细节与完整性校验

5.1 NetX Duo接口的初始化与TLS证书处理

设备端要发起HTTPS下载，最核心的一步是先把NetX Duo跑起来。我的工程里，网络协议栈是在ThreadX之上的独立线程里初始化的，包括：

• NetX Duo系统初始化
• 以太网接口或者无线接口的驱动注册
• DHCP客户端获取IP地址
• MQTT客户端连接云端
• TLS安全层加载证书

TLS这块，我直接用了NetX Duo自带的加密库，配合X.509证书解析。这里有一个我从其他项目带过来的经验：固件升级用的HTTPS服务器域名，必须要用固定的IP白名单或者强校验证书，不要依赖系统根证书库。设备环境里没有在线更新根证书的条件，为了降低中间人攻击风险，我在固件里预置了服务端的根证书指纹，每次TLS握手时校验指纹一致才继续。这个比单纯校验证书链更可靠也更轻量。

5.2 分块下载与写入Flash的循环结构

下载固件的线程逻辑，核心是一个循环：从HTTP服务器读取一块数据，写入Flash的Bank 2区，然后读出来做一次CRC校验，确认无误后继续下一个块。

这里有一个关键参数：快的大小。STM32H7的Flash编程粒度是32字节（一个word），但擦除的最小单位是sector，H7的sector大小是128KB。如果你的固件有512KB，那写入意味着要擦除整个Bank 2区的4个sector。擦除整块sector是必须的，不要试图只擦需要的部分，那样反而容易踩到Flash擦除后未完全重置的坑。

我设置的块大小是4KB。每次写入前先擦掉对应的sector，然后按32字节对齐分写。代码结构大概是这样：

#define FIRMWARE_BLOCK_SIZE 4096 uint8_t block_buffer[FIRMWARE_BLOCK_SIZE]; uint32_t download_offset = 0; nx_web_http_client_range_request(&client, NX_TRUE, url, &offset_ptr, &length_ptr, firmware_download_buffer, firmware_download_buffer_size, &bytes_copied); while (bytes_copied > 0) { // 1. 擦除目标sector // 2. 按32字节对齐写入Flash // 3. 回读校验 // 4. 更新download_offset download_offset += bytes_copied; // 请求下一段数据 nx_web_http_client_range_request(&client, NX_TRUE, url, &download_offset, &length_ptr, firmware_download_buffer, firmware_download_buffer_size, &bytes_copied); }

实际开发时用的是nx_web_http_client，这是NetX Duo新版里的Web客户端接口，支持Range请求。每次请求都从当前偏移量开始拉数据，这样即使中途断了，也只需要重连后把download_offset增量恢复就行。

5.3 SHA256与数字签名校验

固件完整性的核心逻辑是：下载完成后，Bootloader把Bank 2区的全部数据读出来，计算SHA256摘要，与固件包头部里携带的摘要比对。这个摘要同时还要通过RSA2048或ECDSA签名验证，防止固件被恶意篡改。

这里我用的是mbedTLS（现在叫TF-M或者Mbed TLS），ST官方也有对应的软件包直接集成。在Bootloader里，我只保留了SHA256和验签的最小实现，没有用完整的TLS库，这样可以把Bootloader体积控制在目标范围内。

mbedtls_sha256_context sha_ctx; uint8_t digest[32]; mbedtls_sha256_init(&sha_ctx); mbedtls_sha256_starts(&sha_ctx, 0); mbedtls_sha256_update(&sha_ctx, (uint8_t *)BACKUP_BANK_ADDR, IMAGE_SIZE); mbedtls_sha256_finish(&sha_ctx, digest); mbedtls_sha256_free(&sha_ctx); ret = mbedtls_rsa_verify(&rsa, NULL, NULL, NULL, digest, signature);

签名验证的公钥直接编译进Bootloader里，不在运行时从外部读取，这样能防止签名公钥本身被替换。

5.4 下载过程中的断点续传

断点续传的落地比我想象中简单，主要是靠HTTP的Range机制。下载线程每次启动时，先读取参数区里保存的download_offset，如果上次下载中断时已经写了300KB，那就直接从300KB处继续。

中断恢复的触发条件有两个：网络断开，或者设备意外断电重启。

网络断开时，线程会做有限次数的重连，比如连3次，每次间隔指数退避，30秒、60秒、120秒。如果重连都失败，就先把download_offset和当前状态写进参数区，然后线程挂起，等待MQTT命令重新触发。

意外断电的情况更依赖Flash可靠性。每写一个块，我都会先更新参数区的offset，再擦写下一个sector。这样即使掉电，最多丢一个块的数据，重新下载时从offset处继续，不会有数据错乱。

6. 从死机到自动回滚：实测中踩过的最深的几个坑

6.1 Flash擦写把RTOS调度“卡死”

第一次联调的时候，我遇到了一个印象特别深的坑。下载线程从HTTPS下载数据然后调用HAL_FLASH_Program往Bank 2写数据，结果整个系统频繁出现“卡死”——LED不闪了，串口没有输出，看门狗也没喂上，然后复位重来。

查了一天，最后定位到问题在STM32H7的Flash操作机制上。H7在擦除或编程Flash时，CPU会阻塞等待BSY标志清空。在单Bank模式下，如果代码本身就在Flash里执行，擦写会让整个MCU停在Flash控制器的等待循环里，RTOS调度器也停了。所以在Flash擦写期间，其他线程根本没有机会运行。

解决办法是：让Flash擦写操作只在一个高优先级线程里执行，并且在这个线程执行擦写期间，其余任务绝对不能有任何时间敏感的实时操作。更稳妥的做法是，把擦写这一小段代码放到SRAM里执行，这样CPU从SRAM取指，不用等Flash控制器释放，RTOS就能正常工作。

我在工程里加了一个section，把Flash操作的函数放到RAM里：

__attribute__((section(".ramfunc"))) void flash_write_block(uint32_t dest, uint32_t *src, uint32_t len) { // HAL_FLASH_Program等操作 }

实测效果立竿见影，写Flash的同时，其他任务稳稳地运行，再也没有卡死的现象。

6.2 下载到一半掉线：进度记录在哪儿

前面提到过断点续传，但实现时有个细节差点让我翻车：进度offset，写到哪里最安全？

我一开始把进度直接放到参数区的固定地址，但问题是，每下载一个块都要擦写一次参数区，而H7的内部Flash擦写寿命约1万次，512KB固件要被4KB切块的话等于128次擦写，虽然理论上寿命够，但高频擦写同一个区域总会让人不放心。

后来我改成了双缓冲结构：把进度写入参数区的两个独立区域，交替使用。第一次写A，第二次写B，第三次写A……每次在写之前先读两个区域的版本号，保留版本号大的那个。这样即使写入过程中意外掉电，另一个区域的数据还是完整的，不会把进度写坏。

6.3 断电瞬间：最后1个sector的灾难

这是我在做断电测试时发现的最严重问题。模拟新固件下载到90%、人为断电，重新上电后，Bootloader加载了升级标志，准备从Bank 2启动——结果直接死循环。

查了一遍发现，罪魁祸首是“最后1个sector”。固件数据是分sector写入的，但最后一个4KB块可能只占了sector的一小部分。断电时，这个sector处于“擦除过但没写全”的状态。Bootloader启动时，如果直接用这个不完整的sector计算SHA256，摘要必然对不上，然后它不知道该回滚还是继续等，行为就不可控了。

解决办法分两层：

• 下载完成后，对固件末尾做“补齐写入”：将最后一个sector的剩余部分全部填0xFF，确保整个镜像数据连续完整。

• Bootloader在校验前先检查固件包的头部信息和文件大小，如果文件大小对应的最后一个sector存在未写完的数据，直接判定“固件包不完整”，走回滚流程。

这两条加在一起，断电场景就基本被兜住了。

6.4 验证结果与回滚策略的最终形态

最终版本的升级链路，我在实验室里做了多轮测试，覆盖了这些场景：

这套回滚策略的最终形态，总结起来就是一句话：每一步失败都有明确的兜底，而不是寄希望于“下次运气好”。从HTTPS断点续传、Flash双Bank写入、SHA256验签、Bootloader启动计数到App自检确认，每一层都设了一道保险。整个链路虽然长，但每一段的职责单一，排查问题也很快。

最后分享一点个人的经验吧。做这套升级系统时，最深的体会是：远程升级里，真正的难点不在于“把数据写进Flash”，而在于“写进去了之后，怎么保证能安全地跑起来、跑不起来怎么安全地退回来”。回滚策略的价值，往往要到量产设备真正出现固件事故的那一刻才体现出来。如果你是第一次在STM32上做OTA，我建议你先别急着写代码，把本文里的分区表、状态机、回滚计数这三个设计文档定下来，再动手。这三个东西想清楚了，后面的实现全部都顺理成章。