2. 嵌入式系统基础

OTA升级的本质是在嵌入式设备运行过程中，对非易失性存储器中的代码和数据进行安全、可靠的在位更新。要设计出健壮的Bootloader和差分升级方案，首先必须深刻理解MCU的启动机制、Flash的物理特性、分区规划方法以及中断向量表的处理方式。本章将围绕这五个核心基础点展开，为后续的差分算法和回滚策略奠定坚实的工程认知。

2.1 MCU启动流程：从复位到main函数的必经之路

核心原理

以ARM Cortex-M系列为例，MCU上电或复位后，硬件逻辑会从地址0x00000000（或映射的Flash起始地址）读取初始栈指针（MSP），从地址0x00000004读取复位向量（Reset_Handler）。随后，CPU跳转到复位向量执行启动代码，依次完成：关闭看门狗、配置系统时钟、初始化SRAM、拷贝.data段、清零.bss段，最后调用__main进入C运行时环境，最终跳转到main()函数。这一过程对OTA设计的关键启示在于：复位向量和栈指针是启动的“第一桶金”，任何分区设计都必须保证这两项在Bootloader和App中各自独立且正确。

判断方法或操作流程

在实际工程中，可通过以下步骤验证启动流程的正确性：

1. 使用调试器（如J-Link、ST-Link）连接MCU，复位后查看PC寄存器和SP寄存器的值。
2. 确认PC指向的地址是否为Flash起始地址+4处的复位向量值。
3. 单步执行启动代码，观察时钟配置和存储器初始化是否按预期完成。
4. 在main()入口设置断点，确认C运行时环境已正确建立。

案例拆解：启动流程异常导致OTA后“变砖”

某车载T-Box产品在OTA升级后出现无法启动的问题。通过调试器连接发现，PC指针指向0xFFFFFFFF，SP为0x00000000。分析原因：App的链接脚本未正确设置Flash起始地址，导致编译出的向量表仍指向0x08000000，而该地址已被Bootloader占用。当Bootloader跳转到App时，读取到的“复位向量”实际上是Bootloader的代码数据，导致执行流错乱。解决方法是：在App的链接脚本中显式设置FLASH_ORIGIN = 0x08010000，并确保SCB->VTOR在App启动早期被重映射。

常见误区或总结复盘

• 误区一：认为所有MCU启动流程相同。实际上，不同厂商（ST、NXP、TI）和不同内核（Cortex-M0/M3/M4/M7）在启动细节上存在差异，如M0+不支持VTOR寄存器。
• 误区二：忽略Bootloader自身的启动时间。OTA场景下，Bootloader应尽量精简，避免复杂初始化，以缩短启动延迟。
• 复盘：启动流程是OTA的“地基”，任何分区调整都必须重新验证启动时序，建议在CI/CD流程中加入启动自检用例。

2.2 Flash存储器结构：物理特性与编程约束

核心原理

嵌入式Flash具有按扇区擦除、按字节/字编程的物理特性。以STM32F4系列为例，其Flash分为多个扇区，主存储器扇区大小从16KB到128KB不等。擦除操作会将整个扇区置为0xFF，而编程操作只能将1写为0（即只能从1变0，不能从0变1）。这意味着：在OTA升级中，不能直接覆盖旧代码，必须先擦除目标扇区，再写入新数据。此外，Flash的擦写寿命有限（通常为10万次），频繁擦写会缩短器件寿命，因此差分升级算法应尽量减少擦写次数。

判断方法或操作流程

在设计分区表前，需查阅芯片手册确认以下参数：

案例拆解：扇区大小不匹配导致的升级失败

某智能电表项目使用GD32F303，其Flash扇区大小为4KB。设计差分升级时，将App划分为两个“逻辑分区”，但未考虑物理扇区边界。当差分算法生成补丁时，发现一个逻辑分区的数据跨越了多个物理扇区，导致擦除操作必须覆盖相邻扇区，意外擦除了参数区数据。解决方案：在分区表设计阶段，强制所有分区起始地址与物理扇区边界对齐，并在差分算法中增加扇区映射表。

常见误区或总结复盘

• 误区一：将Flash当作RAM使用，频繁写入小数据。应使用Flash模拟EEPROM技术或外部EEPROM。
• 误区二：忽略编程电压和温度对Flash可靠性的影响。在极端温度下，Flash编程可能失败，需增加校验重试机制。
• 复盘：Flash物理特性是分区设计和差分算法的硬约束，必须在项目初期建立“Flash特性参数表”并纳入设计评审。

2.3 分区表设计：Bootloader、App与参数区的规划

核心原理

分区表是OTA升级的“地图”，它定义了Flash中各个区域的起始地址、大小和用途。一个典型的OTA分区表包含：Bootloader区、App A区、App B区（备份区）、参数区（升级标志、版本号、回滚计数）。分区设计需遵循以下原则：

• 对齐原则：所有分区起始地址必须与Flash扇区边界对齐，避免跨扇区操作。
• 冗余原则：至少保留一个App备份区，用于升级失败回滚。
• 隔离原则：参数区独立于代码区，防止代码写入时误擦除参数。

