3. 启动流程深度解析：复位序列、向量表、堆栈初始化、C运行时环境建立

芯片上电那一刻，到底发生了什么？

很多初学者把启动流程想得很神秘。其实说白了，就是硬件把控制权交给软件的一个握手过程。我做了这么多年嵌入式，见过太多人在启动阶段栽跟头——要么堆栈没配好，要么中断向量表地址写错，板子死活跑不起来。

今天我们就把它彻底讲透。

3.1 复位序列：从硬件到软件的第一步

ARM Cortex-M 内核复位后，硬件会自动做三件事：

1. 读取栈顶地址：从地址 0x00000000 加载 MSP 初始值
2. 读取复位向量：从地址 0x00000004 加载 Reset_Handler 入口地址
3. 跳转执行：将 PC 指针指向 Reset_Handler

注意，这里有个关键点：Cortex-M 的向量表地址默认是 0x00000000。但如果你把代码链接到了别的地址（比如 0x08000000 的 Flash 区），就需要在启动代码里重新设置向量表偏移。

我遇到过一位同事，他把向量表放在了 0x08010000，但忘了设置 SCB->VTOR。结果每次复位后，CPU 都从 0x00000000 取向量，那里全是 0，直接 HardFault。嗯，这种坑踩一次就记住了。

3.2 向量表：中断的入口地图

向量表本质上是一个函数指针数组。每个表项对应一个异常或中断的入口地址。

Cortex-M3/M4 的向量表结构如下：

偏移地址	异常号	名称	描述
0x00	-	MSP 初始值	主堆栈指针初始值
0x04	1	Reset_Handler	复位异常入口
0x08	2	NMI_Handler	不可屏蔽中断
0x0C	3	HardFault_Handler	硬错误异常
0x10	4	MemManage_Handler	内存管理异常（M3/M4）
0x14	5	BusFault_Handler	总线错误异常（M3/M4）
0x18	6	UsageFault_Handler	用法错误异常（M3/M4）
...	...	...	...
0x40 + 4*(n-16)	n	IRQn_Handler	外设中断入口

写启动代码时，我习惯用 __attribute__((section(".isr_vector"))) 把向量表放到指定段。这样链接器能精确控制它的位置。

// 向量表定义示例
__attribute__((section(".isr_vector")))
void (* const g_pfnVectors[])(void) = {
    (void (*)(void))(&_estack),     // 0x00: MSP 初始值
    Reset_Handler,                  // 0x04: 复位入口
    NMI_Handler,                    // 0x08: NMI
    HardFault_Handler,              // 0x0C: HardFault
    MemManage_Handler,              // 0x10: MemManage
    BusFault_Handler,               // 0x14: BusFault
    UsageFault_Handler,             // 0x18: UsageFault
    // ... 后续中断向量
};

3.3 堆栈初始化：别让程序第一步就摔跤

堆栈初始化是启动代码里最容易被忽视的环节。你想想看，如果 SP 指向了未初始化的 RAM 区域，第一条 push 指令就会写坏数据。

Cortex-M 支持两种堆栈：

• MSP（主堆栈指针）：用于异常/中断处理，默认使用
• PSP（进程堆栈指针）：用于线程模式，RTOS 常用

启动时，硬件自动从向量表加载 MSP。但如果你要切到 PSP，需要在 Reset_Handler 里手动设置。

我个人习惯在启动代码里做三件事：

1. 确认 _estack 符号指向 RAM 末尾
2. 检查堆栈大小是否足够（至少 256 字节，RTOS 场景建议 1KB+）
3. 在调试阶段，把堆栈区域填充为 0xDEADBEEF，方便检测栈溢出

// 堆栈填充示例（调试用）
void StackFill(void)
{
    extern uint32_t _sstack, _estack;
    uint32_t *pStack = &_sstack;
    while (pStack < &_estack) {
        *pStack++ = 0xDEADBEEF;
    }
}

3.4 C运行时环境建立：让 main() 安心工作

从 Reset_Handler 到 main()，中间还有一堆活要干。C 标准要求全局变量在 main() 执行前完成初始化。这些工作统称为 C 运行时环境建立。

主要包含四个步骤：

步骤	操作	说明
1	拷贝 .data 段	将 Flash 中的初始值复制到 RAM
2	清零 .bss 段	将未初始化全局变量区域清零
3	初始化堆管理器	如果使用 malloc，需要初始化堆
4	调用构造函数	C++ 全局对象构造（如适用）

这些操作通常由 __main()（ARMCC）或 _start()（GCC）完成。但如果你自己写启动代码，就得手动实现。

我见过一个项目，工程师为了省事跳过了 .bss 清零。结果一个全局标志位初始值随机，导致状态机乱跳。查了两天才找到原因——嗯，从那以后我再也不敢省这一步了。

// 手动初始化 .data 和 .bss 段
void SystemInit(void)
{
    extern uint32_t _sdata, _edata, _sidata;
    extern uint32_t _sbss, _ebss;
    uint32_t *pSrc, *pDst;

    // 拷贝 .data 段
    pSrc = &_sidata;
    pDst = &_sdata;
    while (pDst < &_edata) {
        *pDst++ = *pSrc++;
    }

    // 清零 .bss 段
    pDst = &_sbss;
    while (pDst < &_ebss) {
        *pDst++ = 0;
    }
}

3.5 完整启动流程图

下面这张图把整个启动流程串起来了。我建议你把它存下来，调试时对照着看。

3.6 避坑指南：启动阶段常见问题

最后，我把这些年遇到的启动阶段问题整理了一下。你调试时如果板子死活没反应，按这个清单排查：

• 向量表地址不对：检查 SCB->VTOR 是否指向正确的 Flash 地址
• MSP 初始值非法：确认 _estack 在 RAM 范围内，且对齐到 8 字节
• .data 段拷贝方向反了：源地址在 Flash，目标地址在 RAM，别搞反
• .bss 段未清零：全局变量初始值随机，状态机直接乱套
• 堆栈溢出：中断嵌套深了，栈空间不够，覆盖了全局变量
• 时钟配置过早：在 Flash 等待周期没配好之前就切高速时钟，直接死机

启动流程说难不难，说简单也不简单。关键是把每个环节的硬件行为理解透，再配合调试工具验证。下次遇到板子点不亮，别急着怀疑硬件，先看看启动代码——八成问题出在这里。