STM32上电启动流程详解：从复位向量到C运行时的完整链条

1. 上电那一刻：CPU怎么知道去哪里执行第一条指令

1.1 复位矢量与初始SP的硬件行为

先说一个很多人没意识到的点：Cortex-M3内核的STM32，上电后并不是从“第一行代码”开始执行的，而是先干两件非常底层的事——读存储器最前面的两个字。地址0x00000000处的值会被加载到MSP（主栈指针），地址0x00000004处的值会被当作复位后第一条指令的地址加载到PC。做完这两步，CPU才算真正“活过来”，开始取指执行。

所以，所谓的“上电启动流程”，本质就是回答两个问题：初始栈指针放在哪、第一条指令在哪。答案都写在启动文件里。从硬件行为来看，Cortex-M3的复位时序是确定的，它不管你烧录的是不是STM32官方的启动文件，只要向量表前两个字合法，就能跑起来。这也解释了为什么有人随便改了启动文件还能跑，而有人改动了一点点就彻底死机。

新手第一次打开startup_stm32f10x_hd.s，满屏的EQU、AREA、SPACE、DCD确实劝退。但你把它当成一张“内存布局清单 + 跳转安排表”逐行看，会发现逻辑非常简单：先划内存区域，再布置向量表，最后跳转到C代码。下面我按这个思路拆。

1.2 BOOT引脚：决定从哪块存储区启动

这里要带上STM32特有的BOOT机制。BOOT0和BOOT1引脚在复位释放时的电平组合，决定CPU从哪个存储区加载向量表，而不是由软件随便切换的：

从Flash启动时，芯片内部会把Flash基地址0x08000000映射到0x00000000。也就是说，向量表虽然从地址0读取，但实际读到的是Flash里的内容。那个“Vector Table Mapped to Address 0 at Reset”是真真切切的硬件行为，不是随便写的注释。如果BOOT引脚被拉错，程序烧进去了也不跑，这是新手最容易碰到的“假死”现象之一。我工作中排查过不少这类问题，最后都是万用表一量BOOT0才发现被上拉电阻拉高了。

1.3 谁把控制权交给启动文件

光有启动文件还不够，还得保证它被放在Flash的最前面。这由链接脚本控制。对MDK来说，.sct散列文件会把RESET段放在0x08000000开头；对GCC工具链来说，.ld链接脚本用KEEP保留启动目标文件并排在最前。如果启动文件没排到最前，CPU上电取向量表取到的是别的代码，行为完全不可预测。

我见过一个项目，为了“精简工程”，把启动文件从工程里移除，自己写了个C文件想用函数指针强行指定入口，结果上电直接HardFault。这种尝试没必要，也不建议。启动文件是芯片厂商验证过的骨架，我们真正要做的不是推翻它，而是理解每一行到底干了什么。

2. 从 startup 文件的栈和堆开始逐行读汇编

2.1 栈区与堆区的AREA定义：先划地皮再干活

以最常见的startup_stm32f10x_hd.s为例，文件最先出现的是这样一段：

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

第一行EQU就相当于C里的#define，把Stack_Size定义为0x400字节，也就是1KB。接着AREA STACK, NOINIT, READWRITE声明了一块名为STACK的区域，属性是不初始化、可读可写，ALIGN=3表示8字节对齐。为什么是8字节而不是4字节？因为AAPCS过程调用标准要求栈指针在异常入口和函数调用边界保持8字节对齐，这是为了兼容某些需要64位原子操作的指令。

SPACE Stack_Size会在这块区域中预留出1KB空白空间，这就是栈空间本身。最后的__initial_sp是一个标号，它指向这块空间的结束地址，也就是栈顶。栈向下增长，所以入口处的标号应该是空间的最高地址，而不是起点。

紧接着是堆区的定义：

Heap_Size EQU 0x00000200 AREA HEAP, NOINIT, READWRITE, ALIGN=3 __heap_base Heap_Mem SPACE Heap_Size __heap_limit

堆大小默认512字节，__heap_base指向堆起点，__heap_limit指向堆终点。如果你的代码大量使用malloc，这个默认值几乎不够用，建议在工程配置里改大，或者干脆避免动态内存分配。在嵌入式里，我一般建议静态分配优先，原因不只是碎片的确定性，还因为启动文件里默认堆确实很小。

