STM32 OTA 中断向量表重定向详解

在STM32的OTA（Over-the-Air）升级中，中断向量表重定向是关键技术需求，其核心原因在于STM32的硬件架构和固件运行机制。以下从原理、实现方式及必要性三个角度详细分析：

一、中断向量表的作用与默认机制

1. 中断向量表的本质
   中断向量表是一个存储中断服务函数入口地址的数组，位于Flash起始位置（默认0x08000000）。每个中断对应一个32位地址值，指向该中断的处理函数（如Reset_Handler、HardFault_Handler等）。STM32上电后，CPU从中断向量表中读取栈顶指针和复位中断向量地址，完成启动流程。

2. 默认运行逻辑
   在未重定向时，所有中断均从0x08000000地址的中断向量表中获取入口地址。若BootLoader和APP程序共享同一中断向量表，当APP更新后其函数地址可能变化，导致中断无法正确跳转。

二、OTA升级对中断向量表的需求

1. BootLoader与APP的物理隔离
   OTA升级需要将Flash划分为BootLoader区和APP区（如BootLoader在0x08000000，APP在0x08010000）。若APP的中断向量表未独立设置，中断仍会从BootLoader区的旧向量表获取地址，导致程序崩溃。

2. 动态切换执行环境的必然性

3. 场景1：BootLoader完成固件升级后跳转至APP，若APP的中断向量表未重定向，中断将无法正确响应新程序的逻辑。

4. 场景2：APP运行时触发中断（如定时器、外设中断），若未指向APP的中断向量表，会跳转到BootLoader的中断处理函数，导致逻辑混乱(比如老的中断向量表指向的定时器2中断用来计数的，app定时器2中断用来pwm输出的，当app中断触发时没有指向当前需求输出pwm)。

5. 多固件版本的兼容性
   每次APP代码修改后，编译器生成的中断向量地址可能不同。若未通过重定向动态更新向量表位置，旧固件的中断处理逻辑将无法适配新固件。

三、重定向的两种实现方式

1. 修改中断向量表地址（主流方案）

• 原理：通过VTOR寄存器（Vector Table Offset Register）动态设置中断向量表的偏移地址。例如：

  SCB->VTOR = 0x08010000;  // 将中断向量表指向APP区的起始地址

• 适用场景：Cortex-M3/M4等支持VTOR寄存器的内核。此方式在APP启动时修改VTOR值，使中断跳转到新向量表。

2. 固定中断向量值（特殊场景方案）

• 原理：强制APP的中断向量值与BootLoader保持一致，共享同一中断向量表。需在代码中声明全局变量区分运行环境，并在中断函数内部分支处理逻辑。




• 缺点：APP每次更新需保证中断函数地址不变，限制代码修改灵活性，仅适用于功能简单的场景。

---

四、不同内核的差异化处理

1. Cortex-M3/M4（含VTOR寄存器）
   直接通过VTOR寄存器重定向，例如STM32F1/F4系列。这是最灵活且推荐的方式。

2. Cortex-M0（无VTOR寄存器）
   需将中断向量表复制到RAM起始地址，并通过SYSCFG_CFGR1寄存器将RAM映射到0x00000000，强制CPU从RAM读取向量表。例如STM32F0系列。

---

五、验证与调试要点

1. 链接脚本配置
   确保APP的.ld文件正确设置Flash起始地址和向量表偏移量，避免地址冲突。

2. 中断响应测试
   在APP中主动触发中断（如按键、定时器），观察是否跳转到预期处理函数。

3. VTOR值监测
   通过调试器查看SCB->VTOR的值，确认其指向APP的中断向量表地址。

---

总结

中断向量表重定向是OTA升级的核心机制，其本质是解决多份固件在独立Flash区域运行时中断处理的兼容性问题。通过VTOR寄存器或RAM重映射，开发者可确保BootLoader与APP的中断逻辑无缝切换，保障系统稳定运行。具体实现需结合芯片内核类型（是否支持VTOR）和Flash划分方案灵活选择。