第2章复位向量表

2. 复位向量表：ARM Cortex架构的异常向量表结构，复位向量的定义与跳转逻辑

好，咱们直接进入正题。上一章我们聊了启动代码的整体流程，这一章我打算把最核心的「复位向量表」掰开揉碎了讲清楚。你想想看，MCU上电后第一件事是什么？就是去找复位向量。如果这个向量指错了地方，那整个系统就别想跑起来。

2.1 异常向量表长什么样？

ARM Cortex-M和Cortex-R的异常向量表，说白了就是一张「中断服务函数地址表」。这张表放在Flash的最开头，也就是地址0x00000000处。我刚开始做车规项目时，有个同事把向量表偏移搞错了，结果一上电就进HardFault，查了两天才找到原因——嗯，这种坑踩过一次就忘不了。

这张表的结构其实很简单：

; 典型的Cortex-M3/M4向量表布局（以STM32为例）
0x00000000:  __initial_sp      ; 栈顶指针（主堆栈的起始地址）
0x00000004:  Reset_Handler     ; 复位向量
0x00000008:  NMI_Handler       ; 不可屏蔽中断
0x0000000C:  HardFault_Handler ; 硬错误
0x00000010:  MemManage_Handler ; 内存管理错误
0x00000014:  BusFault_Handler  ; 总线错误
0x00000018:  UsageFault_Handler; 用法错误
...                            ; 其他异常和中断向量

注意看，第一个条目不是函数指针，而是栈顶地址。这是ARM Cortex架构的一个设计特点——CPU复位后会自动从0x00000000加载SP，从0x00000004加载PC。我个人习惯在链接脚本里把栈空间分配好，然后在汇编里用.word指令把地址填进去。

关键点：向量表的前16个条目是系统异常（包括复位），从第16个开始才是外设中断。Cortex-M3/M4最多支持240个外设中断，但具体数量取决于芯片厂商的设计。

2.2 复位向量的定义与跳转逻辑

复位向量是系统上电或复位后CPU执行的第一条指令的地址。在ARM Cortex-M架构中，这个地址存放在0x00000004处。CPU复位后，硬件会自动完成以下操作：

从0x00000000加载主栈指针（MSP）
从0x00000004加载PC指针
从0x00000008开始执行（如果复位向量指向Thumb代码）

这里有个细节——Cortex-M只支持Thumb指令集，所以复位向量指向的地址必须满足LSB=1（表示Thumb状态）。如果LSB=0，CPU会进入错误状态。我在调试一个Tier1的样品时遇到过这个问题：他们用汇编写的启动代码，.word Reset_Handler忘了加+1，结果CPU死活不跑。后来发现是汇编器自动处理了，但如果你手动填地址，一定要小心。

小技巧：在C代码中定义中断服务函数时，建议用__attribute__((interrupt))或__irq关键字。这样编译器会自动生成正确的函数入口和退出代码，包括保存/恢复上下文。

2.3 向量表偏移（VTOR）

在实际项目中，我们经常需要把向量表从Flash搬到RAM，或者放在不同的Flash扇区。这时候就要用到VTOR（Vector Table Offset Register）。

Cortex-M3/M4的VTOR寄存器位于0xE000ED08，可以设置向量表的基地址。注意，这个地址必须对齐到512字节（对于M3/M4）或256字节（对于M0+）。

// 设置向量表偏移到0x20000000（假设SRAM起始地址）
#define SCB_VTOR   (*(volatile uint32_t *)0xE000ED08)

void vector_table_relocate(void)
{
    // 先把向量表复制到SRAM
    memcpy((void*)0x20000000, (void*)0x08000000, 0x200);
    
    // 设置VTOR
    SCB_VTOR = 0x20000000;
    
    // 别忘了设置新的栈顶指针
    __set_MSP(*(uint32_t*)0x20000000);
}

我曾经在一个Bootloader项目中用过这个技巧。Bootloader在Flash的0x08000000处，应用程序在0x08020000处。每次跳转前，我先设置VTOR指向应用程序的向量表，再跳转到对应的复位向量。这样应用程序的异常处理就能正常工作。

警告：修改VTOR后，一定要确保新向量表已经正确初始化。否则，一旦发生中断，CPU会从错误的位置加载函数地址，结果就是HardFault。我见过有人把VTOR设成了未初始化的RAM区域，结果中断一来就死机。

2.4 复位跳转的完整流程

咱们用一张图来总结复位后的跳转逻辑：

这张图把整个流程串起来了。你注意看，VTOR的检查是在硬件加载完SP和PC之后才进行的。也就是说，复位向量本身不受VTOR影响——它永远从0x00000004读取。VTOR影响的是后续的异常和中断向量查找。

2.5 实际项目中的注意事项

做车规项目这么多年，我总结了几条关于复位向量表的铁律：

向量表必须对齐：Cortex-M3/M4要求512字节对齐，M0+要求256字节对齐。不对齐的话，VTOR写不进去。
栈顶指针要合理：第一个字是栈顶地址，不是函数指针。我见过有人把函数地址写进去，结果SP指向了Flash区域，一压栈就崩。
中断函数要weak：建议把所有中断函数都声明为weak属性，这样用户可以在应用程序中重新定义。我在Bootloader里就是这么做的——默认的中断函数都指向一个死循环，用户覆盖了才会真正处理。
保留向量表空间：在链接脚本里，要给向量表留够空间。Cortex-M3/M4的向量表有16个系统异常 + 最多240个中断，每个占4字节，总共约1KB。别省这点空间。

避坑指南：我曾经在一个项目中，把向量表放在了RAM的末尾，结果VTOR设置后，中断一来就HardFault。查了半天才发现，RAM末尾被堆栈占用了，向量表被覆盖了。后来我把向量表放在RAM开头，并确保堆栈不会增长到那个区域。记住——向量表所在的内存区域，必须保证不会被其他数据覆盖。

好了，关于复位向量表的内容就讲到这里。下一章我们会深入Reset_Handler的具体实现，看看从汇编到C语言入口的完整跳转过程。到时候我会分享一些我在Bootloader和应用程序跳转方面的实战经验。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

2. 复位向量表：ARM Cortex架构的异常向量表结构，复位向量的定义与跳转逻辑

2.1 异常向量表长什么样？

2.2 复位向量的定义与跳转逻辑

2.3 向量表偏移（VTOR）

2.4 复位跳转的完整流程

2.5 实际项目中的注意事项