📚 课程目录第3章物联网终端硬件与软件架构

3、物联网终端硬件与软件架构：MCU/MPU、通信模组、存储分区、Bootloader与应用程序的协作关系

物联网终端的OTA升级能力并非单纯依赖软件协议，而是建立在硬件资源与底层软件架构的精密配合之上。理解MCU/MPU的计算边界、通信模组的升级通道、存储分区的冗余策略以及Bootloader的引导机制，是设计可靠远程升级方案的前提。本章将拆解这四类核心组件的职责边界与协作流程，帮助工程师在方案设计初期就规避“升级变砖”“断电损坏”“回滚失效”等典型风险。

3.1 主控单元选型：MCU与MPU的升级能力边界

物联网终端的主控芯片决定了OTA升级的实现复杂度。MCU（如STM32F4、ESP32、GD32）通常集成Flash和SRAM，采用Cortex-M内核，适合执行逻辑相对固定的固件升级；MPU（如i.MX6ULL、全志V3s）则运行Linux或RTOS，具备MMU和外部存储接口，升级对象往往是整个根文件系统或内核镜像。选型时需重点评估三个维度：Flash容量是否支持双分区镜像、RAM大小能否容纳升级包解压缓冲、算力是否满足签名校验（RSA-2048在Cortex-M4上约需200ms）。

对比维度	MCU方案	MPU方案
升级对象	固件镜像（bin/hex）	内核+设备树+根文件系统
典型Flash需求	512KB - 4MB	128MB - 4GB (eMMC)
升级包传输	整包或差分（Delta）	整包或增量（ostree）
回滚机制	双Bank切换	U-Boot + rootfs A/B
升级失败恢复	Bootloader强制恢复	recovery分区 + 工厂镜像

对于MCU方案，建议预留至少2倍固件大小的Flash空间用于双分区；对于MPU方案，则需规划独立的recovery分区（通常64MB以上），并确保U-Boot具备从recovery引导的能力。实际项目中，若MCU Flash不足，可考虑外挂SPI NOR Flash（如W25Q128）作为升级暂存区，但需注意SPI读写速度对升级时长的影响。

3.2 通信模组的升级通道设计

通信模组（如移远EC200U、广和通L610）承担升级包的下载任务。设计时需明确模组与主控的接口方式：UART是最常见的选择，但波特率通常限制在921600bps以内；USB可提供更高吞吐（12Mbps），但需要主控具备USB Host能力；SPI从模式适合高速场景，但驱动复杂度较高。模组固件本身也可能需要升级，此时需区分“主控升级”和“模组升级”两条独立通道。

关键设计决策：升级包下载路径有两种方案。方案A：模组直接下载到外部Flash（通过模组GPIO模拟SPI），主控不参与数据搬运，适合低功耗场景；方案B：模组通过AT指令将数据分片透传给主控，由主控写入Flash，便于实现断点续传和加密处理。推荐优先采用方案B，因为主控可对数据进行实时校验，且不依赖模组厂商的私有协议。

通信模组还需关注连接保持策略。升级过程中若网络中断，应支持断点续传（记录已接收分片序号），同时设置超时重连机制。对于NB-IoT等低带宽网络，建议将升级包压缩（如LZMA）后再传输，压缩率通常可达40%-60%。

3.3 存储分区规划：双A/B分区与标志位管理

存储分区是OTA升级安全性的基石。典型的MCU Flash布局包含：Bootloader区（64KB-256KB）、App A区（当前运行版本）、App B区（备用版本）、参数区（保存升级标志、版本号、回滚计数）。分区表建议固定在Flash起始地址，由Bootloader在启动时读取并校验。

// 典型STM32F4分区表（2MB Flash）
0x08000000 - 0x08003FFF  Bootloader (16KB)
0x08004000 - 0x08007FFF  参数区 (16KB, 含升级标志)
0x08008000 - 0x0807FFFF  App A (480KB)
0x08080000 - 0x080FFFFF  App B (512KB)
// 注意：App A和App B大小需一致，便于地址映射

升级标志位建议使用双字冗余存储（写入两次，读取时比对），防止写入过程中断电导致标志损坏。标志状态机包括：IDLE（无升级）、READY（新固件已就绪）、COMMIT（确认运行成功）、ROLLBACK（需要回滚）。Bootloader根据标志状态决定引导哪个分区。

