4、启动代码的入口与向量表：向量表的结构（初始SP、复位向量、异常向量）、向量表在启动文件中的定义与放置

当一颗ARM Cortex-M内核的芯片上电或复位后，CPU从Flash中取到的第一条指令并不是用户写的main函数，而是一个被称为“向量表”的特殊数据结构。向量表是Cortex-M处理器启动流程的“总入口”，它决定了处理器复位后从哪里开始执行、遇到异常时跳转到哪里处理。理解向量表的结构、定义方式与链接放置规则，是读懂启动代码、排查启动异常（如硬件错误HardFault）的基础。本章将深入拆解向量表的内部布局、启动文件中的具体写法，以及链接脚本（.ld或.sct）如何保证向量表被放置在正确地址。

上图展示了Cortex-M处理器启动时与向量表之间的核心交互关系。左侧是Flash起始区域的向量表布局，右侧是内核上电后的执行路径。可以看到，向量表并非简单的函数指针数组，它包含了初始栈指针（SP）和所有异常/中断的服务函数地址。下面我们逐一展开。

4.1 向量表的结构：从初始SP到异常向量

ARM Cortex-M处理器（包括M0、M3、M4、M7以及M33等）的向量表是一个按固定顺序排列的32位（4字节）地址数组。向量表的总大小由芯片支持的中断源数量决定，但前16个条目（偏移0x00~0x3C）是所有Cortex-M内核共有的系统异常向量，从偏移0x40开始才是芯片厂商自定义的外部中断向量。

偏移地址	向量名称	优先级	说明
0x00	初始SP（MSP）	-	主栈指针初始值，通常指向RAM末尾
0x04	Reset_Handler	-3（最高）	复位后第一条执行的指令地址
0x08	NMI_Handler	-2	不可屏蔽中断
0x0C	HardFault_Handler	-1	硬件错误，最常见的异常
0x10~0x3C	MemManage/BusFault/UsageFault/保留	可配置	M3/M4/M7支持，M0/M0+仅HardFault
0x40 起	外部中断向量（IRQ0~IRQn）	可配置	由芯片厂商定义，如EXTI、TIM、UART等

这里有一个关键细节：向量表中存储的是地址值，而不是指令。例如，Reset_Handler条目中存放的是Reset_Handler函数的入口地址（即函数名的值）。Cortex-M内核在复位时，硬件逻辑会自动完成以下操作：

从地址0x00000000（或映射的Flash起始地址）读取初始SP值，写入主栈指针MSP。
从地址0x00000004读取复位向量值，将其写入程序计数器PC。
CPU从PC指向的地址开始取指执行，即进入Reset_Handler。

对于Cortex-M3/M4/M7，向量表还支持重定位（通过VTOR寄存器），但M0/M0+不支持VTOR，向量表必须固定在Flash起始地址。这是芯片选型时需要考虑的约束。

经验提醒：在调试HardFault时，查看向量表偏移0x0C处的值是否指向有效的HardFault_Handler函数，是判断向量表是否被正确链接的第一道检查。如果该值为0xFFFFFFFF或0x00000000，说明Flash内容异常或链接脚本配置错误。

4.2 启动文件中的向量表定义：汇编代码拆解

在STM32、NXP LPC、GD32等主流Cortex-M芯片的启动文件（如startup_stm32f407xx.s）中，向量表通常通过汇编伪指令定义。以下是一个典型的向量表定义片段（以STM32F407为例）：

; 向量表段声明
    AREA    RESET, DATA, READONLY
    EXPORT  __Vectors
    EXPORT  __Vectors_End
    EXPORT  __Vectors_Size

__Vectors       DCD     __initial_sp          ; 0x00 初始SP
                DCD     Reset_Handler         ; 0x04 复位向量
                DCD     NMI_Handler           ; 0x08 NMI
                DCD     HardFault_Handler     ; 0x0C HardFault
                DCD     MemManage_Handler     ; 0x10 MemManage (M3/M4)
                DCD     BusFault_Handler      ; 0x14 BusFault
                DCD     UsageFault_Handler    ; 0x18 UsageFault
                DCD     0                     ; 0x1C 保留
                DCD     0                     ; 0x20 保留
                DCD     0                     ; 0x24 保留
                DCD     0                     ; 0x28 保留
                DCD     SVC_Handler           ; 0x2C SVC
                DCD     DebugMon_Handler      ; 0x30 DebugMon
                DCD     0                     ; 0x34 保留
                DCD     PendSV_Handler        ; 0x38 PendSV
                DCD     SysTick_Handler       ; 0x3C SysTick
; 以下是外部中断向量（部分示例）
                DCD     WWDG_IRQHandler       ; 0x40
                DCD     PVD_IRQHandler        ; 0x44
                DCD     TAMP_STAMP_IRQHandler ; 0x48
                ; ... 后续中断向量
__Vectors_End

这段代码的关键点在于：

