从0xFFFFFFFE死机到中断向量表重定位：一次BootLoader屏蔽后的深度排错

1. 当单片机卡死在0xFFFFFFFE时发生了什么

那天下午三点，我正在调试一块GD32F303的开发板。为了测试新功能，我屏蔽了BootLoader直接运行应用程序，结果程序卡死在0xFFFFFFFE这个诡异的地址。屏幕上反汇编显示0000 MOVS r0,r0，这个无效指令让我瞬间冒冷汗——这明显是CPU跑飞了。

0xFFFFFFFE这个地址很特殊：在ARM Cortex-M架构中，它属于保留地址空间。当CPU试图从这里取指时，说明中断向量表出了问题。我当时的场景是：

• 屏蔽了BootLoader
• 将中断向量表恢复为默认配置
• 仅保留SysTick定时器和GPIO控制LED
• 所有外设初始化都正常

但程序就是无法运行。通过JTAG调试器查看寄存器状态，发现PC指针确实指向了这个非法地址。更奇怪的是，如果改用硬件延时替代SysTick，程序就能正常运行。这个现象直接指向了中断向量表重定位的问题。

2. 中断向量表的秘密

2.1 为什么需要重定位向量表

在标准嵌入式系统中，中断向量表默认存放在Flash起始地址（比如STM32的0x08000000）。但当使用BootLoader时，应用程序的中断向量表需要重定位。通常有两种做法：

1. 在BootLoader中完成重定位
2. 在应用程序初始化时重定位

我遇到的坑在于：前同事把VTOR（Vector Table Offset Register）设置放在了SystemInit()里。这个函数在__main之前执行，此时：

• 内存尚未完全初始化
• C运行时环境未就绪
• 中断向量表地址却已被修改

c复制// 错误的VTOR设置位置
void SystemInit(void) {
    // ...其他初始化代码
    SCB->VTOR = VECT_TAB_OFFSET; // 过早重定位！
}

2.2 硬件层面的连锁反应

当VTOR设置过早时，SysTick中断发生时：

1. CPU尝试查找中断服务程序
2. 由于VTOR指向错误地址，获取到错误的中断向量
3. PC指针被加载到非法地址（如0xFFFFFFFE）
4. 触发HardFault或直接死机

通过逻辑分析仪抓取波形，可以观察到：

• 系统时钟