搞过几年代码的工程师大概都有这种体会：写STM32程序的时候，点一下烧录，板子就跑起来了，但要是有人问一句“芯片到底是怎么从‘没电’走到main函数的”，很多人不一定答得上来。平时调试遇到问题，例如中断进不去、全局变量初值不对、上电就死机，最后追根溯源都会撞到“启动流程”这堵墙上。
这篇就从头到尾把STM32的上电启动流程拆开，从硬件复位、向量表、栈指针，到启动文件里的每一句汇编代码，再到C库初始化，一条线拉通。内容基于Cortex-M3内核做主线展开，同时说明Cortex-M4/M0的差异，用的是标准库加MDK的环境，但原理完全不限于某个具体型号。
1. 上电启动这件事，到底分几个阶段
拿一块STM32F103最小系统板举例：插上USB供电，芯片的VDD引脚电压拉升，主频时钟信号开始震荡，内核从复位状态释放。从这一刻到main()里的第一行C语言被执行，期间发生的事情可以分成三个层面。
第一层是硬件层面。电源电压上升到阈值后，芯片内部的电源管理模块产生上电复位，整个芯片所有寄存器回到默认值。此时程序计数器PC被硬件强制指向一个特殊地址：0x00000000。不要以为这个地址上存的是代码，Cortex-M架构里，地址0x00000000处放的不是第一条指令，而是初始栈指针SP。地址0x00000004处放的也不是第二条指令，而是复位向量的地址。这是Cortex-M内核一个非常容易混淆的地方——ARM7时代的芯片，地址0x00000000确实是第一条指令，到Cortex-M改成了向量表放在最前面，开局就是数据和地址的混排。
第二层是内核层面。硬件把地址0x00000000的内容加载到MSP寄存器，也就是主栈指针；再把地址0x00000004的内容加载到PC。因为STM32的Flash从0x08000000开始，而复位向量指向的地址通常就是0x08000004附近，PC从Flash里取出复位处理函数的地址后，马上跳转过去执行。官方启动文件里，这个函数名叫Reset_Handler。
第三层是软件层面。Reset_Handler做三件核心工作：调用SystemInit()配置时钟树和Flash等待周期，把只读数据段从Flash拷贝到RAM，把未初始化数据段清零，最后跳进C库的__main，由它完成C环境的准备，再调进用户的main()。
三层串起来，就是一句话：硬件抬电，内核取向量表，固件搬数据、清内存，C库铺路人，用户代码开场。标题上说的“上电启动流程逐行拆解”，拆的就是第二层和第三层里那些逐条执行的汇编指令。
2. 向量表和栈指针：上电第一瞬间到底发生了什么
2.1 向量表的结构与存储位置
STM32的向量表从Flash起始地址0x08000000开始排列。表里每4个字节一项，第一项放初始栈指针，第二项放复位向量，后面依次是NMI、硬错误、各种外设中断的入口地址。Cortex-M3要求向量表至少按4字节对齐，STM32实际按8字节对齐处理，因为表头需要容纳一些额外信息。
向量表里的值，写程序的人基本不会手动维护。MDK工程里用启动文件加上分散加载文件，编译器把向量表放在名为__VECTOR_TABLE的段里，再把这个段链接到0x08000000。打开编译出的map文件能看到这样的信息：
__VECTOR_TABLE 0x08000000 0x130 Data这说明向量表在Flash里占了0x130个字节，从0x08000000开始放。第一项数据0x20005000之类，就是启动时给MSP赋的初始值。
这里有个很多人没想透的细节：Cortex-M规定上电复位后，CPU从地址0x00000000取栈指针，从0x00000004取复位向量。但STM32的代码明明在0x08000000，为什么CPU能找到？因为STM32启动时，芯片内部的BOOT模式决定了地址0x00000000映射到哪里。在FLASH启动模式下，0x00000000被映射到0x08000000，CPU从0x00000000读，实际上读到了Flash里0x08000000地址的内容。
2.2 初始栈指针为什么指向RAM末尾
向量表第一项写0x20005000，这是STM32F103C8的RAM地址0x20000000加上20KB容量得到的末地址。为什么栈指针初值指向RAM的最高地址？因为Cortex-M的栈是向下生长的满递减栈——压栈时SP先减地址，再写入数据。初始SP指向RAM的最高地址，栈向下往低地址延伸，就有最大的可用空间。
有的同学自己写链接脚本，栈指针写错了，例如写成RAM的起始地址，一上电程序直接卡死。因为第一次调用压栈就把数据写到了不可用的地址上。遇到这类问题，别去调试C代码，先查启动文件里的栈空间定义和向量表第一项。
2.3 复位向量的B1位与Thumb模式
向量表第二项指向复位处理函数入口，例如0x08000149。注意这个地址末尾是奇数。Cortex-M内核只支持Thumb指令，它要求所有函数地址的bit0为1。CPU跳转时，实际上把0x08000148这个偶地址当作真正的指令地址，bit0被用作状态切换标志。
人工编写启动文件时，经常会在标号后面看到- 1或者| 1这样的运算，目的就是给函数入口地址加上这个特殊的bit0。汇编器在处理LDR R0, =Reset_Handler这类伪指令时，会自动把地址的最低位标上Thumb标志。如果写裸机程序时自己手工构造跳转表，最容易踩的坑就是把bit0给抹掉了，导致CPU跳到地址后进入错误状态。
3. 启动文件汇编逐行分析：Reset_Handler是怎么干活的
打开STM32标准库里的startup_stm32f103xe.s文件，搜索Reset_Handler，可以看到一段不到20行的汇编代码。这段代码是理解整个启动流程的核心，下面逐段拆。
3.1 异常向量表与数据段声明
启动文件开头是向量表声明，用汇编器伪指令逐项列出中断入口地址。以某常见Cortex-M3启动文件为例，开头大致长这样：
Vector_Table: DCD __initial_sp DCD Reset_Handler DCD NMI_Handler DCD HardFault_Handler ... DCD WWDG_IRQHandler ...DCD是“定义常量字”的伪指令，意思是在当前地址放一个32位数值。__initial_sp是链接器生成的符号，指向栈顶地址。这里每一项占用4字节，向量表整体长度取决于芯片有多少中断源。
后面还有一段AREA声明。例如：
AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE 0x400 __initial_spSPACE 0x400表示在这块区域预留1KB字节空间，__initial_sp被定义在这块预留空间的末尾。修改栈大小时，要修改SPACE后面的数值，并且确认链接脚本或启动文件用的是同一个符号。栈开太小，程序里递归稍深就会发生栈溢出，数据把堆或者变量区冲掉，行为极其诡异。
3.2 Reset_Handler标准实现
Reset_Handler PROC EXPORT Reset_Handler IMPORT SystemInit IMPORT __main LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP第一句LDR R0, =SystemInit是伪指令，把SystemInit函数的地址加载到R0。第二句BLX R0带链接跳转并切换指令集。执行完后，控制权回到Reset_Handler，接着加载__main的地址，用BX R0跳过去。
SystemInit是标准库提供的函数，它的作用藏在某官方标准库的system_stm32f10x.c里。主要做几件事：设置Flash等待周期、使能外部高速晶振、配置PLL倍频系数、把系统时钟切换到PLL输出。以F103为例，经过这个函数，系统时钟从HSI的8MHz最终变成72MHz。如果晶振没接或者频率不对，代码往往卡在等待HSE就绪的死循环里。
__main不是用户写的main，它是C库的入口函数。MDK的ARM编译器在嵌入式场景下，__main负责调用__scatterload完成代码和数据的加载，再调用__rt_entry建立C运行环境，最后才调用用户的main。整个链路比很多教程描述的“直接跳进main”要长一截。
3.3 数据段拷贝和BSS段清零的隐藏位置
很多人在启动文件里找不到拷贝data段和清零bss段的汇编指令，误以为启动文件不干这些事。真相是，这些动作被__main接管了。
ARMCC编译器编译C程序后，会生成一个名为__main.o的C库启动目标文件。它先把加载域和运行域的地址对比，如果发现数据段需要从Flash拷到RAM，就调用__scatterload_copy执行逐字节拷贝，然后把未初始化的全局变量所在的bss段清零，最后调用__rt_entry里的__rt_lib_init把C库的堆、标准IO等环境准备好。
简化的启动流程可以概括为：
Reset_Handler调用SystemInitReset_Handler跳转__main__main完成数据段复制与BSS清零- C库初始化运行环境
- 调用用户
main
如果读者用的是GCC工具链，启动文件会自己写__copy_data和__clear_bss，因为GCC的C库入口不自动做这些事。这就是为什么同一个工程换编译器之后，启动文件也要跟着换，不能混用。
4. 时钟配置和C库启动：main之前那些BSP开发者经常忽略的坑
4.1 SystemInit里的关键寄存器变化
SystemInit在跳转到__main之前执行，它在C环境下运行，能正常调用变量完成复杂计算。它的输出直接决定了后续所有外设的工作频率。这里以标准库默认配置为例，函数内几个关键动作值得一条条看：
- 设置
FLASH->ACR，把Flash等待周期配置为2个周期，保证72MHz总线频率下Flash读取不丢失； - 调用
RCC_DeInit把所有时钟复位于默认状态； - 开启
HSEON，等待外部晶振就绪； - 配置PLL的倍频系数，把8MHz外部晶振倍频到72MHz，涉及到PLLSRC、PLLMUL等位域；
- 配置AHB、APB1、APB2的分频系数，得到72MHz、36MHz、72MHz的总线频率；
- 最后把系统时钟切换器SW切到PLL输出。
调试时如果把断点打在SystemInit内部，单步执行，能清楚看到RCC->CFGR这个寄存器从0x00000000逐步变成0x001D0000左右的值。整个过程中，Flash控制器、总线分频和PLL三个模块的顺序是有讲究的。如果先把总线频率提上去了才去配置Flash等待周期，读取指令就会出错。
4.2 __main阶段的两个关键动作
__main的执行过程涉及两个核心动作。第一个是把加载域（Load Region）和运行域（Execution Region）对齐。C程序编译出来后，初始化的全局变量在Flash里有一份初值，运行时要搬到RAM里才能被读写。__scatterload就是干这件事的。第二个是把没有初值的全局变量和静态变量所在的BSS段全部清零。
这两个动作如果出差错，表现五花八门。常见的一种是：上电后某些全局变量不是默认的0，而是带了一堆乱值。原因多数不是启动代码的问题，而是分散加载文件里某个段的属性标错了，或者C库初始化被某种方式跳过。另一种是某变量明明赋了初值，上电却是0，这往往是把数据段放到了只读属性区域，拷贝动作没触发。
__main PROC LDR R0, =__scatterload BLX R0 LDR R0, =__rt_entry BX R0 ENDP这是ARMCC库启动最精简的骨架。__rt_entry里还包括__rt_lib_init，它把标准C库函数需要的环境（例如堆指针、浮点环境）配置好。用户C代码用到的malloc、printf一类依赖，都挂在这一级，这也是为什么嵌入式里常常碰到一个问题：直接跳转到用户main能跑，但从正常启动流程进去就出现各种库函数异常，核心区别就在这里。
如果读者需要做极简启动、不依赖C库，可以绕过__main，自己完成数据段拷贝和BSS清零后，直接跳进main()。但这么做的代价是C库的malloc、浮点打印之类功能可能全部不可用。
4.3 为什么说启动文件里其实没有用户代码的容错空间
启动文件是芯片复位后执行的第一份软件，这个阶段RAM还没有初始化完，也不存在“正常”的C运行环境。因此在Reset_Handler里尽量不做复杂计算，不要调用依赖初始化的库函数。所有需要严格时序的初始化，例如外部SDRAM、DMA，也应该放到SystemInit之后、用户main开头去做。有人喜欢把外设初始化放在Reset_Handler里，以为能提前准备好一切。实测下来，一进入SystemInit把时钟切到72MHz，Flash等待周期一变，之前那些“提前准备”很可能全部失效，属于典型的白费功夫。
5. 实操记录：从烧录到main的断点追踪
拆完原理，用实际操作验证一遍。手头一个F103C8T6的最小系统板，MDK5.28编译环境，SWD下载，调试器选内置的CMSIS-DAP。下面是一段真实的排障经历。
5.1 在Reset_Handler打断点
打开工程，在Reset_Handler的LDR R0, =SystemInit这一行前打一个断点，全速运行。能停在断点处，说明芯片上电、Flash读取、向量表跳转都正常。如果连这里都到不了，优先检查BOOT0引脚电平是不是被拉到了系统存储器模式，或者SWD引脚被复用导致无法连接。
第一次在开头打点，实机运行后停在断点，四字节附近的数据如下：
地址0x08000000存放0x20005000，是栈顶地址；0x08000004存放0x08000149，是Reset_Handler的地址。在MDK的Memory窗口里能直接核对。
5.2 单步跟过SystemInit
从断点单步走，进入SystemInit后，核心寄存器变化如下：
| 寄存器 | 复位值 | 执行后典型值 | 说明 |
|---|---|---|---|
| RCC->CR | 0x00000000 | 0x01010001 | HSI开启、HSE开启并就绪 |
| RCC->CFGR | 0x00000000 | 0x001D0400 | PLL倍频9，USB预分频1.5，MCO关闭 |
| FLASH->ACR | 0x00000000 | 0x00000012 | 等待周期2周期，预取使能 |
| RCC->CR（PLL） | 0x00000000 | 等待结束后置位PLLRDY | PLL锁定 |
单步过SystemInit后，继续走，会进入__main，再到__scatterload，然后从Flash向RAM地址0x20000000附近搬运数据。在__scatterload循环里观察RAM数据变化，可以看到各个初始化全局变量的值被逐个写入。
5.3 断在用户main的第一行
在用户main第一行打断点，全速运行，能稳定停住，说明整个链路上所有环节都正常。剩下的事情就交给应用逻辑。
实机操作时，我习惯在Reset_Handler、SystemInit返回后、用户main开头各打一个断点，分三次确认链路健康度。这也是排查“上电后系统异常”最高效的方法。
6. 常见故障与排查思路：上电死机、变量错乱、中断无效逐个击破
6.1 时钟配置死循环
现象：程序上电后完全没有输出，调试器能连上，PC停在一个类似while的循环里，通常是SystemInit内等待外部高速晶振就绪的代码。排查方法：用示波器或万用表测外部晶振两个引脚，确认8MHz波形正常。手头没有示波器时，可以在SystemInit里把HSERDY标志位的循环加一个超时计数，跑几秒后强制跳过，看后续执行是否正常。很多时候不是晶振坏了，而是晶振两端的负载电容值不对，导致起振条件不满足。
6.2 全局变量初值丢失
现象：一个定义为uint8_t flag = 1;的全局变量，上电后flag的值是0。打开map文件查阅这个变量所在的区域，如果它的地址落在ZI段而不是RW段，说明编译器把初始化值放丢了。更常见的原因是分散加载文件里把该数据段标成了NOINIT属性。标准库工程不怎么会遇到这个问题，一旦自己写过分散加载文件，就有概率踩中。
6.3 中断向量表偏移
现象：程序实现了BootLoader加App的结构，App的代码偏移到0x08008000启动，中断全部失效。原因几乎都在于App的向量表还停留在0x08000000，CPU触发中断后去读的是BootLoader的向量表。解决方法是把NVIC_SetVectorTable或者SCB->VTOR设置成0x08008000。
对于Cortex-M3/M4，可以在main最开始写：
SCB->VTOR = 0x08008000;对于Cortex-M0/M0+，没有VTOR寄存器，App必须在链接时就固定向量表到正确偏移，并把代码设计成不依赖中断偏移的形态。
6.4 栈溢出引发的启动崩溃
现象：程序烧进去以后，在main入口正常，执行几个函数后突然跳到HardFault_Handler。打开调试器看调用栈，发现SP值低得离谱。把启动文件里Stack_Size从0x400改成0x1000，问题消失。这就是栈空间不足。实际工程里，尽量不要在中断处理函数里放长数组或递归调用，中断栈和主栈共用同一块MSP空间。
进HardFault后，一个实用的排查办法是查看压栈现场。Cortex-M进入异常时，硬件自动把R0、R1、R2、R3、R12、LR、PC、xPSR这8个寄存器压到当前栈上。在调试器的寄存器窗口里，找到进入异常前PC的值，对照反汇编代码，一般能定位到触发异常的指令。
6.5 调试器复位后不同步
现象：下载完程序后，点调试器复位按钮，PC跳到复位向量，但外设寄存器还停留在上一次运行状态，与冷启动行为不一致。这是调试复位和上电复位的差异。真要复现上电场景，直接给板子断电再上电，或者用调试器的系统复位功能配合硬件复位引脚。做启动流程测试时，别偷懒只依靠调试器的复位，最可靠的就是手按电源开关。
7. 一份最小启动工程的完整参考
为了验证整个流程，可以自己从头写一个最小工程，不依赖标准库的启动文件，手工写向量表和启动汇编，更能看清每一个环节的依赖关系。
7.1 工程结构与启动汇编
工程包含三个文件：startup.s、main.c、link.ld。启动汇编如下：
.syntax unified .cpu cortex-m3 .thumb .section .isr_vector, "a", %progbits .word _estack .word Reset_Handler .word NMI_Handler .word HardFault_Handler .word MemManage_Handler .word BusFault_Handler .word UsageFault_Handler .section .text .thumb_func .global Reset_Handler Reset_Handler: ldr r0, =_estack mov sp, r0 ldr r0, =SystemInit blx r0 ldr r0, =__copy_data blx r0 ldr r0, =__clear_bss blx r0 ldr r0, =main blx r0 b .这里手动设置了MSP，调用了时钟初始化、数据段复制、BSS清零，然后进入main。注意MSP赋值，向量表里第一项虽然已经给了栈顶，但为了直观确认内核行为，也可以在Reset_Handler里再用ldr和mov sp显式设置一次。冗余但有效。
__copy_data和__clear_bss用C实现，放在main.c里：
extern char _sdata, _edata, _sbss, _ebss; void __copy_data(void) { char *src = &_sdata; char *dst = &_sdata; while (dst < &_edata) *dst++ = *src++; } void __clear_bss(void) { char *dst = &_sbss; while (dst < &_ebss) *dst++ = 0; }实际上src和dst不能直接如此使用，因为_sdata的地址在加载域和运行域不同。正确的写法要用链接脚本里的_la_sdata这种加载域地址符号。这里为了表达原理做了简化表达，如果照抄到工程里，需要再查工具链的符号规则。
7.2 链接脚本的关键定义
GCC链接脚本里需要明确三个区域：向量表、代码、数据。核心段定义如下：
MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K } _estack = ORIGIN(RAM) + LENGTH(RAM); SECTIONS { .isr_vector : { . = ALIGN(8); KEEP(*(.isr_vector)) . = ALIGN(8); } >FLASH .text : { *(.text) *(.rodata) } >FLASH _sidata = LOADADDR(.data); .data : { _sdata = .; *(.data) _edata = .; } >RAM AT> FLASH .bss : { _sbss = .; *(.bss) _ebss = .; } >RAM }以_estack这个符号为例，它的值就是RAM末地址0x20005000。向量表段被KEEP强制保留，数据段被标记为加载在Flash、运行于RAM，启动代码实现搬运。
7.3 手写工程的验证结果
在这个最小工程里放一个简单的GPIO翻转逻辑，上电后用一个逻辑分析仪抓引脚波形。如果Pin频闪，说明整条启动链完全跑通。我曾把启动汇编里的BSS清零注释掉，定义了一个int g_val = 0;的全局变量，在main的开头判断它是否为0。结果发现变量的初值可能是上电时RAM里的残留数据，导致条件分支异常。这个实验最能直观说明BSS清零存在的意义。
8. 启动流程背后的通用设计思想
看完整个流程可以发现，STM32的启动流程其实不是某个芯片特有的做法，而是现代MCU的通用范式：硬件只负责把控制权交给一段已知地址，剩下的环境准备交给固件。理解这一点以后，再去看其他Cortex-M芯片，例如GD32、MM32、NXP的LPC系列，启动流程几乎一致，差异只在向量表偏移、时钟树结构和库函数命名上。
每颗芯片上电后都需要回答三个问题：栈在哪、第一条代码在哪、C环境如何就绪。这三点分别对应向量表第一项、向量表第二项、库入口__main。搞懂了这三个问题，遇到任何陌生的ARM MCU都不会抓瞎。
回到STM32本身，个人最常见的启动相关BUG，几乎都集中在两个位置：一是外部晶振起振失败后的死循环，二是分散加载文件里数据段属性标错。前者用超时保护解决，后者打开map文件核对RW段分布就能发现。
这一套流程读下来，下次再有人问“STM32上电以后第一件事是什么”，心里就有底了。硬件在抬电后第一件事是抓地址，然后所有动作都在解决同一个问题：让C语言的世界看起来一切正常。能把这段链路在脑内跑一遍，比记多少外设库函数都值。
