企业官网建设流程全解析

1. 这不是“讲启动流程的课”，而是一套嵌入式固件工程师的实战生存手册

你手里的开发板突然卡在 logo 画面不动，串口只输出几行乱码就沉默；OTA 升级后设备变砖，连 JTAG 都连不上；客户现场反馈“某型号设备批量启动失败”，但实验室里一百台都测不出问题——这些不是玄学，是固件工程师每天要面对的真实战场。我干嵌入式固件开发十年，从 STM32 小系统做到 i.MX8 多核 SoC，踩过最深的坑从来不是代码写错，而是对启动流程的理解停留在“复位→跳转→main”这句教科书式描述上。这门专栏标题里写的“启动流程深度拆解・故障定位方法论・OTA 升级工程化实战”，每一个词背后都是血泪经验：所谓“深度拆解”，是指把 Cortex-M4 的向量表重映射、i.MX6 的 IVT（Image Vector Table）签名验证、全志 Hifi4 DSP 的 BootROM 加载顺序，全部拉到寄存器级看数据流；所谓“方法论”，不是教你背几个命令，而是建立一套可复用的故障树——比如串口无输出，先查时钟源是否启用，再查 UART 引脚复用配置，再查 BootROM 是否因校验失败跳过 UART 初始化；所谓“工程化实战”，意味着 OTA 不是“下载+擦写+跳转”三步走，而是要考虑断电保护、版本回滚、差分包压缩率、烧录失败后的安全降级路径。这门课面向的不是刚学完《C 语言程序设计》的学生，而是已经能写驱动、调通外设，却在量产阶段被启动异常、升级失败、固件安全审计卡住的中级工程师。如果你正被“为什么 bootloader 跳转后 PC 指针飞了”、“OTA 升级后 Flash 某个扇区数据异常”、“客户设备在低温环境下启动概率性失败”这类问题反复折磨，那这门课就是为你写的——它不教你怎么“学会”，而是帮你把“会”变成“稳”。

2. 启动流程拆解：从复位信号到 main() 的每一步，都在决定你的固件是否可靠

2.1 启动流程的本质不是“顺序执行”，而是“信任链传递”

很多人把启动流程理解成一条线性路径：复位 → BootROM → Bootloader → Kernel → App。这是致命误区。真实世界里，启动是一个多层级信任链（Chain of Trust）的逐级验证与移交过程。每一级都必须确认下一级的完整性、合法性、来源可信性，才肯交出控制权。这个链条一旦断裂，设备要么拒绝启动（安全模式），要么启动后行为不可控（被篡改固件）。以 i.MX6Q 为例，其启动流程包含至少 5 个关键信任锚点：

• BootROM：固化在芯片内部的只读代码，出厂即定，无法修改。它首先检查外部存储器（如 eMMC、SPI NOR）的特定偏移地址是否存在合法 IVT（Image Vector Table）。IVT 不是普通数据，它包含镜像入口地址、DCD（Device Configuration Data）指针、HAB（High Assurance Boot）签名公钥哈希值。BootROM 用内置公钥验证 IVT 签名，若失败则进入 USB 下载模式或报错。

• DCD 表：紧随 IVT 之后，是一段用于初始化关键硬件的指令序列。它告诉 BootROM “如何配置 DDR 控制器、时钟树、GPIO 复用”。注意：DCD 是由 BootROM 解析并执行的，不是由后续 bootloader 执行。如果 DCD 配置错误（如 DDR 初始化参数与实际颗粒不匹配），BootROM 可能成功加载 bootloader，但后续因内存访问异常导致崩溃，且错误发生在 bootloader 之前，常规调试手段完全失效。

• HAB 签名验证：BootROM 验证完 IVT 后，会继续验证整个 bootloader 镜像的签名。签名算法通常是 SHA256 + RSA2048，私钥由厂商或项目组严格保管。这意味着即使你编译出功能完美的 bootloader，若未用正确私钥签名，BootROM 会直接丢弃它，设备黑屏。我在做某安防摄像头项目时，就因签名工具链版本升级导致签名格式微变，产线 2000 台设备全部变砖，返工成本超 30 万。

