📚 课程目录第4章中断向量表重映射

4、中断向量表重映射：VTOR寄存器详解、运行时重定向向量表、双Bank切换中的向量表处理

中断向量表，说白了就是CPU的“紧急联络簿”。芯片上电或发生异常时，CPU会翻这本联络簿，找到对应的处理函数地址。Bootloader要做的第一件事，往往就是把这本联络簿换个位置——从Flash起始地址挪到Bootloader自己的区域，或者从Bank0切到Bank1。

我个人习惯把VTOR（Vector Table Offset Register）称为“向量表方向盘”。你往哪打方向，CPU就去哪找中断入口。今天咱们就把这个方向盘彻底拆开看看。

4.1 VTOR寄存器深度解析

VTOR是Cortex-M3/M4/M7/M33等内核都有的一个寄存器，地址固定在0xE000ED08。它的结构其实很简单：

位段	名称	描述
[31:7]	TBL_BASE	向量表基地址，128字节对齐
[6:0]	Reserved	保留，必须写0

注意那个128字节对齐的要求。为什么是128？因为Cortex-M的向量表每个条目占4字节，前16个是系统异常，后面才是外设中断。128字节刚好覆盖前32个向量——够用了。我见过有人把地址写成非对齐值，结果中断一进来就跑飞，查了半天才发现是VTOR没对齐。

关键点：VTOR的TBL_BASE位段只关心高25位（[31:7]），低7位硬件直接忽略。所以写0x08000000和0x0800007F效果完全一样，都会对齐到0x08000000。

4.2 运行时重定向向量表

Bootloader启动后，需要把中断向量表从Flash默认地址（通常是0x08000000）重定向到Bootloader自己的区域。这样Bootloader运行期间，任何中断都不会误闯到应用程序的向量表里。

代码实现其实就一行：

// 假设Bootloader的向量表放在0x08010000
SCB->VTOR = 0x08010000;

但这里有个坑——你写VTOR之前，目标地址必须已经存在有效的向量表。否则CPU一发生中断，读到的MSP（主堆栈指针）或Reset_Handler地址全是0xFFFFFFFF，直接HardFault。

我曾经踩过的坑：在Bootloader里先擦除了Flash，然后才设置VTOR。结果擦除期间来了个SysTick中断，CPU去读空Flash，直接卡死。正确的做法是：先把向量表拷贝到RAM或保留的Flash区域，确认数据完整，再修改VTOR。

运行时重定向的典型场景是这样的：

上电启动：CPU从0x00000000读取初始MSP和Reset_Handler，进入Bootloader。
Bootloader初始化：设置VTOR指向Bootloader自己的向量表（比如0x08010000）。
运行期间：所有中断都由Bootloader的向量表处理。
跳转前：将VTOR改回应用程序的向量表地址（比如0x08020000），然后跳转。

嗯，这里要注意：跳转前改VTOR的时机必须精确。我习惯在关闭全局中断、禁用所有外设之后，最后一步才改VTOR，然后立刻跳转。中间不能有任何中断发生。

4.3 双Bank切换中的向量表处理

双Bank架构在OTA升级中很常见。两个Bank各放一份代码，Bank0跑着当前固件，Bank1放着新下载的固件。切换时，要么通过修改VTOR指向另一个Bank，要么通过重映射Flash地址。

以STM32G0/G4系列为例，它们支持物理双Bank。切换方式有两种：

方式	原理	优点	缺点
VTOR重定向	直接修改VTOR指向Bank1的向量表	实现简单，无需硬件重映射	Bank0和Bank1的代码必须位置无关
Flash地址重映射	通过SYSCFG寄存器交换Bank0和Bank1的物理地址	代码无需修改，直接运行	需要硬件支持，切换时有短暂停顿

我个人更倾向于VTOR重定向方式，因为它更可控。但有个前提——你的代码必须编译成位置无关（PIC）或者两个Bank的链接地址固定。否则代码里全是绝对地址跳转，一换Bank就崩。

小技巧：如果芯片不支持硬件重映射，可以用“向量表拷贝+VTOR修改”的方式模拟双Bank切换。把Bank1的向量表拷贝到RAM，VTOR指向RAM，然后跳转到Bank1的代码入口。这样Flash里两个Bank随便切，向量表始终在RAM里。

