在STM32的OTA（Over-the-Air）升级中，中断向量表重定向是关键技术需求，其核心原因在于STM32的硬件架构和固件运行机制。以下从原理、实现方式及必要性三个角度详细分析：
一、中断向量表的作用与默认机制
-
中断向量表的本质
中断向量表是一个存储中断服务函数入口地址的数组，位于Flash起始位置（默认0x08000000）。每个中断对应一个32位地址值，指向该中断的处理函数（如Reset_Handler、HardFault_Handler等）。STM32上电后，CPU从中断向量表中读取栈顶指针和复位中断向量地址，完成启动流程。 -
默认运行逻辑
在未重定向时，所有中断均从0x08000000地址的中断向量表中获取入口地址。若BootLoader和APP程序共享同一中断向量表，当APP更新后其函数地址可能变化，导致中断无法正确跳转。
二、OTA升级对中断向量表的需求
-
BootLoader与APP的物理隔离
OTA升级需要将Flash划分为BootLoader区和APP区（如BootLoader在0x08000000，APP在0x08010000）。若APP的中断向量表未独立设置，中断仍会从BootLoader区的旧向量表获取地址，导致程序崩溃。 -
动态切换执行环境的必然性
- 场景1：BootLoader完成固件升级后跳转至APP，若APP的中断向量表未重定向，中断将无法正确响应新程序的逻辑。
- 场景2：APP运行时触发中断（如定时器、外设中断），若未指向APP的中断向量表，会跳转到BootLoader的中断处理函数，导致逻辑混乱(比如老的中断向量表指向的定时器2中断用来计数的，app定时器2中断用来pwm输出的，当app中断触发时没有指向当前需求输出pwm)。
-
多固件版本的兼容性
每次APP代码修改后，编译器生成的中断向量地址可能不同。若未通过重定向动态更新向量表位置，旧固件的中断处理逻辑将无法适配新固件。
三、重定向的两种实现方式
1. 修改中断向量表地址（主流方案）
- 原理：通过VTOR寄存器（Vector Table Offset Register）动态设置中断向量表的偏移地址。例如：
SCB->VTOR = 0x08010000; // 将中断向量表指向APP区的起始地址 - 适用场景：Cortex-M3/M4等支持VTOR寄存器的内核。此方式在APP启动时修改VTOR值，使中断跳转到新向量表。
2. 固定中断向量值（特殊场景方案）
- 原理：强制APP的中断向量值与BootLoader保持一致，共享同一中断向量表。需在代码中声明全局变量区分运行环境，并在中断函数内部分支处理逻辑。
- 缺点：APP每次更新需保证中断函数地址不变，限制代码修改灵活性，仅适用于功能简单的场景。
四、不同内核的差异化处理
-
Cortex-M3/M4（含VTOR寄存器）
直接通过VTOR寄存器重定向，例如STM32F1/F4系列。这是最灵活且推荐的方式。 -
Cortex-M0（无VTOR寄存器）
需将中断向量表复制到RAM起始地址，并通过SYSCFG_CFGR1寄存器将RAM映射到0x00000000，强制CPU从RAM读取向量表。例如STM32F0系列。
五、验证与调试要点
-
链接脚本配置
确保APP的.ld文件正确设置Flash起始地址和向量表偏移量，避免地址冲突。 -
中断响应测试
在APP中主动触发中断（如按键、定时器），观察是否跳转到预期处理函数。 -
VTOR值监测
通过调试器查看SCB->VTOR的值，确认其指向APP的中断向量表地址。
总结
中断向量表重定向是OTA升级的核心机制，其本质是解决多份固件在独立Flash区域运行时中断处理的兼容性问题。通过VTOR寄存器或RAM重映射，开发者可确保BootLoader与APP的中断逻辑无缝切换，保障系统稳定运行。具体实现需结合芯片内核类型（是否支持VTOR）和Flash划分方案灵活选择。
)