• Bootloader（如 U-Boot）：它拿到控制权后，第一件事不是初始化外设，而是验证 kernel 和 rootfs 的签名。U-Boot 的bootz命令本质是调用verify_image函数，用预置在环境变量中的公钥验证 FIT（Flattened Image Tree）头的签名。这里有个关键细节：U-Boot 自身的签名密钥和 kernel 的签名密钥可以不同，形成多级密钥体系，便于密钥轮换。

• Kernel 内核：Linux 内核启动后，可通过 IMA（Integrity Measurement Architecture）模块对用户空间二进制文件进行运行时完整性校验。这已超出传统启动流程范畴，但它是信任链的自然延伸——启动可信，不等于运行可信。

提示：信任链的每一环都可能成为故障点。排查启动失败，不能只盯着“main() 没执行”，而要像法医一样，逐级检查：BootROM 是否识别到 IVT？DCD 是否成功执行？HAB 验证日志是否显示 signature error？U-Boot 是否打印Verified kernel image？这些信息通常通过串口早期 log 或专用 debug 接口获取，而非常规 printf。

2.2 Cortex-M 内核启动：向量表重映射是绝大多数“跳转失败”的根源

Cortex-M 系列（M0/M3/M4/M7）的启动流程看似简单：复位后，CPU 从地址 0x00000000 读取 MSP 初始值，从 0x00000004 读取复位向量（Reset Handler 地址），然后跳转执行。但问题在于，0x00000000 这个地址，在绝大多数商用 MCU 上，并不指向你的 Flash 起始地址。例如 STM32F407，Flash 起始地址是 0x08000000；NXP LPC54608，Flash 起始是 0x00000000，但 SRAM 也映射到 0x20000000。这就引出了向量表重映射（Vector Table Remap）机制。

• 默认映射：复位后，CPU 总是从 0x00000000 开始取向量表。此时，MCU 厂商通过硬件设计，将该地址映射到 Flash（如 STM32）或 ROM（如 NXP LPC 系列的 BootROM）。所以你的 startup 文件中定义的__Vectors符号（即向量表）必须放在链接脚本指定的 Flash 起始位置，否则 CPU 读到的是一堆垃圾数据，PC 指针直接飞掉。

• 重映射触发：当你的 bootloader 需要跳转到应用固件（App）时，App 的向量表通常不在 Flash 起始，而在某个偏移地址（如 0x08008000）。此时，你必须在跳转前，手动修改 SCB->VTOR（Vector Table Offset Register）寄存器，将其指向 App 的向量表基址。这是几乎所有 Cortex-M bootloader 的核心操作，也是新手最容易遗漏的步骤。我见过太多案例：bootloader 成功跳转，但 App 的 SysTick 中断不触发、NVIC 配置无效，根本原因就是忘了写 VTOR。

• 重映射陷阱：VTOR 寄存器的低 7 位必须为 0（即向量表必须 128 字节对齐）。如果你的 App 向量表起始地址是 0x08008008，直接写入 VTOR 会导致 CPU 异常。正确做法是：SCB->VTOR = (uint32_t)0x08008000;，即取对齐后的基址。

• Stack Pointer 设置：跳转前，必须从 App 向量表的第 0 个字（地址 offset 0x00）读取 MSP 初始值，并写入 MSP 寄存器。这是 C 运行时环境初始化的前提。很多 bootloader 只设置 PC，忽略 MSP，导致 App 启动后栈溢出或访问非法地址。

以下是一个典型的 Cortex-M bootloader 跳转函数（以 STM32F4 为例）：

