1. 上电之后，第一秒到底发生了什么

做嵌入式开发这么久，我带过不少刚入行的新人，发现一个很有意思的现象：大家写 STM32 程序都是打开 Keil、点一下编译、插上调试器、下载、运行，灯亮了就欢呼，灯不亮就怀疑人生。很少有人真正想过一个问题——芯片复位之后、main() 函数的第一行代码执行之前，这中间的几百微秒到底发生了什么？

我为什么突然想聊这个？因为之前有个项目，Bootloader 跳转 APP 的时候偶尔会死机，还有一个 RTOS 项目任务切换时发现了诡异的栈溢出问题。追根溯源，两个问题最终都落到了对启动流程的理解不够透彻上。你如果不清楚复位向量是干什么的、启动文件是怎么一步步把控制权交给 main 的、RTOS 调度器又是怎么"无中生有"地把第一个任务送上 CPU 的，那排查这类问题就只能靠运气。

这篇文章我就把 STM32 上电启动的完整链路彻底拆开揉碎了讲一遍，适合刚学 STM32 的初学者建立整体认知，也适合做了几年开发但一直对启动流程一知半解的老同学查漏补缺。

1.1 复位向量到底在哪：一张"上电后的第一份地图"

先说一个最基础但很多人理解有偏差的概念：复位向量（Reset Vector）。

ARM Cortex-M 内核有一条硬性规定：芯片上电复位后，CPU 会从地址 0x00000000读取一个 32 位数据作为主栈指针（MSP）的初始值，再从地址 0x00000004读取一个 32 位数据作为复位后第一条指令的地址，然后跳过去执行。地址 0x00000004 里存的那个值，就是复位向量的本质——它不是一个跳转指令，而是一个地址值。

这跟传统的 51 单片机不一样，51 是复位后直接跳到 0x0000 地址去执行。Cortex-M 的这套设计把"栈在哪、程序从哪开始"两个信息固化在固定地址上，CPU 不需要任何外部配置就能拉起运行环境。

这里有个重要的细节：我们烧录程序时，代码一般放在 0x08000000（Flash 起始地址）。但 CPU 上电后找的是 0x00000000，那它是怎么找到我们的代码的？

答案藏在 STM32 的存储映射里。STM32 内部有一个"别名映射"机制，芯片根据 BOOT 引脚的电平状态，决定把哪一块物理存储器的地址映射到 0x00000000 这个"零地址区"：

绝大多数正常开发场景都是 BOOT0 拉低，也就是从主 Flash 启动。这时 CPU 虽然访问的是 0x00000000，但实际读到的是 0x08000000 处的内容。我们调试时看到的程序入口地址 0x08000000 也不难理解了。

1.2 向量表：一个排好队的"中断地址簿"

复位向量不是孤零零存在的，它只是整个**中断向量表（Vector Table）**的第一个有效成员。向量表说白了就是一张存放着各类函数地址的表：

• 位置最靠前的两个特殊成员：初始栈指针、复位向量
• 后面的成员：各类异常和中断的服务函数入口地址，比如 NMI、HardFault、SVC、PendSV、SysTick，以及芯片外设的中断（EXTI、TIM、UART、I2C 等）

Cortex-M 内核规定向量表的偏移必须是 2 的整数次幂（通常按 128 字节对齐），因为 VTOR 寄存器（向量表偏移寄存器）的低位会被忽略。

在 STM32 的正点原子或标准库工程里，你可以打开startup_stm32f10x_hd.s文件，开头就是一大串 DCD 伪指令，把各个中断服务函数地址按顺序排好。系统复位后，CPU 会从 0x00000000（经过映射后是 0x08000000）读取第一个字给 MSP，然后从 0x08000004 读取复位向量并跳转执行。

这里我还想强调一个非常关键的进阶点：向量表的位置并不总是固定在 Flash 开头。当你做 Bootloader + APP 的架构时，APP 可能被放在 0x08010000 等偏移地址。此时如果不修改 VTOR 寄存器，中断一来 CPU 仍然会去 Flash 开头找中断服务函数地址，结果找到的全是 Bootloader 里的函数（或者压根不对），程序直接跑飞。这就是很多 Bootloader 跳转后中断不响应的根本原因。解决办法是 APP 启动早期执行SCB->VTOR = APP_BASE_ADDRESS来重定向向量表。这个细节后面讲 Bootloader 跳转时还会再提。

1.3 BOOT 引脚与启动介质：别在硬件上栽跟头