判断方法或操作流程

分区表设计流程如下：

1. 统计Bootloader最大体积（通常预留2倍余量）。
2. 统计App最大体积（考虑未来功能扩展）。
3. 确定参数区大小（至少4KB，用于存储标志位和版本信息）。
4. 根据Flash总容量，计算是否支持双App分区。
5. 在链接脚本和代码中定义分区起始地址宏。

案例拆解：分区表设计不当导致升级空间不足

某工业控制器使用512KB Flash，最初设计为Bootloader 32KB + App 480KB，无备份区。当产品需要增加新功能导致App体积膨胀至460KB时，OTA升级包无法在现有Flash中生成备份。被迫重新设计分区表，将Bootloader压缩至24KB，App A/B各244KB，但Bootloader功能裁剪后无法支持复杂的差分校验。最终方案：采用外部SPI Flash存储升级包，内部Flash仅保留单App+备份标志。此案例说明：分区表设计必须预留至少20%的余量，并考虑未来3~5年的功能演进。

常见误区或总结复盘

• 误区一：分区表固定不变。实际上，可通过Bootloader支持动态分区表读取，增加灵活性。
• 误区二：忽略参数区的磨损均衡。频繁擦写参数区会快速耗尽Flash寿命，建议使用双备份参数区或磨损均衡算法。
• 复盘：分区表是OTA架构的核心决策，建议使用表格形式在项目文档中明确记录，并纳入配置管理。

2.4 中断向量表重映射：让App正确响应中断

核心原理

ARM Cortex-M内核通过向量表偏移寄存器（VTOR）定位中断向量表。默认情况下，VTOR指向0x00000000（即Flash起始地址）。当App运行在非零地址时，必须将VTOR设置为App的起始地址，否则中断发生后CPU会从错误的向量表读取处理函数地址，导致系统崩溃。重映射操作通常在App启动早期（main()之前）完成。

判断方法或操作流程

在App代码中，重映射操作的标准流程如下：

// 以STM32为例，在SystemInit()或main()最早期执行
#define APP_BASE_ADDR  0x08010000u
SCB->VTOR = APP_BASE_ADDR;
__DSB();  // 数据同步屏障，确保VTOR写入生效

需注意：

• VTOR写入前，必须确认App的向量表已正确链接到APP_BASE_ADDR。
• 部分MCU（如Cortex-M0+）不支持VTOR，需通过Bootloader跳转时设置MSP和PC，或使用固定地址映射。
• 若使用RTOS，还需确保中断优先级分组设置正确。

案例拆解：中断向量表未重映射导致串口中断异常

某物联网网关在OTA升级后，串口通信间歇性失效。排查发现：App的USART1_IRQHandler未被调用，而是执行了默认的Default_Handler。原因：App代码中未设置VTOR，导致中断向量表仍指向Bootloader区域。Bootloader的向量表中，USART1中断向量指向Bootloader自己的处理函数（或空指针）。解决：在App的SystemInit()中添加VTOR重映射代码，并增加断言检查SCB->VTOR == APP_BASE_ADDR。

常见误区或总结复盘

• 误区一：在Bootloader跳转前设置VTOR。正确做法是：Bootloader跳转前应恢复默认向量表（VTOR=0），由App自己重新设置。
• 误区二：忽略中断向量表的对齐要求。ARM要求向量表按2的幂次对齐（通常为256字节或更大），链接脚本需显式指定.isr_vector段的对齐属性。
• 复盘：中断向量表重映射是OTA后系统稳定性的关键，建议在App启动自检中加入VTOR校验。

2.5 Bootloader与App的职责划分：清晰边界，协同工作

核心原理

Bootloader与App的职责划分遵循“最小权限”原则：Bootloader只负责引导、校验和升级决策，不包含业务逻辑；App负责业务功能，并触发升级流程。两者通过共享参数区（如升级标志、版本号、回滚计数）进行通信。Bootloader在每次复位后检查参数区，决定是跳转到App还是进入升级模式。

判断方法或操作流程

职责划分的决策矩阵如下：

案例拆解：Bootloader承担过多职责导致升级失败

某医疗设备项目将差分合并算法放在App中执行。当App在升级过程中因内存不足崩溃后，系统无法自动恢复，只能返厂维修。重构后，将差分合并算法移至Bootloader，App仅负责下载升级包并触发软复位。Bootloader在复位后检测到升级标志，执行合并、校验、写入备份区，最后跳转新App。此改动使升级成功率从92%提升至99.5%，且支持断电恢复。

常见误区或总结复盘

• 误区一：Bootloader与App共用中断处理函数。应完全隔离，避免耦合。
• 误区二：App直接写Bootloader区域。必须通过Bootloader提供的接口或标志位触发，防止误操作。
• 复盘：职责划分的终极目标是：即使App完全损坏，Bootloader仍能独立完成恢复升级。这是OTA设计的安全底线。