2.2 向量表的DCD逐个定义：一张异常入口登记表

接着是RESET段的定义和向量表本体：

AREA RESET, DATA, READONLY EXPORT __Vectors EXPORT __Vectors_End EXPORT __Vectors_Size __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 0 ; Reserved DCD 0 ; Reserved DCD 0 ; Reserved DCD 0 ; Reserved DCD SVC_Handler ; SVCall Handler DCD DebugMon_Handler ; Debug Monitor Handler DCD 0 ; Reserved DCD PendSV_Handler ; PendSV Handler DCD SysTick_Handler ; SysTick Handler

DCD是分配一个4字节的字，等价于C里的const uint32_t数组元素。向量表第一个元素是栈顶地址，第二个元素才是复位处理函数地址，剩下的按Cortex-M3内核异常顺序排列。注意前16个向量是内核级异常：NMI、HardFault、SVCall、PendSV、SysTick等，这是ARM Cortex-M3的通用设计，不是STM32自创的。从第17个向量开始才是外设中断，比如WWDG、PVD、TIM、SPI、USART、EXTI这些，全部逐一用DCD登记。

每个DCD后面的符号地址，链接器会自动处理最低位的Thumb标志位。Cortex-M3只支持Thumb指令，硬件取向量时要求地址最低位为1，链接器会在重定位阶段自动把这个位写进去。所以你在源码里看到的是DCD Reset_Handler，而在实际启动时，PC加载的值是Reset_Handler地址 | 1。这是新手常问的点：为什么向量表里的地址看起来不符合4字节对齐？其实是对齐的，最低位的1是状态标志，不是地址的一部分。

向量表最后会有这样几行：

__Vectors_End __Vectors_Size EQU __Vectors_End - __Vectors

__Vectors_Size算出的向量表总字节数，会被某些库函数用于校验表长。比如在IAP升级时，可能用它确认APP向量表是否完整。简单说，这张表就是一张“异常/中断入口登记表”，硬件猜不出你的Handler地址，只能查表。

2.3 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

逐行解释：

• EXPORT Reset_Handler [WEAK]：导出这个符号，并标注为弱定义。如果你在这个文件的任何其他位置或者C代码中定义了一个强符号Reset_Handler，链接时就会优先选择强符号。对绝大多数人来说，不会自己去覆盖复位函数，所以这个弱定义只是保险。同样的弱导出机制也应用于NMI_Handler、HardFault_Handler等所有默认Handler。

• IMPORT SystemInit：把外部C函数SystemInit引入到汇编文件中。这是启动流程中唯一一个直接调用的C函数，它的职责是配置系统时钟。为什么要单独拎出来？因为芯片厂商希望你把时钟初始化放在进入main之前，这样整个C环境的运行时频率是稳定的，而系统时钟又恰恰是后续所有外设与延时逻辑的基础。

• IMPORT __main：引入C库的入口函数。注意这里不是main()，而是C运行时库的__main。它负责后续的数据段复制、清零和最终跳转到真正的main。这个名字来自ARM编译器的启动库，GCC工具链下对应的符号是_start，作用类似。

• LDR R0, =SystemInit：把SystemInit的地址加载到R0。LDR Rd, =label是ARM汇编的一条伪指令，它把标签地址当作立即数装入寄存器，而不是从内存加载值。这一步是后面间接跳转的准备。

• BLX R0：跳转到R0指向的地址，同时伴有链接寄存器。如果SystemInit是普通C函数，返回后应该回到这里继续执行。

• LDR R0, =__main+BX R0：再加载__main地址并跳转，这次不再要求返回，因为启动流程交出去了。

为什么用了LDR + BLX而不是直接BL SystemInit？直接BL当然也能跑，但伪指令加间接跳转的好处是：在链接时对符号的地址解析更灵活，尤其适用于不同编译选项下的位置无关代码或复杂重定位场景。官方启动模板这么写，很大程度上是为了在所有情况下都稳妥。你在理解阶段知道这点就够了。