BOOT 引脚的配置在开发调试期容易被忽略，但产品量产阶段它就是个坑。

我记得有个同事做一款手持设备，样机调试时一切正常，量产烧录完程序贴上外壳后，居然出现一批设备"上电没反应"。折腾了半天发现是产线测试时有人把 BOOT0 跳线帽插到了 1 的位置，芯片每次上电都进系统存储器自带的 Bootloader，应用程序根本没跑起来。

这个问题的本质就是启动介质选择。BOOT0=1、BOOT1=0 时，芯片映射的是系统存储器，里面是芯片出厂预烧录的 Bootloader，它主要用于串口下载程序，不会主动跳转执行用户 Flash 里的代码。

实操建议：

• 产品设计时尽量不要把 BOOT0/BOOT1 引脚裸露给用户，或者默认焊接 10k 下拉电阻拉低，避免悬空导致启动介质不稳定。
• 在产品中需要支持 IAP（In-Application Programming）升级时，才通过代码或按键组合把 BOOT0 拉高进入系统 Bootloader，完成后必须确认切回主 Flash。
• 调试阶段如果发现程序"跑起来了但不受控制"，第一步检查 BOOT 引脚，第二步才去怀疑固件。

2. 启动文件：一颗螺丝钉都不能少

确认了复位向量、启动介质之后，CPU 跳到了复位向量指向的位置，也就是启动文件里的Reset_Handler函数。以 STM32F103 的启动文件为例，这部分代码可以说是整个启动流程里的"总导演"。

2.1 startup 文件里都有什么

启动文件（startup_stm32f10x_hd.s）的典型内容可以分成这几块：

• 栈（Stack）空间定义
• 堆（Heap）空间定义
• 中断向量表
• Reset_Handler 汇编函数
• 异常与中断服务函数的弱定义（Weak Definition）

栈的定义很简单：

Stack_Size EQU 0x400 AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE Stack_Size __initial_sp

EQU 0x400表示栈大小为 1KB。有人觉得 1KB 太小，直接改成 0x1000，也没问题，但你要清楚这个改动对内存布局的影响——栈空间是分配在 SRAM 里的，栈加大，堆或全局变量的可用空间就变小。我在做多线程任务时尤其注意栈大小：任务栈和主栈是两回事，启动文件里定义的是主栈（MSP 使用的栈），RTOS 里每个任务有自己的栈，这些后面详谈。

中断向量表在启动文件里长这样（截取部分）：

__Vectors DCD __initial_sp ; Top of Stack DCD Reset_Handler ; Reset Handler DCD NMI_Handler ; NMI Handler DCD HardFault_Handler ; Hard Fault Handler DCD MemManage_Handler ; MPU Fault Handler DCD BusFault_Handler ; Bus Fault Handler DCD UsageFault_Handler ; Usage Fault Handler ...

注意第一个 DCD 后面的值是__initial_sp，它就是栈顶地址。这再次印证了前面的结论：芯片上电会从 0x08000000 读到的第一个值就是栈顶，第二个值才是 Reset_Handler 的地址。

启动文件末尾还用ALIGN、END等伪指令保证向量表对齐到合理边界。这块内容大多数人不需要手动改，但具备阅读能力非常重要。

2.2 Reset_Handler 的日常工作清单

Reset_Handler 的汇编实现（标准库版本）一般是这样的：

Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT __main LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP

不要被这段汇编吓到，它只干三件事：

1. 把 SystemInit 函数的地址装载到 R0，然后调用它。SystemInit 是芯片厂商提供的系统初始化函数，主要完成：配置 Flash 预取缓冲、设置时钟树（PLL、分频器等）、使能外设总线时钟。你会发现 SystemInit 里通常会做一套默认时钟配置（比如 F103 把系统时钟从 8MHz HSI 切换到 72MHz PLL）。如果你在工程里想自定义时钟，可以改 SystemInit 或在自己的代码里重配，但顺序上它必须在 main 之前先跑完，否则后面的代码拿到的时钟是默认低速状态。

2. 把 __main 的地址装载到 R0，然后跳过去。这里注意，__main 不是我们写的 main()，而是 C 库的入口函数。它负责建立 C 运行环境。很多人以为 Reset_Handler 之后直接进 main，其实中间隔了一道 C 库初始化工序。

3. 结束 Reset_Handler。后面就是 C 的世界了。

我之前调试过一个诡异 bug：串口发送的数据开头总是多一个字节的乱码，最终定位到是 SystemInit 里的时钟切换配置没生效，导致 UART 波特率分频算错了。如果当时对启动流程的调用顺序有清晰的认知，可能更快联想到 SystemInit 这一环。