4.4 双Bank切换的向量表处理流程

下面这张图展示了双Bank切换时向量表的核心处理逻辑：

流程走到“收到升级指令”后，Bootloader需要做三件事：

验证Bank1的向量表：检查Bank1起始地址的前4字节（初始MSP）是否在RAM地址范围内，第2个4字节（Reset_Handler）是否在Flash地址范围内。这是最基础的合法性检查。
关闭所有中断：包括SysTick、外设中断，以及PendSV和SVCall。我习惯调用一个全局的DeInit函数，把所有外设恢复到复位状态。
修改VTOR并跳转：先写VTOR指向Bank1，然后执行DSB和ISB指令确保修改生效，最后用函数指针跳转到Bank1的Reset_Handler。

核心代码片段：

// 双Bank切换函数
void switch_to_bank1(void) {
    uint32_t bank1_base = 0x08040000;  // Bank1起始地址
    
    // 1. 验证向量表有效性
    uint32_t msp = *(volatile uint32_t *)bank1_base;
    uint32_t reset_handler = *(volatile uint32_t *)(bank1_base + 4);
    
    if ((msp < 0x20000000) || (msp >= 0x20020000)) {
        return;  // MSP不在SRAM范围，放弃切换
    }
    if ((reset_handler < 0x08000000) || (reset_handler >= 0x08080000)) {
        return;  // Reset_Handler不在Flash范围，放弃切换
    }
    
    // 2. 关闭所有中断
    __disable_irq();
    for (int i = 0; i < 8; i++) {
        NVIC->ICER[i] = 0xFFFFFFFF;  // 清除所有中断使能
        NVIC->ICPR[i] = 0xFFFFFFFF;  // 清除所有挂起中断
    }
    
    // 3. 修改VTOR并跳转
    SCB->VTOR = bank1_base;
    __DSB();
    __ISB();
    
    // 4. 跳转到Bank1的Reset_Handler
    void (*bank1_reset)(void) = (void (*)(void))reset_handler;
    bank1_reset();
}

4.5 向量表在RAM中的运行时重定向

还有一种场景：把向量表拷贝到RAM，然后VTOR指向RAM。这样做的好处是可以在运行时动态修改中断处理函数——比如实现函数补丁或者热修复。

步骤很简单：

在链接脚本中预留一块RAM区域，大小等于向量表（通常是256字节到512字节）。
启动时从Flash拷贝向量表到这块RAM。
设置VTOR指向RAM地址。
之后可以直接修改RAM里的向量表条目，实现动态重定向。

实际项目经验：我在一个需要不停机升级的项目里用过这个方案。把UART中断向量重定向到RAM里的新函数，这样升级过程中串口通信不会断。等新固件加载完，再把所有向量一次性切过去。

4.6 常见问题与避坑指南

VTOR写不进去？检查是不是在特权模式下操作的。非特权模式下VTOR是只读的。
中断响应变慢？如果VTOR指向RAM，RAM的访问延迟比Flash高，中断响应会慢几个周期。对时间敏感的应用要注意。
双Bank切换后外设中断不响应？大概率是Bank1的向量表里外设中断地址没初始化。很多人的Bank1代码只拷贝了前16个系统异常，后面的外设中断全是0。
跳转后卡在HardFault？检查VTOR修改后有没有执行DSB+ISB。Cortex-M有指令流水线和缓存，不刷一下的话CPU可能还在用旧的VTOR值。

我曾经犯过的错：有一次做双Bank升级，切换后系统随机死机。查了两天才发现——Bank1的向量表里，SysTick的入口地址指向了Bank0的代码段。切换后SysTick一触发，CPU跳到Bank0的代码里，而Bank0已经被擦除了。从那以后，我每次生成Bank1固件都会强制检查所有中断向量是否指向Bank1范围内。

嗯，向量表重映射这块内容其实不难，但细节特别多。VTOR就是个指针，但指错了地方，整个系统就崩了。我个人建议：每次修改VTOR之前，先打印或保存当前值，万一出问题还能恢复。生产代码里最好加一个向量表校验的断言，别省这一步。