比较微妙的一点：SystemInit返回之后，马上执行LDR R0, =__main。但SystemInit本身只做了寄存器级配置，没开中断、没使能外设、没初始化变量。中断被使能是后面的事。这是刻意设计的，在C运行时初始化之前尽量保持环境干净。

2.4 其他弱定义Handler：死循环不是Bug而是保护

Reset_Handler下面通常是一大片这样的代码：

NMI_Handler PROC EXPORT NMI_Handler [WEAK] B . ENDP HardFault_Handler PROC EXPORT HardFault_Handler [WEAK] B . ENDP

B .是“跳到当前地址”，也就是原地死循环。任何没有在C工程里定义同名函数的异常，都会默认进到这里并被卡死。很多同学第一次遇到“程序跑飞，全速运行却像死机”的场景，误以为是CPU本身坏了，实际是某个外设中断被使能了，但没有对应的Handler，程序一进中断就落入死循环。

这种写法的意义在于，把错误显式化。中断向量指向一个明显的死循环，总比跳到一个随机地址强得多。你一旦调试器停下来，看到PC停在B .这一行，再结合当前中断标志，马上能定位到缺哪个中断函数。如果厂商把这些Handler都留空，反而难查。

同时注意：如果你愿意，可以用C函数覆盖这些弱符号，比如在C文件里写void HardFault_Handler(void){...}，链接器会优先选你的强符号。这也是常见的故障排查手法，用HardFault_Handler打印出错位置，而不是让程序干等。

3. SystemInit：启动流程里唯一一个C函数决定了你的主频

3.1 SystemInit存在的理由与“先跳转再初始化”的差异

Reset_Handler调用了SystemInit，这个函数在配套的system_stm32f10x.c里实现。它的存在，使得芯片可以从一个确定的低速时钟，自动切换到外部高速晶振加PLL的高频模式。这一过程必须在任何用户业务逻辑运行之前完成，否则后续所有延时、波特率、定时器溢出时间全部是错的。

很多人会问：为什么不直接在main开头调用时钟初始化呢？理论上也可以，但官方把这段逻辑放到SystemInit里，进入main之前就生效，这样带来的好处是：启动阶段如果发生HardFault，调试器看到的栈信息是干净的；外设库里的延时函数从第一条语句开始就能使用最终时钟频率，不会出现“前面按8MHz后来按72MHz”的割裂。

3.2 FLASH等待周期的寄存器配置细节

在SystemInit内部，配时钟前会先设置Flash等待周期。来看标准库中的核心片段：

FLASH->ACR = FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY_2;

这句代码设置了两个关键位：PRFTBE开启Flash预取缓冲，LATENCY_2设置两个等待周期。为什么需要等待周期？因为Flash存储器的读速度跟不上高主频的CPU，CPU取指令必须插入等待。F103在72MHz下需要2个等待周期，如果这里配成0个等待周期，程序会在运行到某些Flash读取请求时拿到错误数据，症状表现为随机HardFault、奇奇怪怪的跑飞，非常难查。这是SystemInit里最容易被忽略，却又是最致命的寄存器配置。

3.3 HSI过渡到HSE再到PLL的时钟链路

再往下看，SystemInit最终会调用SetSysClock()，完整走一遍时钟链路：

RCC->CR |= (uint32_t)0x00000001; // 开启HSI RCC->CFGR = 0x00000000; // 恢复默认时钟配置 RCC->CR &= (uint32_t)0xFEF6FFFF; // 关闭HSE、CSS、PLL RCC->CIR = 0x009F0000; // 关闭所有时钟中断 SetSysClock();

启动瞬间，外部晶振还没稳定，芯片先用内部HSI RC振荡器工作，频率约8MHz，精度一般且温漂明显。SetSysClock接着做这几件事：

1. 打开外部高速晶振HSE，等待稳定。
2. 配置Flash等待周期。
3. 把PLL输入源切到HSE，设置PLL倍频系数。
4. 打开PLL，等待锁定。
5. 把系统时钟切换到PLL输出，等待切换确认。

以72MHz主频为例，倍频系数是9倍，8MHz外部晶振经过9倍频得到72MHz。全程用寄存器位操作，不能依赖任何全局变量，因为此时全局变量区还没准备好。这一点很重要，也是后面章节的关键。