2.3 __main 到 main：C 运行环境的幕后搭建

__main 是 ARM C 库提供的入口，它内部会做这样几件事：

• 拷贝 RW 段：把初始值非零的全局变量（RW data）从 Flash 拷贝到 SRAM。
• 清零 ZI 段：把初始值为零的全局变量区域（ZI data，BSS 段）清零。
• 初始化堆：为 malloc 等动态内存函数准备好堆空间。
• 调用 main()。

这就像你要在一张白纸上画画之前，得先把桌子擦干净、把画笔摆放整齐。没有 __main 的这层"收拾"，你的全局变量初始值可能全是乱码，malloc 也必然失败。

Keil 工程里，你可以在__main的汇编处打断点，然后单步走，会依次看到__scatterload（装载段拷贝）、__rt_entry（运行时入口）等步骤。强烈建议初学者做一次这个操作，比看十遍文档都管用。

这里还有一个容易被忽略的坑：C 库的底层函数（如 printf 重定向、heap 大小）与启动文件里的堆定义关系密切。如果你在代码里大量使用 malloc 而不注意 Heap 大小，可能在某个特殊内存分配场景下直接返回 NULL 指针。传统上大家会把堆加大一点，但更推荐的思路是尽量使用静态分配，嵌入式环境里动态内存的碎片风险和不确定性太高。

3. 从 main() 到第一个任务：RTOS 是怎么"凭空"变出任务的

如果你只是裸机开发，到 main() 就算完成了启动流程。但实际项目中，越来越多的工程师会引入 RTOS（FreeRTOS、RT-Thread、UCOS 等）。那么问题来了：main() 里调用了 vTaskStartScheduler() 之后，第一个任务是怎么被"欺骗"成它一直在运行、然后被切换走的？

这里面的核心机制涉及三兄弟：SVC、PendSV、SysTick。它们仨在中断向量表里的位置紧挨着，在调度器里却各司其职。

3.1 裸机 main()：一个无限循环的世界

裸机开发无非是：初始化硬件、初始化变量、while(1) 里做轮询或中断处理。main() 之后就没有所谓的"启动流程"了，CPU 永远在循环里跑。如果你是裸机开发者，理解到上一节的内容已经足够。

但一旦引入 RTOS，main() 的角色就变成了"系统的孵化器"，它要做的事情多了起来：初始化堆、创建任务、创建队列/信号量、然后启动调度器。调度器启动之后，main() 通常就不再作为一个普通函数返回了，它被调度器"吸收"了。

3.2 vTaskStartScheduler 如何"骗"出第一个任务

以 FreeRTOS 为例，vTaskStartScheduler()内部干了一连串事情后，会调用SVC 0指令（或在新版本中使用svc 0汇编指令），触发一个 SVC 异常。SVC（Supervisor Call）是一个"请求内核服务"的软中断。

为什么要通过 SVC 来启动？因为调度器需要从线程模式切换到特权模式，SVC 异常正好能完成一次特权的提升，还能趁机做上下文切换的初始化工作。

关键的原理在pxPortInitialiseStack()函数：它会给每个任务伪造一个"刚开始运行"的寄存器现场，包括 xPSR、PC（指向任务函数地址）、LR、R0-R12 等。这些值被压入任务自己的栈中，看起来就像是"这个任务刚刚被一个中断打断，才压栈保存了现场"。

然后当 SVC 异常处理函数（vPortSVCHandler）执行时，它会：

1. 获取当前要运行的任务的栈指针（从pxCurrentTCB里拿任务栈顶）。
2. 把这个栈顶指针加载到 PSP（进程栈指针）。
3. 从任务栈里弹出所有伪造的寄存器值。
4. 执行异常返回，PC 直接跳转到了任务函数。

任务函数的第一行代码就这样被"凭空"执行起来了。用一句话总结就是：调度器把第一个任务伪装成了一个"被中断打断过、现在恢复现场"的任务。这种设计非常巧妙，因为它让后续所有的任务切换都能用同一个机制——中断触发 + 现场保存/恢复。

3.3 PendSV 与 SysTick：调度器的左右手

有了第一个任务之后，下一个问题就是：怎么切换任务？

• SysTick：提供系统节拍，相当于一个周期性闹钟。每个 tick 到来时，内核知道"该看看要不要调度了"。在时间片轮转调度里，多个同优先级任务靠 tick 轮换。
• PendSV：可挂起的系统调用，是真正的"任务切换执行者"。它有个特性——可以设置为最低优先级，并且等待其他中断处理完再执行。这样当 UART 中断正在处理时，PendSV 不会打断它，避免了上下文切换与中断服务函数之间的资源竞争。

