第4章 中断向量表重定向：从硬件机制到实战部署
中断向量表，说白了就是MCU的“紧急电话本”。芯片复位或者发生中断时，CPU会拿着中断号去查这个表，找到对应的处理函数地址，然后跳过去执行。这个机制听起来简单，但在Bootloader开发中，它恰恰是第一个要啃的硬骨头。
我记得刚做Bootloader那会儿，第一次把程序下载到0x08010000地址，结果一上电就跑飞了。折腾了两天才发现——向量表还在0x08000000躺着呢，CPU根本找不到我的中断服务函数。从那以后，我每次移植Bootloader，第一件事就是确认向量表重定向有没有做对。
4.1 向量表的工作原理
先看看向量表长什么样。以Cortex-M3/M4为例，向量表从Flash起始地址开始，按顺序排列：
| 偏移地址 | 内容 | 说明 |
|---|---|---|
| 0x0000_0000 | 初始栈顶指针 (MSP) | 复位后SP自动加载此值 |
| 0x0000_0004 | 复位向量 (Reset_Handler) | 复位后PC跳转至此地址 |
| 0x0000_0008 | NMI_Handler | 不可屏蔽中断 |
| 0x0000_000C | HardFault_Handler | 硬错误处理 |
| ... | ... | ... |
| 0x0000_0040 | SVCall_Handler | 系统服务调用 |
| 0x0000_0044 | PendSV_Handler | 可挂起系统异常 |
| 0x0000_0048 | SysTick_Handler | 系统滴答定时器 |
| 0x0000_004C+ | 外设中断向量 | IRQ0 ~ IRQn |
每个向量占4字节，存放的是处理函数的地址。注意，Cortex-M的向量表里存的不是跳转指令，而是地址值。CPU复位后，硬件自动完成两件事：
- 从0x0000_0000加载SP值
- 从0x0000_0004加载PC值，跳转执行
嗯，这里有个关键点——向量表必须4字节对齐，而且起始地址的低2位必须是0。为什么？因为Cortex-M的异常处理机制要求向量表地址按256字节对齐（SCB->VTOR寄存器位宽限制），后面会细说。
4.2 SCB->VTOR寄存器配置
SCB->VTOR（Vector Table Offset Register）是Cortex-M内核提供的“向量表搬家”工具。它在系统控制块（SCB）里，地址是0xE000_ED08。这个寄存器的作用很简单：告诉CPU向量表的新家在哪。
VTOR的位定义如下：
| 位域 | 名称 | 描述 |
|---|---|---|
| [31:7] | TBLBASE | 向量表基地址，低7位固定为0 |
| [6] | TBLOFF | 0=Flash，1=SRAM |
| [5:0] | 保留 | 必须写0 |
看到没？低7位强制为0。这意味着向量表地址必须是128字节对齐的。但实际项目中，我建议按256字节对齐，因为有些MCU（比如STM32F1系列）要求512字节对齐。保守一点总没错。
配置代码其实就一行：
/* 将向量表重定向到0x08010000 */
SCB->VTOR = 0x08010000;
但这一行代码放在哪，什么时候执行，这里头有讲究。我见过不少新手直接把这段代码写在main函数开头，结果程序一跑就死。为什么？因为main函数本身可能依赖中断，而向量表还没切过去。
4.3 运行时重定向实战
实战环节，我们以STM32F407为例，演示如何在Bootloader中完成向量表重定向。假设Bootloader占0x08000000~0x0800FFFF（64KB），应用程序从0x08010000开始。
第一步：链接脚本配置
应用程序的链接脚本必须指定正确的Flash起始地址：
/* app.ld - 应用程序链接脚本片段 */
FLASH (rx) : ORIGIN = 0x08010000, LENGTH = 960K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
第二步：启动文件修改
应用程序的启动文件里，向量表声明要加上属性修饰，确保链接器把它放在正确位置：
; startup_stm32f407xx.s 片段
.section .isr_vector, "a", %progbits
.type g_pfnVectors, %object
.size g_pfnVectors, .-g_pfnVectors
g_pfnVectors:
.word _estack
.word Reset_Handler
.word NMI_Handler
; ... 其他向量
第三步：Bootloader跳转前的准备
Bootloader在跳转到应用程序之前，必须完成向量表重定向。我习惯在跳转函数里做这件事：
typedef void (*pFunction)(void);
void JumpToApp(uint32_t app_addr)
{
uint32_t msp_value;
pFunction app_entry;
/* 1. 关闭全局中断 */
__disable_irq();
/* 2. 关闭所有外设中断（根据实际使能情况清理） */
for(int i = 0; i < 8; i++)
{
NVIC->ICER[i] = 0xFFFFFFFF;
NVIC->ICPR[i] = 0xFFFFFFFF;
}
/* 3. 从应用程序向量表读取栈顶指针和复位向量 */
msp_value = *(volatile uint32_t*)app_addr;
app_entry = (pFunction)(*(volatile uint32_t*)(app_addr + 4));
/* 4. 重定向向量表到应用程序 */
SCB->VTOR = app_addr;
/* 5. 设置主栈指针 */
__set_MSP(msp_value);
/* 6. 跳转到应用程序 */
app_entry();
}
第四步：验证重定向是否成功
跳转后，可以在应用程序的Reset_Handler开头读取VTOR确认：
void Reset_Handler(void)
{
/* 读取VTOR确认重定向地址 */
uint32_t vtor = SCB->VTOR;
if(vtor != 0x08010000)
{
/* 重定向失败，进入错误处理 */
Error_Handler();
}
/* 继续执行系统初始化... */
SystemInit();
main();
}
4.4 常见踩坑与避坑指南
做向量表重定向，我踩过的坑能列一长串。挑几个典型的说说：
- 坑1：中断服务函数在应用程序里，但中断向量还在Bootloader
现象：应用程序里使能了定时器中断，一触发就进HardFault。
原因：VTOR没改，CPU去Bootloader的向量表找中断处理函数，而Bootloader里对应的向量指向的是Bootloader的弱定义（通常是死循环）。
解决：跳转前务必执行SCB->VTOR = APP_ADDR。 - 坑2：重定向后第一次中断正常，第二次就崩溃
现象：能进一次中断，但退出时栈乱了。
原因：应用程序的栈指针设置不对。跳转时只改了MSP，但中断返回时会自动恢复PSP（如果使用了进程栈）。
解决：确保应用程序启动文件正确初始化了栈指针，或者在跳转前把两个栈指针都设好。 - 坑3：在中断服务函数里修改VTOR
现象：程序跑着跑着突然死机。
原因：中断嵌套时修改VTOR，CPU正在查表，你突然把表换了位置。
解决：VTOR只能在非中断上下文修改，且修改前必须关中断。
- 向量表重定向的本质是告诉CPU“我的中断处理函数搬家了”
- VTOR配置必须在跳转前、关中断后执行
- 跳转前要清理所有中断挂起位，避免“脏中断”带入应用程序
- 向量表地址必须按128/256/512字节对齐（具体看MCU手册）
- 应用程序的链接脚本必须与VTOR设置的地址一致
下面这张图把整个流程串起来了，你可以对照着理解：
最后说一句，向量表重定向这件事，看着简单，但它是Bootloader和应用程序之间的“握手协议”。握不好，后面所有中断相关的功能都会出问题。我个人的习惯是：每次写完跳转代码，先拿一个定时器中断做测试——在应用程序里使能定时器，看能不能正常进入中断。能进，说明重定向成功了；进不去，赶紧回头查VTOR配置和链接脚本。