📚 课程目录第2章启动流程深度解析

2. 启动流程深度解析：Cortex-M复位序列、向量表与堆栈指针、从Reset_Handler到main()的完整路径

说实话，很多工程师写了几年嵌入式代码，却从来没认真看过芯片上电后到底发生了什么。他们只知道「程序从main开始跑」，但main之前的那段路，才是Bootloader最核心的战场。

我个人习惯把Cortex-M的启动流程比作「军队出征前的整队」——向量表是花名册，堆栈指针是后勤补给，Reset_Handler是总指挥。任何一个环节出错，队伍都拉不出去。

2.1 复位序列：芯片上电后的第一口气

Cortex-M处理器复位后，硬件会自动做三件事，顺序固定，不需要你写任何代码：

读取向量表偏移地址：从0x00000000处读取初始堆栈指针值（MSP）
读取复位向量：从0x00000004处读取Reset_Handler的入口地址
跳转执行：将PC指针指向Reset_Handler，开始执行第一条指令

嗯，这里要注意：Cortex-M使用的是字节序小端模式（默认），所以0x00000000存放的是MSP的低字节。我曾经在调试一块国产MCU时，发现芯片死活不进main，最后用调试器一看——Flash里0x00000000的数据被擦除了，MSP读出来全是0xFF，堆栈指针直接飞到了地址空间顶端之外。

⚠ 避坑指南： 千万不要假设Flash的0地址一定有效。量产烧录时，如果烧录工具从偏移地址开始写，而向量表没被正确放置到0地址，芯片上电就会「跑飞」。我曾经因为这个原因，在产线前熬了三个通宵。

2.2 向量表：处理器的「紧急联络簿」

向量表本质上是一个函数指针数组，每个表项对应一个异常或中断的处理函数地址。Cortex-M强制要求向量表从0地址或SCB->VTOR指定的地址开始。

典型的向量表布局如下：

偏移地址	异常/中断号	内容	说明
0x0000	-	MSP初始值	堆栈指针的初始值，必须是SRAM范围内的有效地址
0x0004	1	Reset_Handler	复位后第一条指令入口
0x0008	2	NMI_Handler	不可屏蔽中断
0x000C	3	HardFault_Handler	硬错误，最常用的调试入口
0x0010 ~ 0x003C	4~15	系统异常处理函数	MemManage、BusFault、UsageFault等
0x0040 + (n-16)*4	16~	外设中断处理函数	由芯片厂商定义

你想想看，如果向量表被破坏了，比如HardFault_Handler的地址被写成了0x00000000，那一旦发生硬件错误，CPU会再次跳回0地址，形成死循环。我遇到过最隐蔽的情况是：Bootloader升级固件时，只写了应用程序区，却忘了更新向量表里的中断向量偏移——结果应用程序一开中断就进HardFault。

💡 个人经验： 在Bootloader中，我习惯在跳转到应用程序前，先校验应用程序向量表的前两个Word（MSP和Reset_Handler）。如果MSP不在SRAM范围内，或者Reset_Handler指向了非Flash区域，直接拒绝跳转。这个检查帮我挡掉了至少三次「刷错固件」的线上事故。

2.3 堆栈指针：MSP与PSP的「双轨制」

Cortex-M有两个堆栈指针：主堆栈指针（MSP）和进程堆栈指针（PSP）。复位后默认使用MSP，这也是所有异常处理函数使用的堆栈。

为什么需要两个？说白了，是为了隔离。操作系统里，内核跑在MSP上，用户任务跑在PSP上。这样用户任务栈溢出时，不会直接冲垮内核的栈。裸机开发一般只用MSP，但Bootloader里我建议你了解这个机制——万一你要上RTOS呢？

堆栈指针的初始值由向量表第一个Word决定。这个值必须是4字节对齐的，而且指向的地址空间必须可读写（通常是SRAM的末尾地址）。

; 典型的汇编启动代码片段
__Vectors       DCD     __initial_sp          ; 0x0000: 栈顶地址
                DCD     Reset_Handler         ; 0x0004: 复位入口
                DCD     NMI_Handler           ; 0x0008
                DCD     HardFault_Handler     ; 0x000C
                ; ... 其他异常向量

; 链接脚本中定义栈顶
__initial_sp = ORIGIN(SRAM) + LENGTH(SRAM);  ; SRAM末尾