3.4 时钟配置失败的典型现象对照

排查时钟问题最有效的方式，是用调试器在SystemInit里外各设断点，对比RCC->CFGR的SWS状态位。执行完SetSysClock后，如果SWS不是PLL作为系统时钟，就说明切换链路某一步没成功。

4. __main与C运行时：全局变量在这一步才真正可用

4.1 __main是C库入口而不是main函数

从汇编跳到__main后，启动流程进入C运行库的领地。__main不是我们写的那个main()，而是编译器和C库自动生成的一段引导代码。它的核心工作有两件：把RW段从Flash复制到RAM，把ZI段清零。在MDK环境中，__main最终会调用__rt_entry，再由__rt_entry调用用户写的main()。

这里有个很多新手踩过的坑：__main这个名字在汇编里看起来像“主函数”，于是有人直接把它理解成main入口。实际上它是一个“整合器”，在调用你的main之前，它已经把C环境铺好了。如果你在某个全局变量初始化函数里打印日志，会发现日志执行顺序比main早，但此时变量区刚刚就绪，还算安全。

4.2 .data搬运与.bss清零的真实时机

C语言里写了初始值的全局变量，比如int g_count = 100;，这个初始值在编译后会放在Flash的只读区域，叫加载域。程序运行时，这个变量必须在RAM里才能被CPU读写，所以__main负责在启动阶段把这一块数据从Flash复制到RAM，这被称为执行域装载。而没写初始值的全局变量（或显式置0）属于ZI段，直接清零即可。

关键在于：这个搬运和清零动作，发生在SystemInit之后，发生在进入main之前。也就是说，Reset_Handler调用SystemInit时，全局变量区的内容是完全不可预期的“脏数据”。如果在SystemInit里使用了带初始值的全局变量，你读到的不是初始值，而是RAM里的残留数据；如果在SystemInit里写了全局变量，后面__main做数据拷贝时，Flash里的初值会把你写入的值覆盖掉。

这是官方库SystemInit没有使用任何全局变量的深层次原因。我见过有人在工程里擅自改SystemInit，往里面放了个调试计数变量，结果上电后计数器的值总是被清掉，查了一天才发现是数据段搬运的时序问题。理解这个顺序，真的能省很多查错时间。

4.3 微库与非微库在启动阶段的区别

在MDK工程里，你可以勾选“Use MicroLib”选项，这会显著改变__main及运行时库行为。微库为嵌入式精简了大量C标准库功能，启动代码更短，RAM占用更少，还不要求实现__user_initial_stackheap这类底层回调。但代价是部分标准函数行为简化，比如printf可能不完全支持浮点格式化，malloc这类动态内存功能也很受限制。

如果你不勾选微库，启动文件末尾通常会多出一段：

IMPORT __use_two_region_memory EXPORT __user_initial_stackheap __user_initial_stackheap LDR R0, = Heap_Mem LDR R1, =(Stack_Mem + Stack_Size) LDR R2, = (Heap_Mem + Heap_Size) LDR R3, = Stack_Mem BX LR

这段代码告诉运行时库，堆和栈是两个独立区域，各自边界在哪。如果不勾选微库又没提供这段回调，C库初始化堆栈时可能会用错误的地址模型，程序同样跑不起来。所以，如果你想要完整的C标准库行为，请保留启动文件里这段回调；如果你只想跑个轻量应用，勾选微库也没问题，但心里要清楚两者在启动阶段的差异。

5. 实战验证与调试器观察启动流程

5.1 在Reset_Handler打断点看PC/SP的变化过程

纸上谈兵不如实际操作。把程序下载到开发板后，在MDK反汇编窗口里找到Reset_Handler，在这条函数入口打一个断点：先复位CPU，此时观察寄存器窗口，SP已经被设置为向量表第一个元素对应的值，PC停在Reset_Handler入口。继续单步，走到BLX R0之后，PC会进入SystemInit内部，此时你可以对比时钟寄存器，能看到系统时钟还在8MHz。单步走完SetSysClock，再检查SWS位，应切换到PLL输出。