常见误区：部分工程师将升级标志直接存储在App分区末尾，这会导致App升级时标志被覆盖。正确做法是使用独立参数区，并采用磨损均衡算法（如记录写入次数，轮换使用多个扇区），避免频繁擦写导致Flash损坏。

3.4 Bootloader与应用程序的协作机制

Bootloader是OTA升级的“总指挥”，其核心职责包括：硬件初始化（时钟、串口、Flash控制器）、升级包接收（通过UART/SPI/USB）、固件写入（擦除、编程、校验）、启动引导（根据标志选择App分区）。应用程序则需配合实现升级触发（接收服务器指令）、状态上报（上报当前版本和升级进度）、看门狗喂狗（防止升级过程中死机）。

协作流程通常如下：

应用程序收到升级指令后，将固件包分片写入App B区，每片写入后回读校验。
全部写入完成后，应用程序在参数区写入READY标志，然后软复位。
Bootloader启动后检查标志：若为READY，则引导App B，并将标志改为COMMIT。
App B运行后，主动向服务器上报版本号；若服务器确认成功，则App B将标志改为IDLE。
若App B在启动后30秒内未上报成功（或触发看门狗复位），Bootloader检测到COMMIT标志超时，自动回滚至App A。

经验提醒：回滚机制必须设置“尝试次数上限”（如3次）。若App B连续3次启动失败，应停止自动回滚，进入紧急恢复模式（通过串口或USB强制刷机），避免无限重启消耗电量。

3.5 实战案例：智能电表双分区升级失败恢复

背景：某电力公司智能电表采用STM32L476 + 4G模组（EC200U），Flash为1MB，原方案仅使用单分区。一次远程升级中，因服务器推送了损坏的固件包，导致电表启动后立即死机，现场运维需逐一拆表烧录，造成巨大损失。

改造方案：

重新划分Flash：Bootloader 32KB + 参数区 8KB + App A 480KB + App B 480KB。
Bootloader增加CRC32校验和启动超时检测（App启动后需在10秒内清除“启动失败”标志）。
升级流程改为：先下载至App B，校验通过后置位READY，重启后由Bootloader引导。
增加回滚计数：若App B连续2次启动失败，则永久回退至App A，并上报服务器“升级失败”事件。

结果：后续一次升级中，服务器推送了不兼容的固件，电表在App B启动后3秒内触发看门狗复位，Bootloader检测到异常后自动回滚至App A，电表恢复正常计量功能，运维人员仅需远程查看日志即可定位问题，无需现场干预。

复盘经验：单分区方案在OTA场景下风险极高，双分区虽增加约50%的Flash成本，但换来了远程自愈能力。此外，回滚触发条件不能仅依赖看门狗，应结合“应用程序主动上报失败”和“Bootloader超时检测”双重机制，确保覆盖所有异常路径。

3.6 常见误区与设计复盘

在硬件与软件架构设计中，以下问题需特别警惕：

误区一：忽略Flash擦写寿命。Flash擦写次数通常为10万次，若升级频繁且未做磨损均衡，参数区可能提前损坏。建议使用静态磨损均衡算法，并监控擦写次数。
误区二：Bootloader不支持升级。若Bootloader本身存在Bug，将无法修复。建议将Bootloader设计为可升级（通过独立的Bootloader升级通道），或至少保证其足够精简稳定。
误区三：通信模组与主控升级互相干扰。若模组固件升级和主控升级同时进行，可能导致数据通道冲突。应设计互斥机制，优先完成主控升级，再处理模组升级。
误区四：未考虑升级包加密。明文固件包易被逆向分析，建议使用AES-128-GCM加密传输，密钥预置于Bootloader中。

总结而言，硬件架构设计应遵循“冗余优先、校验前置、回滚兜底”的原则。MCU/MPU选型时预留足够Flash和RAM，通信模组选择支持断点续传的型号，存储分区采用双A/B布局，Bootloader实现完整的标志管理和回滚逻辑。只有这四层协作顺畅，OTA升级才能真正实现“无人值守、失败自愈”的工程目标。