📚 课程目录第4章中断向量表重定位

4. 中断向量表重定位：原理、必要性与Bootloader实现

中断向量表，说白了就是一张“中断发生时该去哪执行”的地址映射表。每个中断源对应一个表项，表项里存放的是中断服务函数（ISR）的入口地址。CPU一旦捕获到中断信号，硬件会自动从这个表里取出地址，跳转过去执行。

我刚开始做嵌入式时，总觉得这玩意儿是芯片出厂就定死的，没啥好折腾的。直到有一次做OTA升级，程序跑飞了才发现——嗯，向量表不动，升级就是扯淡。

4.1 中断向量表原理

以ARM Cortex-M系列为例，向量表默认放在Flash起始地址0x00000000。第0个表项是栈顶指针，第1个是复位向量，后面依次是各种异常和中断的入口。

// 典型的Cortex-M向量表结构（简化）
typedef void (*pFunc)(void);

typedef struct {
    uint32_t    stackTop;       // 0x00000000: 栈顶地址
    pFunc       resetHandler;   // 0x00000004: 复位向量
    pFunc       nmiHandler;     // 0x00000008: NMI
    pFunc       hardFaultHandler; // 0x0000000C: HardFault
    // ... 其他异常
    pFunc       irq0Handler;    // 0x00000040: 外部中断0
    pFunc       irq1Handler;    // 0x00000044: 外部中断1
    // ...
} VectorTable;

硬件上电后，CPU从0x00000000读取栈顶指针，从0x00000004读取复位向量地址，然后跳转执行。这个流程是硬连线逻辑，改不了。

关键点：向量表的位置由芯片的VTOR寄存器（Vector Table Offset Register）控制。只要修改VTOR，就能让CPU从新的地址读取向量表。这是重定位的硬件基础。

4.2 为什么需要重定位？

你想想看，Bootloader和App是两个独立的固件镜像。如果App也想用中断，它的向量表就不能和Bootloader冲突。我见过不少新手直接把App烧到0x08000000，结果一开中断就死机——因为向量表还在Flash开头，指向的是Bootloader的ISR。

重定位的必要性，总结下来就三点：

多镜像共存：Bootloader在0x08000000，App在0x08020000，各自维护自己的向量表
运行时切换：从Bootloader跳转到App前，必须把VTOR指向App的向量表
RAM中执行：某些场景需要把向量表拷贝到RAM，提升中断响应速度（比如低功耗模式）

我曾经踩过的坑：有一次做IAP升级，App的向量表放在0x08010000，但VTOR忘了改。结果App里一按按键触发外部中断，直接跳回Bootloader的ISR，然后ISR里又调了App的函数——栈就乱了。排查了整整两天才发现是VTOR没更新。

4.3 在Bootloader中实现向量表拷贝与映射

实现步骤其实不复杂，但细节决定成败。我个人习惯分三步走：

计算目标地址：确定App向量表在Flash中的偏移量
拷贝向量表：如果需要RAM映射，把Flash中的向量表拷贝到RAM
设置VTOR：修改VTOR寄存器，指向新的向量表基址

4.3.1 直接映射（Flash到Flash）

最常见的方式。App的向量表就在Flash里，Bootloader跳转前只需修改VTOR。

// 假设App起始地址为APP_BASE_ADDR (0x08020000)
#define APP_BASE_ADDR       0x08020000
#define SCB_VTOR            ((volatile uint32_t *)0xE000ED08)

void jump_to_app(void) {
    uint32_t app_stack_top;
    pFunc app_reset_handler;

    // 1. 从App向量表读取栈顶和复位向量
    app_stack_top = *(volatile uint32_t *)APP_BASE_ADDR;
    app_reset_handler = (pFunc)(*(volatile uint32_t *)(APP_BASE_ADDR + 4));

    // 2. 设置主栈指针
    __set_MSP(app_stack_top);

    // 3. 重定位向量表 —— 关键一步
    *SCB_VTOR = APP_BASE_ADDR;

    // 4. 跳转到App复位向量
    app_reset_handler();
}

注意：设置VTOR之前，必须确保App的向量表已经烧录到Flash中。如果App还没烧录或者烧录位置不对，一设置VTOR就会触发HardFault。我一般会在跳转前加一个校验：检查向量表的前几个表项是否合法（比如栈顶地址是否在RAM范围内）。

4.3.2 拷贝到RAM（Flash到RAM）

有些场景需要把向量表搬到RAM里。比如低功耗模式下Flash可能掉电，或者你想动态修改中断入口。这时候就需要拷贝。

#define VECTOR_TABLE_SIZE    (16 + 240)  // 16系统异常 + 240外部中断
#define RAM_VECTOR_BASE      0x20000000  // RAM起始地址

void copy_vector_table_to_ram(void) {
    uint32_t *src = (uint32_t *)APP_BASE_ADDR;
    uint32_t *dst = (uint32_t *)RAM_VECTOR_BASE;
    uint32_t i;

    // 拷贝整个向量表到RAM
    for (i = 0; i < VECTOR_TABLE_SIZE; i++) {
        dst[i] = src[i];
    }

    // 设置VTOR指向RAM
    *SCB_VTOR = RAM_VECTOR_BASE;

    // 确保CPU从RAM读取向量表
    __DSB();  // 数据同步屏障
    __ISB();  // 指令同步屏障
}

警告：拷贝到RAM后，RAM的起始地址（0x20000000）就不能再被App用作普通数据区了。否则App的全局变量会覆盖向量表，导致中断异常。我习惯在链接脚本里把RAM的前1KB保留给向量表，App的.data和.bss从1KB之后开始。

4.4 重定位后的中断响应流程

为了让你更直观地理解，我画了一张流程图：

4.5 常见问题与避坑指南

问题	现象	原因	解决方案
VTOR未设置	App中断触发后死机	CPU仍从Bootloader向量表读取ISR地址	跳转前必须写VTOR寄存器
向量表对齐错误	中断响应异常	VTOR要求向量表基址512字节对齐（Cortex-M）	确保App起始地址按0x200对齐
RAM向量表被覆盖	中断偶尔失效	App的.data段初始化覆盖了RAM向量表	链接脚本保留RAM前1KB给向量表
Cache一致性问题	中断跳转错误	拷贝到RAM后，CPU读取了Cache中的旧数据	拷贝后执行DSB+ISB指令

我的经验：调试中断向量表重定位时，最有效的办法是在跳转前打印VTOR的值，确认它指向了正确的地址。另外，可以在App的ISR入口处加一个GPIO翻转，用示波器看中断响应是否来自App——这比看代码快多了。

4.6 小结

中断向量表重定位，说白了就是让CPU知道“现在该用谁的向量表”。Bootloader负责在跳转前把VTOR指对地方，App才能正常响应中断。这个机制是OTA升级、多镜像系统、低功耗设计的基础。

嗯，这里要注意：VTOR的修改时机非常关键。必须在关闭全局中断的情况下操作，否则在修改过程中来了中断，CPU会读到不完整的向量表。我一般会在跳转前先关中断，设置完VTOR再开——但App的复位向量里通常也会重新初始化中断，所以Bootloader里关掉就行，不用再开。