这套操作下来，你对整个启动流程的顺序感会非常强。我在带新人时，都会让他们先做这个实验，再去看文章和手册，效果比单纯读代码好太多。调试器不是只能看代码，它也是理解硬件启动行为的工具。

5.2 BOOT设置与两种常见的启动失败场景

BOOT引脚相关的启动失败，是嵌入式现场最高频问题之一。场景一：产品量产时，板子上BOOT0被意外拉高，程序明明烧进去了，上电却跑出厂Bootloader，USB或串口枚举出来的设备完全不是预期的东西。场景二：调试时候为了方便，有人把BOOT1也拨到高端，从SRAM启动，结果代码烧到Flash后发现复位后不执行，因为向量表根本不在SRAM里，除非调试器额外加载SRAM镜像。

所以遇到“烧录成功但跑不起来”的问题，先量BOOT0，不要急着怀疑固件坏掉了。这是我一直强调的排查顺序：硬件状态确认绝对优先于代码逻辑排查。

5.3 从bootloader跳转APP时的向量表偏移处理

做IAP时，启动流程会多一层复杂度。APP通常从0x08008000之后开始，它的向量表不在0地址。从Flash启动时，硬件只认映射到0地址的区域，如果你不会重定位向量表，APP一进中断就会取到bootloader里对应位置的错误向量，直接HardFault。

解决办法是设置SCB->VTOR。F1系列上常通过宏VECT_TAB_OFFSET配置：

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;

偏移量必须是向量表对齐值。跳转前的操作顺序也有讲究：先关闭所有中断，确保没有挂起的异常；再把APP向量表第一个字读出作为MSP初始值，第二个字读出作为复位入口；最后用__set_MSP()切栈指针，跳转过去。

我自己做bootloader时，通常直接在跳转函数里先调用NVIC_SystemReset()做一次整体复位，再从复位后的Reset_Handler自然进入APP，这样可以彻底清掉外设状态，比手动关外设更干净。当然，这种方式需要bootloader在复位后能判断是否进入APP，设计上会多一个标志位。各有利弊，但一定要避免“直接在main函数中间用函数指针跳转”，那样外设寄存器状态全是脏的，AB面都差。

5.4 实际项目踩过的三个启动相关坑

第一个坑：低估栈需求量。启动文件默认栈只有1KB，如果你用了带浮点格式化的printf、深度递归或RTOS的多任务栈，1KB随时溢出，症状是程序跑一段时间后随机HardFault。遇到这类“诡异死机”，先检查栈是否溢出。做法很简单，在调试器内存窗口里观察栈顶附近是否有被踩过的历史数据，或者干脆在怀疑的时间点检查MSP是否落在栈边界内。

第二个坑：中断Handler缺失。某外设中断被使能后，C代码里却忘了写对应的Handler，程序一进中断就落到弱定义的死循环。调试器暂停后，PC停在B .上，看起来像死机，实际上是中断缺失。习惯做法是：每次使能一个新中断，同时把对应的Handler函数骨架也写上，哪怕里面空着也行，也算有一个明确的存档。

第三个坑：在SystemInit阶段用全局变量。前面剖析过，.data段还没搬运，.bss段也没清零。启动阶段用全局变量，其结果是不确定的。原则是：SystemInit及之前只操作寄存器，不碰任何全局变量。

结尾的小经验

回头再看整个上电启动流程，其实就是三件事：硬件从0地址取栈指针和复位向量，启动文件完成栈和堆布局、向量表登记，SystemInit配好系统时钟，再由C运行时完成数据初始化和入口跳转。整个过程顺序固定，任何一个环节被破坏，程序都可能在进入main之前就夭折。调试启动问题时，顺着这条链从SP、PC、时钟寄存器一路查，比盲目翻业务代码高效得多。最后再分享一个习惯：我每次新建工程，都会先在Reset_Handler、SystemInit、main三个位置各加一个断点，作为“启动健康检查”的标准动作。这三个点对应了硬件复位、时钟就绪、业务入口三个阶段，任何一个断点停不下来，说明启动链路在对应环节出了问题。这个习惯帮我省下了不少莫名其妙的定位时间，你也可以试试。