调度器流程大致是：SysTick 触发 -> 内核判断是否需要切换 -> 需要则置位 PendSV -> PendSV 处理函数里保存当前任务现场、切换 TCB、恢复下一个任务现场 -> 异常返回，新任务继续执行。

这里我需要提醒一个常见误区：很多人把任务栈的大小设置得刚刚好，比如函数调用链非常深、用了比较大的局部数组，结果一压栈就把栈底踩穿了。RTOS 的启动阶段和运行阶段一样，都可能因为栈溢出引发 HardFault。后面我们会专门聊这个。

3.4 从 Bootloader 跳转 APP 时的启动再造

如果你做过带 Bootloader 的架构，需要额外理解"二次启动"的概念。APP 的启动本质上也是从复位向量开始，只是它的"入口"不是真正的上电复位，而是 Bootloader 通过跳转指令主动切过去的。

Bootloader 跳转 APP 之前的准备工作：

1. 关闭全局中断，等待所有中断处理完后清掉挂起的中断标志。
2. 把 APP 向量表地址写入 SCB->VTOR。
3. 重新设置 MSP：__set_MSP(*(volatile uint32_t *)APP_ADDR)，也就是读 APP 向量表的第一个字，把主栈指针切到 APP 定义的栈顶。
4. 取出 APP 复位向量的地址(void *)(*(volatile uint32_t *)(APP_ADDR + 4))，然后函数指针跳转过去。

这一步如果遗漏，后果很典型：APP 里跑起来了但调了中断就死机，或者在跳转瞬间直接 HardFault。

我自己踩过一个大坑：Bootloader 跳转前没有把外设时钟重新配置，APP 的 SystemInit 虽然会重设时钟，但某个外设在上一个程序里被打开且继续跑着，跳转后新程序对这个外设的状态完全不知情，中断标志也没清，结果 APP 起来后一开串口就进中断风暴。经验是：Bootloader 要把用过的外设彻底 DeInit 一遍，或者 APP 启动早期对所有外设做一次完整的复位配置。

4. 启动阶段最常见的坑与排查实录

这一节我整理了近几年大家问得最多、我也实际踩过的启动阶段问题，希望能帮你在遇到类似情况时少走弯路。

4.1 一上电就 HardFault：定位三板斧

HardFault 是 Cortex-M 最常见也最令人头疼的异常之一。很多人遇到 HardFault 就懵了，其实定位方法非常固定：

第一板斧：确定是哪个栈在起作用。看 LR（链接寄存器）的值：

• LR 如果等于0xFFFFFFF9，说明使用的是 MSP（线程模式/主栈）。
• LR 如果等于0xFFFFFFFD，说明使用的是 PSP（进程栈，RTOS 环境常见）。

这个区分很重要，因为 HardFault 现场的寄存器组保存在当前使用的栈里。如果是 PSP，你需要把 PSP 指针带到 Keil 的 Watch 窗口里，才能看到任务栈里的现场值。

第二板斧：看 PC 和 LR 是多少。这两个值指向的是发生异常时正在执行的指令地址和返回地址。把它们对应到编译出的 map 文件或反汇编文件，基本能定位到是哪个函数炸了。

第三板斧：查 Fault 状态寄存器。在调试器的寄存器窗口里找CFSR（可配置故障状态寄存器）、HFSR（硬故障状态寄存器）、BFAR、MMFAR等，能区分 Bus Fault、Usage Fault、MemManage Fault 的具体原因。比如CFSR里IBUSERR位置位，说明取指令时访问了非法地址——很可能是函数指针跳错了位置。

4.2 调试器连不上、程序反复复位

这类问题常见于量产板。排查优先级我建议按这个顺序：

1. 检查电源和复位电路：NRST 引脚如果波形有抖动或异常低电平拉低，芯片会一直在复位状态。
2. 检查 SWD 引脚是否被复用：STM32 的 PA13/PA14 是 SWDIO/SWCLK，PA15、PB3、PB4 是 JTAG 相关引脚。很多工程为了省引脚会把它们配置成普通 GPIO，一旦烧录过这种程序，重新连接调试器就会失败。
3. 低功耗模式误入：代码里过早进入 STOP/STANDBY 模式，导致 CPU 不响应调试请求。