typedef void (*pFunction)(void); void JumpToApplication(uint32_t applicationAddress) { uint32_t jumpAddress = *(__IO uint32_t*)(applicationAddress + 4); // 复位向量地址（offset 0x04） pFunction Jump_To_Application = (pFunction)jumpAddress; // 1. 关闭所有中断 __disable_irq(); // 2. 设置主堆栈指针 MSP __set_MSP(*(__IO uint32_t*)applicationAddress); // 从 offset 0x00 读取 MSP // 3. 设置向量表偏移 SCB->VTOR = applicationAddress; // 必须是 128 字节对齐地址 // 4. 清除所有外设时钟使能（可选，但强烈建议） RCC->AHB1ENR = 0; RCC->AHB2ENR = 0; RCC->APB1ENR = 0; RCC->APB2ENR = 0; // 5. 跳转 Jump_To_Application(); }

实操心得：在调试跳转失败时，不要急着看 App 代码，先用 JTAG 在Jump_To_Application()调用前打个断点，用调试器查看：

• *(__IO uint32_t*)applicationAddress的值是否合理（应为一个较大的 RAM/Flash 地址）？
• *(__IO uint32_t*)(applicationAddress + 4)的值是否指向 App 的 Reset_Handler 符号？
• SCB->VTOR的值是否已更新为applicationAddress？ 这三个检查点，能快速定位 90% 的跳转问题。

2.3 SoC 启动流程：i.MX6 与全志 Hifi4 的“启动密码”完全不同

MCU 和 SoC 的启动哲学有本质区别：MCU 启动是“确定性”的，SoC 启动是“可配置性”的。i.MX6 和全志 Hifi4 代表了两种典型范式。

• i.MX6 的 IVT + DCD + Boot Data 三位一体：

  • IVT（Image Vector Table）：固定 32 字节结构，包含header（魔数 0x402000D1）、entry（入口地址）、reserved1、dcd_ptr（DCD 表地址）、boot_data_ptr（Boot Data 地址）、self（IVT 自身地址）、csf_ptr（签名认证表地址）等字段。它的存在位置由 BOOT_MODE 引脚决定：eMMC 模式下，IVT 在 eMMC 分区 0 的 0x400 偏移；NAND 模式下，在 NAND 第一个块的 0x400 偏移。IVT 的self字段必须等于其实际物理地址，否则 BootROM 拒绝加载。这是一个极易被忽略的硬性要求。
  • DCD（Device Configuration Data）：一段由 BootROM 解析的二进制指令流，用于配置 DDR、时钟、GPIO。DCD 指令集是 i.MX6 特有的，不是通用汇编。例如，配置 DDR PHY 的某寄存器，需要一条WRITE_DATA指令，指定目标地址、数据、掩码。DCD 错误不会导致 BootROM 报错，但会导致后续 bootloader 因内存不可用而崩溃，且崩溃点飘忽不定。
  • Boot Data：告诉 BootROM 如何从存储器读取后续镜像。例如，对于 eMMC，它包含分区号、起始扇区、读取长度等信息。如果 Boot Data 中的扇区号计算错误，BootROM 会读取到错误的数据，导致 bootloader 解析失败。

• 全志 Hifi4 DSP 的 BootROM 加载逻辑： 全志芯片（如 A33, R16）的启动更依赖于固件布局规范。其 BootROM 会按固定顺序扫描外部存储器（SPI NOR > SD Card > eMMC）的特定扇区（通常是 LBA 0 和 LBA 1），寻找名为boot0和boot1的镜像。boot0是一个极小的二级 bootloader，负责初始化 DDR 并加载boot1；boot1才是真正的 U-Boot 或自定义 bootloader。Hifi4 的关键在于boot0的大小和校验方式：它必须小于 32KB，且头部包含 CRC32 校验值。如果boot0编译后超过 32KB，或 CRC 计算错误，BootROM 会直接跳过该存储器，尝试下一个。

注意：i.MX6 的 IVT 和 DCD 生成，官方推荐使用elftosb工具，但它对输入 ELF 文件的段布局有严格要求。我曾因 linker script 中.text段未按ALIGN(4)对齐，导致elftosb生成的 SB（Signed Binary）文件在 BootROM 加载时校验失败。解决方案是：在链接脚本中，对所有关键段（.text,.rodata,.data）强制添加ALIGN(4)，并在elftosb命令中指定-o输出选项确保对齐。

3. 故障定位方法论：建立你的“嵌入式启动故障树”，告别盲目 printf

3.1 为什么 printf 在启动早期是“伪朋友”？

新手最常用的调试手段是加printf("here 1\n")，但这在启动流程中极具欺骗性。原因在于：printf依赖完整的 C 运行时环境（_init、stdout初始化、缓冲区分配），而启动早期（尤其是 BootROM 和 bootloader 初期）这些环境根本不存在。你看到的“成功打印”，往往是因为 bootloader 已经完成了 UART 初始化，并启用了半主机（semihosting）或重定向了stdout。一旦你修改了 bootloader 的初始化顺序，或者在更早的阶段（如 reset handler）加printf，它就会静默失效，甚至导致系统挂起。

真正的启动早期调试，必须回归到硬件级可观测性：

• LED 指示灯：在 reset handler 中，直接操作 GPIO 寄存器点亮 LED。这是最原始、最可靠的信号。我习惯在Reset_Handler的第一行，用汇编指令ldr r0, =0x400F6000（STM32F4 的 GPIOE 基址）mov r1, #0x00000001str r1, [r0, #0x10]（BSRR 寄存器置位）点亮一个 LED。如果 LED 不亮，说明连 reset handler 都没执行，问题在硬件或 BootROM 阶段。

• 逻辑分析仪抓取 UART 波形：不要依赖终端软件，用 Saleae 或 Siglent 逻辑分析仪直接捕获 UART TX 引脚的波形。你可以看到：

  • BootROM 是否发送了初始的USB DL字符串（表示进入下载模式）？
  • bootloader 是否发出了U-Boot 2020.10的 banner？
  • kernel 是否打印了Starting kernel ...？ 如果波形中只有零星几个字符，说明 UART 初始化失败或波特率不匹配。

• JTAG/SWD 实时寄存器监控：在调试器中，不设置断点，而是开启“实时寄存器视图”，观察关键寄存器的变化：

  • SCB->VTOR：确认向量表是否已重映射。
  • RCC->CR/RCC->CFGR：确认 HSE/HSI 是否已就绪，PLL 是否已锁定。
  • RCC->AHB1ENR：确认 GPIO、USART 时钟是否已使能。
  • GPIOx->MODER/GPIOx->AFR：确认 UART 引脚是否配置为复用功能。

实操心得：我给自己定了一条铁律——任何启动问题，先用 LED 和逻辑分析仪确认问题发生在哪一级。LED 不亮 → BootROM 阶段；LED 亮但无 UART 输出 → bootloader UART 初始化失败；UART 有 banner 但 kernel 不启动 → kernel 镜像损坏或 DTB 错误。这套方法让我在 2 小时内定位了 95% 的启动问题，远快于反复修改printf和烧录。

3.2 构建你的嵌入式启动故障树（BST）

故障树（Fault Tree）是一种自顶向下、逐层分解的逻辑分析工具。我们将“设备无法启动”作为根节点，分解为 3 个主要分支：硬件问题、BootROM 阶段失败、Bootloader 阶段失败。每个分支再细化，最终指向可验证的具体操作。

3.2.1 硬件问题分支（占比约 15%）

• 电源问题：

  • 测量所有电源轨（VDD_CORE, VDD_IO, VDDA）的电压和纹波。尤其注意 VDDA（模拟电源），它影响 ADC 和内部 RC 振荡器。
  • 检查复位电路：复位芯片（如 TPS3823）的 RESET_OUT 信号是否在上电后有干净的脉冲？用示波器看上升沿是否陡峭（<100ns）？是否有振铃？

• 时钟问题：

  • 用示波器探头（10x 档）测量晶振两端波形。正常应为清晰正弦波，幅度 > 0.5Vpp。如果波形平直或畸变，可能是负载电容不匹配或晶振损坏。
  • 检查 BootROM 是否因时钟不稳定而跳过初始化。某些 MCU 的 BootROM 有“时钟稳定性检测”，若 HSE 启动超时，会 fallback 到内部 RC，导致后续 PLL 配置失败。

• 存储器问题：

  • SPI NOR：用 Flash 编程器读取前 64KB，检查是否全是 0xFF（未编程）或全 0x00（擦除失败）。
  • eMMC：用mmc info命令（在 U-Boot shell 中）检查 eMMC 是否被识别，CID/CSD 寄存器是否有效。

3.2.2 BootROM 阶段失败分支（占比约 40%，最棘手）

• IVT/DCD/Boot Data 错误（i.MX6）：

  • 使用imx_usb_loader工具，强制让设备进入 USB 下载模式，然后用sb_loader发送一个最小的、已知正确的 SB 文件。如果成功，证明硬件正常，问题在你的镜像。
  • 用hexdump -C your_image.bin | head -20检查 IVT 的魔数40 20 00 d1是否在正确偏移（eMMC 模式下是 0x400）。
  • 用imximage工具（Yocto SDK 提供）反编译 DCD 表，确认其指令是否符合芯片手册要求。

• 签名验证失败（HAB Error）：

  • i.MX6 的 HAB 错误会通过 UART 输出类似HAB Warning: Failed to authenticate data的字符串。但有时 BootROM 会静默失败。此时，用 JTAG 连接，查看HAB_STATUS寄存器（地址 0x00000000）的值。0x12表示签名验证失败，0x33表示 IVT 格式错误。

• BootROM 未找到有效镜像：

  • 检查 BOOT_MODE 引脚电平。用万用表测量，确认是强上拉/下拉，而非浮空。
  • 检查存储器连接：SPI NOR 的 CS、CLK、DO、DI 引脚是否虚焊？eMMC 的 CMD、CLK、DAT0-DAT7 是否有短路？

3.2.3 Bootloader 阶段失败分支（占比约 45%，最常见）

• UART 无输出：

  • 检查 bootloader 的CONFIG_SYS_CONSOLE配置是否正确指向你的 UART 设备（如CONFIG_SYS_CONSOLE_IS_IN_ENV=y且console=ttymxc0）。
  • 检查board_init_f函数中，UART 初始化代码是否被执行？在uart_init()函数入口加 LED 指示。

• U-Boot 停留在Hit any key to stop autoboot：

  • 这表明 U-Boot 主循环已运行，但bootcmd环境变量执行失败。用printenv bootcmd查看其内容，再手动执行run bootcmd，观察具体哪一步失败（如fatload mmc 0:1 ${loadaddr} uImage报错** Unable to read file uImage **）。

• Kernel Panic：

  • 最常见的原因是 Device Tree Blob（DTB）与 kernel 不匹配。用fdtget工具检查 DTB 中的compatible字符串是否与 kernel 的MACHINE_START匹配。
  • 检查bootargs环境变量：root=/dev/mmcblk0p2是否指向正确的 rootfs 分区？console=ttyS0,115200的设备名是否正确（ttyS0vsttymxc0）？

提示：故障树不是一成不变的。每次解决一个新问题，都要把它加入你的个人 BST 文档中。我维护了一个 Markdown 文件，记录了 37 个真实案例，包括“i.MX6Q 在 -40°C 启动失败，原因是 DCD 中 DDR PHY 的温度补偿参数未启用”，这让我在后续项目中，一看到低温需求，就立刻检查 DCD 的TEMP_COMP字段。

4. OTA 升级工程化实战：从“能升级”到“敢升级”的跨越

4.1 OTA 的本质不是“传输协议”，而是“状态机管理”

绝大多数 OTA 方案失败，不是因为 HTTP 下载慢，而是因为没有把升级过程建模为一个健壮的状态机。一个合格的 OTA 状态机，必须包含至少 7 个核心状态和明确的转换条件：

1. IDLE（空闲）：设备正常运行，等待升级指令。
2. DOWNLOADING（下载中）：HTTP/HTTPS 下载固件包，同时计算 SHA256 校验和。
3. VERIFYING（校验中）：比对下载包的 SHA256 与服务器下发的摘要。此步骤必须在 RAM 中完成，严禁在 Flash 上直接校验，因为 Flash 读取速度慢且可能受干扰。
4. PREPARING（准备中）：擦除目标 Flash 扇区，备份当前固件（可选），关闭所有非必要外设（如 WiFi、蓝牙）。
5. WRITING（写入中）：将固件包解密（如有）、解压缩（如有），逐块写入 Flash。每写入一块（如 4KB），必须立即读回校验，确保写入正确。
6. VALIDATING（验证中）：升级完成后，对整个新固件区域进行 CRC32 或 SHA256 校验。
7. REBOOTING（重启中）：设置重启标志（如在 RTC 备份寄存器中写入0xDEADBEAF），然后调用NVIC_SystemReset()。

状态机的关键在于状态持久化。如果设备在WRITING状态时断电，重启后必须能从断点恢复，而不是从头开始。这要求：

• 每个状态变更，都必须原子性地写入一个非易失性存储器（如 EEPROM、Flash 的专用配置区、RTC 备份寄存器）。
• 状态存储区必须有冗余（如双备份），并用 CRC 保护，防止位翻转。

以下是一个简化的 OTA 状态机伪代码框架：

typedef enum { OTA_IDLE = 0, OTA_DOWNLOADING, OTA_VERIFYING, OTA_PREPARING, OTA_WRITING, OTA_VALIDATING, OTA_REBOOTING } ota_state_t; // 状态存储在 RTC 备份寄存器 BKP_DR1 #define OTA_STATE_REG (&(RTC->BKP_DR1)) void ota_state_machine(void) { ota_state_t current_state = (ota_state_t)*OTA_STATE_REG; switch(current_state) { case OTA_IDLE: if (ota_upgrade_flag) { ota_download_start(); *OTA_STATE_REG = OTA_DOWNLOADING; // 触发下载任务 } break; case OTA_DOWNLOADING: if (download_complete && download_sha256_ok) { *OTA_STATE_REG = OTA_VERIFYING; ota_verify_firmware(); } else if (download_failed) { ota_set_error(OTA_ERR_DOWNLOAD); *OTA_STATE_REG = OTA_IDLE; } break; case OTA_VERIFYING: if (sha256_match) { *OTA_STATE_REG = OTA_PREPARING; ota_prepare_flash(); } else { ota_set_error(OTA_ERR_VERIFY); *OTA_STATE_REG = OTA_IDLE; } break; // ... 其他状态处理 case OTA_REBOOTING: // 此状态只在重启前瞬间设置，重启后由 bootloader 读取 break; } } // Bootloader 启动时检查 OTA 状态 void bootloader_check_ota(void) { if (*OTA_STATE_REG == OTA_REBOOTING) { // 从备份区加载新固件，跳转执行 jump_to_application(NEW_FIRMWARE_ADDR); } }

注意：状态机必须有超时机制。例如，DOWNLOADING状态持续超过 300 秒，自动转入OTA_IDLE并上报错误。否则，一个卡死的下载任务会永久阻塞整个系统。

4.2 差分升级（Delta OTA）：不是“锦上添花”，而是“量产刚需”

全量 OTA（Full OTA）升级一个 8MB 的固件，对带宽和电量都是巨大消耗。差分升级（Delta OTA）通过只传输新旧固件之间的差异部分，将升级包体积压缩到原来的 10%-30%。其核心是bsdiff/bspatch算法。

• bsdiff 原理：它不是简单的二进制 diff，而是基于最长公共子序列（LCS）和滚动哈希。bsdiff会将旧固件（old.bin）和新固件（new.bin）都分割成固定大小的块（如 8KB），然后为每个块计算一个弱哈希（Adler32）和强哈希（SHA1）。接着，它寻找两个文件中哈希匹配的块，构建一个“复制指令列表”，再对剩余的不匹配数据生成“新增数据块”。最终的差分包（delta.bin）包含：复制指令、新增数据、以及一个“控制块”（control block），告诉bspatch如何重组。

• 实操挑战：

  • Flash 对齐：bsdiff默认假设文件是字节对齐的，但固件镜像通常有严格的扇区对齐要求（如 4KB）。如果 old.bin 和 new.bin 的 Flash 布局（如 IVT 位置、签名位置）有微小变化，bsdiff会产生巨大的差分包。解决方案：在 diff 前，用objcopy工具将固件的.text、.rodata等段提取出来，只对这些“可变”段做 diff，而将.ivt、.signature等“固定”段单独处理。

  • 内存限制：bspatch在嵌入式设备上运行时，需要 RAM 来缓存 old.bin 的哈希表和 delta.bin 的控制块。一个 8MB 固件的差分包，bspatch可能需要 2MB RAM。对于 RAM 仅 256KB 的 MCU，这是不可接受的。解决方案：采用流式bspatch，即边读 delta.bin 边 patch，不缓存整个 old.bin。这需要修改bspatch源码，使其支持seek操作。

• 安全考量：差分包本身也需要签名。不能只签 delta.bin，因为攻击者可以篡改 delta.bin，导致 patch 出恶意代码。正确做法是：服务器生成 delta.bin 后，用私钥对其 SHA256 摘要签名，将签名附加在 delta.bin 末尾。设备端下载后，先验证签名，再执行bspatch。

我主导的一个智能电表项目，固件从 4.2MB 升级到 4.5MB。全量 OTA 平均耗时 8 分钟（GPRS 网络），失败率 12%。引入差分 OTA 后，delta 包平均 1.1MB，耗时降至 2 分钟，失败率 < 0.5%。关键是，我们实现了“断点续传差分”：bspatch过程中，每 patch 完一个 4KB 块，就将当前进度（已 patch 块数、CRC）写入 EEPROM。断电后，重启时从断点继续，无需重传整个 delta 包。

4.3 OTA 的“最后一公里”：安全降级与回滚机制

OTA 升级最危险的时刻，不是下载，而是写入。一旦新固件写入 Flash 后校验失败，设备必须有能力回到一个已知的、可工作的状态。这就是安全降级（Safe Rollback）。

• 双 Bank 架构：这是最可靠的方案。Flash 被划分为两个同等大小的 Bank（Bank A 和 Bank B）。当前运行固件在 Bank A，则 OTA 升级包写入 Bank B。升级完成后，通过修改一个“active bank flag”（存储在独立的配置区），让 bootloader 下次从 Bank B 启动。如果 Bank B 启动失败（如校验失败、HardFault），bootloader 检测到失败标志，自动切换回 Bank A。Bank 切换必须是原子操作，flag 的写入必须有 CRC 保护，并采用“先写新值，再擦旧值”的策略，防止写入一半断电。

• 单 Bank + 备份区：对于 Flash 空间紧张的设备，可在 Bank 内划分出一个“backup sector”。OTA 开始前，将当前固件的关键部分（如 IVT、reset vector、startup code）备份到 backup sector。升级失败时，bootloader 从 backup sector 恢复这些关键部分，保证设备能再次启动。

• 回滚触发条件：不能仅靠“启动失败”来判断。更健壮的做法是：新固件启动后，运行一个health_check()函数，检查：

  • 关键外设（如传感器、通信模块）是否初始化成功？
  • 系统内存使用率是否低于阈值（< 70%）？
  • 是否能在规定时间内（如 30 秒）完成