AREA RESET, DATA, READONLY：声明一个名为RESET的只读数据段，链接脚本会将该段放置在Flash起始地址。
DCD（Define Constant Double-word）：每个DCD占用4字节，依次存放各个向量地址。
__initial_sp：这是一个由链接脚本计算出的符号，通常等于RAM起始地址+RAM大小，即栈顶地址。
EXPORT __Vectors：导出向量表起始地址，供链接脚本和调试器使用。

在启动文件的末尾，通常会定义每个Handler的弱引用（WEAK）默认实现，例如：

; 默认异常处理函数（弱定义）
NMI_Handler     PROC
                EXPORT  NMI_Handler [WEAK]
                B       .
                ENDP

HardFault_Handler PROC
                EXPORT  HardFault_Handler [WEAK]
                B       .
                ENDP

这里的B .表示无限循环（死循环）。如果用户没有在应用程序中重新定义这些Handler，链接器会使用这里的弱定义；如果用户定义了同名函数，则强定义会覆盖弱定义。这是嵌入式开发中常见的“弱符号”机制。

风险提示：如果用户定义的Handler函数名与启动文件中的弱定义不完全一致（例如拼写错误或大小写不同），链接器不会报错，但中断触发时会跳转到默认的无限循环，导致系统“卡死”且难以排查。建议在编写中断服务函数时，直接从启动文件复制函数名。

4.3 向量表的放置：链接脚本与内存映射

向量表在启动文件中定义后，还需要通过链接脚本（GCC的.ld文件或Keil的.sct文件）将其放置在正确的内存地址。对于绝大多数Cortex-M芯片，向量表必须位于Flash的起始地址（如STM32的0x08000000）。以下是GCC链接脚本中的典型配置：

/* memory.ld */
MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM   (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector))   /* 启动文件中的RESET段 */
    . = ALIGN(4);
  } > FLASH

  .text :
  {
    . = ALIGN(4);
    *(.text)
    *(.text*)
    . = ALIGN(4);
  } > FLASH

  /* 其他段... */
}

这里有几个关键点需要理解：

KEEP()：强制链接器保留.isr_vector段，即使看起来没有被引用。因为向量表是通过硬件机制访问的，链接器默认会丢弃未引用的段。
ALIGN(4)：确保向量表按4字节对齐，因为每个向量是32位地址。
> FLASH：将向量表放置在Flash区域，起始地址为0x08000000。

对于支持向量表重定位的Cortex-M3/M4/M7，还可以在运行时通过VTOR寄存器将向量表重映射到RAM中（常用于Bootloader+App架构）。但M0/M0+不支持VTOR，因此App的向量表必须固定在Flash起始地址，这要求Bootloader通过跳转指令（而非修改VTOR）来启动App。

  实战场景：Bootloader跳转App时的向量表处理

  在IAP（In-Application Programming）升级场景中，Bootloader位于Flash起始地址，App位于偏移地址（如0x08010000）。对于M3/M4芯片，Bootloader在跳转前需要：

  1. 设置VTOR = 0x08010000；

  2. 读取App向量表偏移0x00处的SP值，写入MSP；

  3. 读取App向量表偏移0x04处的Reset_Handler地址，跳转执行。

  对于M0/M0+芯片，由于没有VTOR，App的向量表必须通过编译选项（如--vector_table）或链接脚本重定位到0x08010000，且中断向量不能重映射，只能通过Bootloader转发中断。

4.4 常见误区与排查方法

向量表相关的问题在嵌入式开发中非常常见，以下是几个典型的误区和对应的排查思路：

误区现象	可能原因	排查方法
上电后程序不运行，调试器显示PC=0x00000000	向量表未正确链接到Flash起始地址	检查链接脚本中.isr_vector段是否放在FLASH起始位置；查看map文件确认__Vectors地址
触发中断后进入HardFault	中断向量表中对应Handler地址为0或无效	检查启动文件中是否定义了该中断的DCD条目；确认Handler函数是否被链接（避免被优化掉）
修改了中断服务函数但未生效	函数名与启动文件中的弱定义不一致	对比启动文件中的Handler名称，注意大小写和下划线
Bootloader跳转App后中断不工作	M0/M0+无VTOR，App向量表位置错误	确认App链接脚本将向量表放在App起始地址；考虑使用中断转发机制

在实际调试中，建议使用以下步骤快速验证向量表是否正确：

在调试器中查看内存窗口，检查Flash起始地址（如0x08000000）处的数据是否为预期的SP值和Reset_Handler地址。
查看编译生成的.map文件，确认__Vectors符号的地址是否为0x08000000。
在Reset_Handler入口处设置断点，如果能够停在断点处，说明向量表的前两个条目（SP和复位向量）工作正常。
手动触发一个外部中断（如按键中断），观察是否跳转到对应的IRQHandler。

复盘总结：向量表是Cortex-M启动的“第一块多米诺骨牌”。它既是数据结构（存储地址），又是硬件机制（内核自动读取）。理解向量表的关键在于三点：一是结构上，前16个系统异常+外部中断的顺序固定；二是定义上，启动文件通过DCD伪指令逐项填充；三是放置上，链接脚本必须保证向量表在Flash起始地址且4字节对齐。掌握这三点，就能应对绝大多数启动异常问题。