我见过有人把__initial_sp定义在SRAM的中间位置，结果堆栈向下增长时，直接覆盖了全局变量区。调试时变量莫名其妙被改，查了两天才找到原因。

  🔑 关键原则： 堆栈指针初始值 = SRAM起始地址 + SRAM大小。这样堆栈向下增长时，有最大的可用空间。如果芯片有TCM或紧耦合内存，优先把堆栈放在那里，性能会好很多。

2.4 从Reset_Handler到main()：看不见的「清场」工作

Reset_Handler是芯片复位后执行的第一段软件代码。它的任务不是直接跳进main，而是先做三件「清场」工作：

初始化全局变量：把.data段从Flash拷贝到SRAM，把.bss段清零
初始化堆栈和堆：设置堆栈边界，初始化C库需要的堆区
调用SystemInit：配置系统时钟、PLL、Flash等待周期等

我习惯把Reset_Handler写成纯汇编，因为这时候C运行时环境还没准备好——你连全局变量都不能用，更别提调用函数了。但有些芯片厂商的库会用C写Reset_Handler，然后在最前面加一段汇编来设置栈指针，再跳转到C函数。两种方式都可以，但我个人更倾向于汇编，因为可控性更强。

; 典型的Reset_Handler汇编实现
Reset_Handler   PROC
                EXPORT  Reset_Handler

                ; 1. 设置栈指针（其实硬件已经做了，但再设一次更安全）
                LDR     r0, =__initial_sp
                MSR     MSP, r0

                ; 2. 拷贝.data段
                LDR     r0, =__data_start
                LDR     r1, =__data_end
                LDR     r2, =__data_flash_start
                BL      copy_data

                ; 3. 清零.bss段
                LDR     r0, =__bss_start
                LDR     r1, =__bss_end
                BL      zero_bss

                ; 4. 调用SystemInit（可选）
                BL      SystemInit

                ; 5. 跳转到main
                BL      main

                ; 如果main返回，进入死循环
                B       .
                ENDP

你可能会问：为什么不能直接在Reset_Handler里调用main？因为C编译器生成的main函数，默认假设全局变量已经被初始化了。如果你跳过.data和.bss的初始化，全局变量全是随机值，程序行为完全不可预测。

⚠ 重要提醒： 在Bootloader中，如果你要跳转到应用程序，必须确保应用程序的全局变量初始化过程被正确执行。我的做法是：在跳转前，先把应用程序的向量表地址写入SCB->VTOR，然后软件触发复位。这样芯片会重新走一遍完整的Reset_Handler流程，应用程序的全局变量自然就被初始化了。千万不要直接函数指针跳转——那等于让应用程序在一个「半脏」的环境里运行。

2.5 完整启动流程：一张图看懂

下面这张图总结了从芯片上电到main()执行的完整路径。我画这张图时，特意把「硬件自动完成」和「软件手动完成」分成了两个区域——这样你调试时能快速定位问题是出在硬件阶段还是软件阶段。

2.6 调试启动流程的实用技巧

说了这么多理论，来点实际的。如果你遇到芯片上电后不工作，怎么定位问题？我总结了一套「三板斧」：

第一板斧：检查向量表。用调试器读0x00000000和0x00000004的值。MSP应该在SRAM范围内，Reset_Handler应该在Flash范围内。如果读出来是0xFFFFFFFF，说明Flash没烧录或烧录地址错了。
第二板斧：检查堆栈指针。在Reset_Handler的第一条指令处设断点，查看MSP的值是否与向量表一致。如果不一致，说明硬件读取有问题，可能是芯片本身坏了。
第三板斧：单步跟踪。从Reset_Handler开始单步执行，观察.data拷贝是否完整、.bss清零是否彻底。我遇到过链接脚本里.data段长度定义错误，导致拷贝时覆盖了其他变量的情况。

💡 我的调试习惯： 在Reset_Handler的最开头加一段汇编，把MSP的值写入一个GPIO引脚（通过位带操作），然后用示波器测量。如果上电后引脚有脉冲，说明芯片至少读到了向量表。这个「穷人的调试器」方法，在我手头没有调试器时救过我好几次。

启动流程是Bootloader的基石。你把这个流程吃透了，后面讲向量表重映射、双区启动、安全校验这些内容时，就会觉得顺理成章。说白了，Bootloader就是在这条「从复位到main」的路径上，插入了自己的逻辑关卡。