针对第 2 点有一个恢复手段：使用 ST-Link Utility 的 Connect Under Reset 功能，先让芯片停在复位状态再连接调试器，然后擦除 Flash，程序就恢复了。这也是我在量产阶段必教给产线工程师的技能。

4.3 启动阶段问题排查速查表

下面这张表适用于上电启动后"完全不工作"或"行为异常"的场景：

4.4 启动流程实战中容易被忽略的寄存器级细节

很多教科书只会告诉你"启动文件跳转到 main"，但实际工程里你会碰到更多硬件层面的坑。我分享几个自己调试中真实遇到过的细节：

第一个是做低功耗唤醒后的启动路径。STM32 从 STOP 模式唤醒后，不会经过完整的 Reset_Handler 流程，CPU 会继续执行唤醒点之后的代码，但系统时钟可能已被硬件重置为默认的 HSI。很多工程师在这里踩坑：任务恢复正常了，但串口波特率全错，就是因为你没有在唤醒代码里重新调用 SystemInit 或重新配置 PLL。

更隐蔽的是 Standby 模式唤醒，那是一次真正的复位，但它走的是NRST 复位或唤醒复位路径，和上电复位不完全等同。具体差异在各型号的参考手册里有张复位源表格，值得翻一翻。

第二个是 IWDG（独立看门狗）导致的循环复位。这类问题让人非常抓狂：芯片刚启动，看门狗就开始计时，如果你在启动早期初始化 IWDG 后又恰好在设置超时参数前发生了某种阻塞（比如等待 Flash 操作、等待外部器件应答），IWDG 超时，芯片复位，然后又重复这个过程，表现为"永远卡在启动异常里"。我用示波器测 NRST 引脚时会看到一系列规律的复位脉冲，非常典型。

解决思路很简单：确认是否是看门狗复位，通过RCC->CSR里的复位标志来区分；然后在初始化流程里尽快喂狗，或者设计上让看门狗在关键初始化完成之后再开启。

第三个是 Flash 预取缓冲和指令延时（WS）配置。这是很多人完全忽略的启动细节。STM32 的 Flash 接口有一个等待状态寄存器（FLASH_ACR），它决定了 CPU 在访问 Flash 时插入几个等待周期。如果你主频较高却没有正确设置 WS 值，Flash 读取时序就比 CPU 慢，轻则程序偶尔跑飞，重则启动后随机死机。SystemInit 里其实已经处理了这部分，但如果你自己写了过早起频的代码或跳过了 SystemInit，问题就会出现。之前有个项目把 SystemInit 精简掉、自己用寄存器配置时钟，结果发现运行到某个耗时函数就会随机崩溃，最后就是 WS 配置不对导致的。

第四个是任务上下文切换时的栈对齐问题。ARM Cortex-M 内核要求栈指针在进入异常处理时保持 8 字节对齐（AAPCS 调用约定）。RTOS 创建任务栈时如果初始栈帧的地址没有按 8 字节对齐，某些使用浮点或双字加载的代码就可能出错。古怪的是，这类问题只在特定编译器优化级别下才暴露，排查起来非常隐蔽。检查你的 RTOS 移植层里pxPortInitialiseStack对栈指针的处理，以及在任务入口使用__ALIGN(8)等对齐宏，是这类问题常见的解法。

4.5 现场调试的三个小技巧

最后分享几个我在实际调试启动流程时常用的技巧：

• 在 Reset_Handler 入口打断点。Keil 里进入 Debug 后自动停在 Reset_Handler，这时候可以单步观察 SystemInit、__main 的调用过程。既能看到时序，也能确认时钟配置是否生效。
• 在 main() 开头观察全局变量。如果发现有变量初值不是预期值，说明 RW/ZI 段初始化有问题，回溯分散加载文件（.sct）或启动文件。
• 用 RTT/串口打印启动阶段耗时。在 SystemInit 之前记录 SysTick 或 DWT 计数器值，在 main 里再读一次，能算出从复位到 main 的耗时。这个数据在做低功耗唤醒时间优化时非常有用。

关于启动流程的完整理解，我个人的体会是：别把它当成"IDE 自动生成的东西"就跳过不看。启动文件虽然很多年都不需要改一次，但一旦你的项目进入 Bootloader 开发、低功耗唤醒优化、或者 FreeRTOS/CubeMX 的深度定制阶段，前面偷的懒都会在调试时加倍还回来。花一个下午把启动文件从头到尾通读一遍，把断点打进每一段关键代码，实际走一遍启动流程，这个投入的回报远超你的预期。