STM32启动流程详解：从复位向量到main的完整链路

很多人的 C 语言第一课，都是那句printf("hello world")。当年照着翁恺老师的视频把环境搭好，看见黑框里跳出那行字，就觉得 C 语言这关算是过了。等到后来真正上手 STM32，用 Keil 或者 CubeIDE 建一个工程，同样写了一个int main(void)，编译下载，灯亮了。于是心里冒出一个很自然的问题：同样是main，为什么在 PC 上它前面什么都没写就能跑，而在 STM32 上必须有一堆启动文件、链接脚本、时钟配置？从 C 语言的main到 STM32 的main，这中间到底发生了什么，你的代码后来去了哪里？

这篇文章就是把这中间的一段路拆开给你看。适合两类人：一类是刚学完 C 语言基础、准备碰 STM32 的同学，另一类是在这一行干了两三年，平时改启动文件靠抄、出问题靠猜的工程师。前者能建立起一整条从复位到main的完整图景，后者能把平时那些"能跑就行"的模糊地带补上——因为 IAP 升级、RTOS 移植、低功耗唤醒、HardFault 定位这些活儿，全都压在这段路上。

1. 两个 main 之间，隔着的不是一行代码

1.1 桌面环境里，是谁在调用你的 main

先看熟悉的场景。你在终端敲./hello，这个动作并不是"把代码交给 CPU 去跑"这么简单。内核里的execve系统调用先接管，把 ELF 文件映射进地址空间，然后跳到你程序里一个叫_start的符号上——注意，不是main。_start属于 C 运行时的启动代码，一般由crt1.o提供，你写gcc时它被自动链进来了。

_start干的事情不多，但每一件都关键：把内核压在栈上的argc、argv、envp取出来，对齐栈指针，然后调用__libc_start_main。这个函数才是真正的大管家——它负责初始化线程局部存储、初始化 libc 内部结构、注册atexit回调、跑一遍.init_array里的构造函数（C++ 全局对象的构造函数就在这里被执行），最后才调用你写的main。

所以严格来说，PC 上你的main是被 glibc 调用的。main返回之后也不会"程序结束"，而是回到__libc_start_main，它再调用exit，冲刷缓冲区、跑析构、通知父进程。你在main里写return 0，这个 0 就是通过这条路传给 shell 的。

想验证这一点很简单，编译完用readelf -h hello看一眼，Entry point address 指向的绝对不是main的地址。

1.2 STM32 上电之后，CPU 在头几个时钟周期干了什么

把场景换到 STM32。芯片上电、复位释放的那一瞬间，没有任何操作系统，没有文件系统，没有内存管理单元，连时钟都还跑在最保守的内部 RC 振荡器上。Cortex-M 内核此时只做两件固定动作，而且是硬件写死的：

从地址0x00000000取出一个 32 位数值，装进主栈指针 MSP；从地址0x00000004再取出一个 32 位数值，装进程序计数器 PC，然后开始执行。

就这么两条。你写在main里的第一行代码，距离这一刻还隔着几万条指令。这段距离由谁来填？答案是启动文件和链接脚本，而它们的产物，就是那两个从零地址取出来的数值。

很多人第一次意识到这件事，是在链接报错的时候——比如undefined reference to 'main'，或者某些工程里出现的"编译器未包含 main 类型"这类提示。它的意思不是"你代码写错了"，而是"运行时找不到入口了"。类似的现象在其他生态里也常见，Node.js 会因为package.json里缺少main字段报err_package_path_not_exported，Java 会因为 JVM 找不到public static void main抛NoSuchMethodError。main这个词在所有语言里都指向同一个含义：程序的入口约定。区别只在于，谁来完成入口之前的那些准备工作。

PC 上这个活儿由 glibc 和内核干，STM32 上，只能你自己（或者你的启动文件）干。这就是两个main之间最本质的差异。

2. 中断向量表：复位后 CPU 拿到的第一张地图

2.1 为什么第 0 个字是栈顶指针，而不是函数地址

Cortex-M 的向量表设计非常有意思。按常理，一张"跳转地址清单"的第 0 项应该放一个函数地址才对，但 Cortex-M 偏偏放的是栈顶指针。这不是随手写的，而是有明确用意的：C 语言跑起来必须要有栈，没有栈就没法保存局部变量、没法传递参数、没法从中断返回。所以在取第一条指令之前，必须先保证栈是合法的。

这就是为什么在启动文件里你会看到_estack这个符号，它通常定义为 SRAM 的最高地址。以 STM32F103C8T6 为例，SRAM 从0x20000000开始，共 20KB，那么_estack = 0x20005000。这个值被放到0x00000000，复位后 MSP 就等于它。ARM 的栈是满递减栈：栈顶指针指向最后一个入栈的数据，每次压栈先减地址再写入。所以 MSP 从一个高地址往下长，是符合预期的。

这里有一个很多人踩过的坑：如果 SRAM 只有 20KB，而你的全局数组加栈一起超过了它，溢出的方向不是"往上顶到 Flash"，而是"栈把 .bss 段踩烂"。表现出来就是某个毫不相关的全局变量莫名其妙变了值，或者跑几个小时才死机。这种问题查起来极其难受，所以栈大小和最大栈深度，是每个项目都该认真估一遍的数字。

2.2 启动文件里那张表长什么样

向量表在启动代码里长得像下面这样，我以 GCC 的.s语法举例，ARM Compiler 的写法略有差别但结构一致：

.section .isr_vector,"a",%progbits .type g_pfnVectors, %object g_pfnVectors: .word _estack .word Reset_Handler .word NMI_Handler .word HardFault_Handler .word MemManage_Handler .word BusFault_Handler .word UsageFault_Handler .word 0 .word 0 .word 0 .word 0 .word SVC_Handler .word DebugMon_Handler .word 0 .word PendSV_Handler .word SysTick_Handler /* 后面是各外设中断，EXTI0_IRQHandler、TIM2_IRQHandler ... */

第 0 项是_estack，第 1 项是Reset_Handler，第 3 项是HardFault_Handler——正好对应前面说的硬件动作。第 2 项是 NMI，第 3、4、5、6 项依次是硬错误、内存管理错误、总线错误、用法错误。负优先级异常（NMI、HardFault）排在前面是有道理的，它们优先级最高，永远不会被屏蔽。

.section .isr_vector,"a",%progbits这行的含义是：把这段数据放进一个名为.isr_vector的段，属性是 allocatable（需要占用运行时内存）、内容是普通数据。链接脚本里再用KEEP(*(.isr_vector))把它牢牢钉在 Flash 的最开头，地址正好是0x08000000。为什么必须用KEEP？因为一旦你开了--gc-sections，链接器会认为"没有任何代码引用这张表"，然后把它优化掉。表没了，复位后取出来的两个数就是垃圾，芯片直接跑飞。这个坑我在早期项目里踩过，现象是烧录后毫无反应，连复位都不进，排查了半天。

2.3 BOOT 引脚与那张表的物理位置

这里还有一个常常被忽略的细节：Cortex-M 取的数据来自0x00000000，可你的向量表在0x08000000，这中间对不上。答案是 STM32 内部做了一层地址别名映射。当 BOOT0 引脚为低电平时，0x00000000这一段被映射到主 Flash 的起始处，所以从零地址取到的内容，其实就是0x08000000处的内容。

当 BOOT0 拉高、BOOT1 拉低时，这段别名被映射到系统存储器，里面是厂家预置的一段 Bootloader，通常用来通过串口烧程序。这也是为什么有时候程序烧进去了却不跑——多半是 BOOT0 忘了拉回低电平。

理解这层映射的意义在于：向量表不一定非要放在 Flash 里。你也可以把它整体搬到 SRAM 的起始处，然后修改SCB->VTOR寄存器。IAP 升级的工程经常这么干：Bootloader 和 App 各自带一张完整向量表，App 起始地址偏移了一个扇区，跳转前把 VTOR 指过去，中断就能正确落到 App 的处理函数里。这一点在第 7 节会展开。

3. 链接脚本：谁决定你的变量住在哪

3.1 VMA 与 LMA，一个容易被忽略的区分

链接脚本里最有价值、也最容易被跳过的概念，是 VMA 和 LMA 的区别。VMA 是运行地址，LMA 是加载地址。听起来像术语游戏，但它是理解"全局变量初值从哪来"的关键。

想一下：int table[256] = {1,2,3,...}这样的初始化数据，初值是实实在在存在 Flash 里的。但程序运行的时候，这个数组必须待在 SRAM 里，因为它要能被改写。于是出现了一个矛盾：它需要占据两个空间位置——加载时在 Flash（初值随固件一起烧录进去），运行时在 SRAM。

链接脚本用AT>来表达这件事：

.data : { _sdata = .; *(.data) *(.data*) . = ALIGN(4); _edata = .; } >RAM AT> FLASH _sidata = LOADADDR(.data);

>RAM指定 VMA 在 RAM，AT> FLASH指定 LMA 在 Flash。LOADADDR(.data)算出的是.data段在 Flash 中的起始地址，赋给_sidata。运行时的搬运代码，就是拿着_sidata、_sdata、_edata这三个符号，从 Flash 往 RAM 里逐个字拷。

再说一下未初始化数据.bss。C 语言规定全局变量没写初值就等于 0，但编译器不会真的往 Flash 里塞一堆 0，那样太浪费空间。它把这类变量归到.bss段，只在运行时占 SRAM，Flash 里不留任何字节。代价就是必须有人在启动阶段把它全部清零，否则变量里就是上电时的随机值。

所以链接脚本里那三个符号组，本质上是在告诉启动代码："初值从_sidata搬，搬到_sdata到_edata；从_sbss到_ebss全部清成零。"这就是.data搬运和.bss清零的全部原理。

3.2 一份可以照着抄的链接脚本骨架

下面是 STM32F103C8T6 的常用版本，我把关键注释写在旁边：

ENTRY(Reset_Handler) _estack = 0x20005000; /* 20KB SRAM 顶 */ MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K } SECTIONS { .isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) . = ALIGN(4); } >FLASH .text : { . = ALIGN(4); *(.text) *(.text*) *(.rodata) *(.rodata*) . = ALIGN(4); _etext = .; } >FLASH .data : { . = ALIGN(4); _sdata = .; *(.data) *(.data*) . = ALIGN(4); _edata = .; } >RAM AT> FLASH _sidata = LOADADDR(.data); .bss : { . = ALIGN(4); _sbss = .; *(.bss) *(.bss*) *(COMMON) . = ALIGN(4); _ebss = .; } >RAM ._user_heap_stack : { . = ALIGN(8); PROVIDE(end = .); PROVIDE(_end = .); . = . + 0x400; /* 预留 1KB 堆 */ . = . + 0x400; /* 预留 1KB 栈检查区 */ . = ALIGN(8); } >RAM }

几个值得注意的地方。ENTRY(Reset_Handler)告诉链接器程序入口是Reset_Handler，它会写进 ELF 头里，但 Cortex-M 实际不用这个字段，硬件走的是向量表第 1 项，这个声明更多是给调试器和工具链看的。.isr_vector必须放在SECTIONS的第一项，因为它要占据 Flash 的最开头，顺序错了地址就全错。

*(COMMON)这行也别删。有些编译器会把未初始化的全局变量放进 COMMON 段而不是.bss，不收集进来它们就没有归属，链接阶段可能报错或者被放到奇怪的位置。

至于._user_heap_stack那一段，本质上是给栈"划了条红线"。如果链接器发现 RAM 已经装不下这些保留区，它会直接报 region overflow，等于在编译期就告诉你栈和堆要爆了。比运行时崩溃好得多。

3.3 用工具验证，而不是靠猜

链接脚本写完不要靠感觉，直接用工具查。编译后执行：

arm-none-eabi-size build/app.elf

输出会给出 text、data、bss 三段的大小和总占用。text 是 Flash 里的代码和常量，data 是既有初值又要占 RAM 的部分（它同时算进 Flash 和 RAM），bss 只算 RAM。如果你发现 Flash 占用比预期大很多，多半是某个大数组被初始化了。

再看段的实际布局：

arm-none-eabi-objdump -h build/app.elf

这里能看到每个段的 VMA 和 LMA 到底落在哪。重点确认两件事：.isr_vector的 VMA 是不是0x08000000；.data的 LMA 是不是落在 Flash 区间内、VMA 落在 SRAM 区间内。这两个对上了，搬运逻辑基本就不会出问题。

生成 map 文件也很有用，在链接参数里加-Wl,-Map=build/app.map，里面会列出每个符号的最终地址，配合arm-none-eabi-nm排序，可以快速看清谁最占地方。调试内存溢出的时候，这个文件比调试器还快。

4. 从 Reset_Handler 到 main 的完整链路

4.1 启动文件里的搬运和清零是怎么写的

真正的搬运代码，以 ST 早期 GCC 模板为例，长这样：

Reset_Handler: ldr sp, =_estack /* 有些版本省略，硬件已经设过了 */ movs r1, #0 b LoopCopyDataInit CopyDataInit: ldr r3, =_sidata ldr r3, [r3, r1] /* 从 Flash 取一个字 */ str r3, [r0, r1] /* 写到 RAM 对应位置 */ adds r1, r1, #4 LoopCopyDataInit: ldr r0, =_sdata ldr r3, =_edata adds r2, r0, r1 cmp r2, r3 bcc CopyDataInit ldr r2, =_sbss b LoopFillZerobss FillZerobss: movs r3, #0 str r3, [r2], #4 /* 写 0 并后自增 4 */ LoopFillZerobss: ldr r3, =_ebss cmp r2, r3 bcc FillZerobss bl SystemInit bl __libc_init_array bl main

这段汇编的逻辑很朴素：用一个偏移量 r1 从 0 开始，每次加 4，直到_sdata + r1 >= _edata为止；然后用后自增的方式把_sbss到_ebss之间的每一个字写成 0。最后三行才是重点——先bl SystemInit，再bl __libc_init_array，最后bl main。

顺序不能乱。SystemInit要先把时钟和向量表偏移搞定；__libc_init_array要跑完所有构造函数；main必须在这一切就绪之后才能进来。很多人问"为什么main里第一句就想用HAL_Delay，结果死等"，原因往往在于时钟还没配或者 SysTick 还没开，这时候的延时就是个空转。

顺便提一句 ARM Compiler 的差异。AC5/AC6 的启动文件里通常只写一句LDR R0, =__main然后BX R0，剩下的搬运、清零、库初始化全部由__main内部完成——它会调用__scatterload根据分散加载表把该搬的搬、该清的清，再进__rt_entry做库初始化，最后才调你写的main。所以在这条路线里你是找不到搬运循环的，它被藏进库里了。知道这一点，在两种工具链之间切换时才不会犯迷糊。

4.2 SystemInit 到底干了哪些事

SystemInit这个名字容易让人以为它把一切都配好了，其实它的职责在不同系列里有明显差异。

在 CubeMX 生成的工程里，它通常只做三件事：复位 RCC 的相关寄存器到已知状态、打开内部高速时钟（HSI）、设置向量表偏移寄存器SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;。真正的时钟树配置（PLL、分频、Flash 等待周期）被挪到了main.c的SystemClock_Config里，由用户在main开头主动调用。

而在标准外设库那套老模板里，SystemInit会顺手把 PLL 拉起来，F1 系列常见的做法是内部调用一个SetSysClock类的函数，直接把主频拉到 72MHz。

两者没有对错，只是工程组织方式的取舍。但对调试有影响：如果时钟配置在SystemInit里，而你的晶振没起振，程序会卡在一个while(RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET)的死循环里。这时候单步调试会看到 PC 指针停在system_stm32xxx.c里，main一次都没进过。遇到"程序不进 main"，第一件事就是看 PC 停在哪。

还有一点容易忽略：SystemClock_Config里如果忘了配 Flash 等待周期（LATENCY），主频拉高之后取指就会出错。F1 在 48MHz 以上需要 1 个等待周期，F4 在 168MHz 时需要 5 个。这个参数不是"性能调优"，是硬性时序要求，配错了表现是随机跑飞或者取指错误，非常难查。

4.3 __libc_init_array 与那些"没写却被执行"的代码

__libc_init_array的源码很短，但解释了 C++ 一个神奇的现象：

void __libc_init_array (void) { size_t count; size_t i; count = &__preinit_array_end - &__preinit_array_start; for (i = 0; i < count; i++) __preinit_array_start[i] (); _init (); count = &__init_array_end - &__init_array_start; for (i = 0; i < count; i++) __init_array_start[i] (); }

它遍历.preinit_array和.init_array两个段里的函数指针，逐个调用。C++ 的全局对象构造函数、标了__attribute__((constructor))的 C 函数，全部通过这种方式被执行。你写了一句static Logger log("app");，构造函数被自动调用的秘密就在这里。

如果你在裸机上写 C++，但不小心用了-nostartfiles又没自己调__libc_init_array，现象就是构造函数从来不执行，全局对象里的成员全是默认值。这个坑比想象中常见。

4.4 HAL_Init 之后，栈和时钟变成什么样

对 CubeMX 工程来说，main里的第一句通常是HAL_Init()。它内部做了四件事：使能 Flash 预取、设置 NVIC 优先级分组、调用HAL_InitTick配置 SysTick、调用HAL_MspInit做底层初始化。

HAL_InitTick默认把 SysTick 做成 1ms 一次的中断，中断优先级设成最低（TICK_INT_PRIORITY，通常是 0）。为什么故意设成最低？因为 HAL 的延时只是"估时"，不该抢占任何业务中断。如果你的业务 ISR 跑得比 1ms 还久，HAL_Delay(1)的实际时间就会变长，这不是 bug 是设计使然。需要精确延时的场合，别用HAL_Delay，用硬件定时器或者 DWT 计数器。

栈的情况也值得说：main运行期间用的还是 MSP，也就是复位时设的那个栈。一旦你用了 FreeRTOS 这类系统，任务会切到各自的 PSP，MSP 就只服务于中断上下文了。所以任务栈溢出和主栈溢出是两码事，排查时得分开看。

5. 手写一个最小启动流程：把黑盒拆开看

5.1 最小工程需要哪几个文件

想彻底搞明白这段路，最好的办法是扔掉 IDE，自己攒一个最小工程。需要的东西其实只有四个文件：

• startup_min.s：向量表加Reset_Handler，自己写搬运和清零
• link.ld：链接脚本
• main.c：业务代码，直接用寄存器点灯
• Makefile或者一个编译脚本

先写main.c，不依赖任何库，直接操作寄存器：

#include <stdint.h> #define RCC_APB2ENR (*(volatile uint32_t *)0x40021018) #define GPIOC_CRH (*(volatile uint32_t *)0x40011004) #define GPIOC_ODR (*(volatile uint32_t *)0x4001100C) static void delay(volatile uint32_t n) { while (n--) { __asm volatile ("nop"); } } int main(void) { RCC_APB2ENR |= (1U << 4); /* 使能 GPIOC 时钟 */ GPIOC_CRH &= ~(0xFU << 20); /* 清 PC13 配置位 */ GPIOC_CRH |= (0x2U << 20); /* PC13 推挽输出, 2MHz */ while (1) { GPIOC_ODR ^= (1U << 13); delay(200000); } }

关于 PC13 的配置位，值得解释一下。CRH是高 8 位引脚的配置寄存器，每个引脚占 4 个 bit，PC13 对应 bit20 到 bit23。低两位是 MODE（00 输入、01 输出 10MHz、10 输出 2MHz、11 输出 50MHz），高两位是 CNF（00 通用推挽、01 通用开漏、10 复用推挽、11 复用开漏）。所以0x2表示输出 2MHz 加通用推挽。为什么选 2MHz 而不是 50MHz？因为 LED 翻转用不着高速，输出速度越低，边沿越缓，EMI 反而更小。这个小细节在做数字电源、逆变器这类对噪声敏感的板子时是要考虑的。

5.2 手动搬运的启动汇编

启动汇编里就不调用任何库函数了，全部手写：

.syntax unified .cpu cortex-m3 .thumb .global g_pfnVectors .global Reset_Handler .section .isr_vector,"a",%progbits g_pfnVectors: .word _estack .word Reset_Handler .word Default_Handler .word Default_Handler .word Default_Handler .word Default_Handler .word Default_Handler .word 0 .word 0 .word 0 .word 0 .word Default_Handler .word Default_Handler .word 0 .word Default_Handler .word Default_Handler .section .text.Reset_Handler .type Reset_Handler, %function Reset_Handler: ldr r0, =_sdata ldr r1, =_edata ldr r2, =_sidata CopyLoop: cmp r0, r1 bcs ZeroBss ldr r3, [r2], #4 str r3, [r0], #4 b CopyLoop ZeroBss: ldr r0, =_sbss ldr r1, =_ebss movs r3, #0 ZbssLoop: cmp r0, r1 bcs CallMain str r3, [r0], #4 b ZbssLoop CallMain: bl main b . Default_Handler: b .

自己写一遍就会发现，所谓的"启动魔法"就是两个while循环加一次跳转。搬运循环用的是bcs（无符号大于等于时跳转），因为地址比较必须按无符号处理，用有符号比较会在大地址上出错。这个细节我之前在一个项目里被人抄错了，导致高地址段的.data搬不过去，查了很久。

CallMain最后那句b .是必须的。如果main不小心返回了（比如写成了return 0;），程序会掉到后面未知的内存里跑飞。加一句死循环就等于上了一道保险。

5.3 编译、链接、烧录

用 Makefile 把这条链串起来：

CROSS = arm-none-eabi- CC = $(CROSS)gcc OBJCOPY = $(CROSS)objcopy SIZE = $(CROSS)size CFLAGS = -mcpu=cortex-m3 -mthumb -O2 -ffunction-sections \ -fdata-sections -Wall -std=c99 -g3 LDFLAGS = -T link.ld -nostartfiles -Wl,--gc-sections \ -Wl,-Map=build/app.map all: build/app.bin build/app.elf: startup_min.s main.c @mkdir -p build $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ $(SIZE) $@ build/app.bin: build/app.elf $(OBJCOPY) -O binary $< $@

几个参数值得说清楚。-nostartfiles表示不要工具链自带的启动文件，我们自己提供了。-ffunction-sections -fdata-sections让每个函数、每个变量各自成段，配合-Wl,--gc-sections，链接器就能把没被引用的代码和数据全部删掉。这对 Flash 只有 64KB 的芯片来说能省下可观的体积。代价就是你得给所有需要保留的东西加KEEP或者__attribute__((used))，向量表就是典型例子。

-g3保留最多的调试信息，包括宏定义，调试的时候能省不少事。-O2是常用的平衡点，但注意：优化等级改变会显著改变局部变量的存放位置，有些变量被优化进寄存器，调试器里看不到值，看上去像"变量没赋值"。遇到这种情况先降到-O0确认逻辑，再回-O2，不要盲目怀疑编译器。

烧录完，LED 开始闪。到这一步，从复位到main的整条路就完全在你手里了，没有任何一层是黑盒。

6. 常见问题与排查实录

6.1 程序根本进不了 main

这是新手遇到频率最高的一类问题。现象是下载成功，板子毫无反应，打断点停在main上永远命中不了。按下面的顺序查，基本都能定位。

第一步看 PC 停在哪。用调试器 halt 一下，如果 PC 停在system_stm32xxx.c里某个while循环，说明卡在时钟等待上，八成是外部晶振的问题：晶振没焊、焊反了、负载电容不匹配、或者板子上压根没装晶振而你却配了 HSE。最快的验证方法是把时钟源改成 HSI 试一次，能跑起来就说明是 HSE 的锅。

第二步看复位向量。arm-none-eabi-objdump -s -j .isr_vector build/app.elf打出向量表内容，看第 0 个字是不是_estack的值，第 1 个字是不是Reset_Handler的地址。如果第 1 个字是 0，说明KEEP没生效或者段名写错了，链接器把向量表挪走或者删掉了。

第三步看 BOOT 引脚。设计上如果有 BOOT 跳线，检查是不是停在系统存储器那一档。这个错误很蠢，但每年都会有人踩。

第四步看启动文件型号是否匹配。F1 和 F4 的向量表长度、中断名称都不一样，用错了虽然能编译过，但中断会全部错位，表现出来是"能进 main，但一开中断就死"。

6.2 全局变量初值不对，或者被莫名其妙清零

这类问题的根因几乎都在.data搬运和.bss清零上，分三种情况。

第一种是搬运代码缺失。现象是带初值的全局变量全是 0。用-nostartfiles自己写启动文件但忘了搬运循环，或者 ARM Compiler 下用了__main却把它改名了，都会这样。

第二种是链接脚本少了AT> FLASH。这时候.data的 LMA 被当成 VMA，链接器认为初值本来就在 RAM 里，于是 Flash 里那份数据没有随固件烧进去，运行时读到的就是 SRAM 上电的随机值。用objdump -h看.data的 LMA，如果落在 SRAM 范围内就是这个问题。

第三种是变量被优化掉了。一个全局变量只在一个函数里读写，编译器可能把它优化进寄存器，调试器里看到的地址和实际不一样。这时候加volatile就行。但要注意volatile不是万能的：它只保证每次都从内存读，不保证原子性。多字节变量的并发读写，该关中断还是要关。

还有一种隐蔽的情况：栈溢出踩到了.bss。判断方法是往栈的起始区域填一个特征值（比如0xDEADBEEF），跑一段时间后检查这个特征值有没有被覆盖。这是估算最大栈深度的土办法，但非常好用。

6.3 HardFault 定位的三板斧

HardFault 是 Cortex-M 上最常见的死法，也是最需要方法论的。

第一板斧：读状态寄存器。SCB->CFSR会告诉你错误类型。bit1 是 DACCVIOL（数据访问违例），通常指向野指针；bit16 是 UNDEFINSTR（未定义指令），通常是跳到了非代码区或者 Thumb 位没置上；bit25 是 DIVBYZERO，除零。SCB->HFSR的 bit30 是 FORCED，说明是其他错误上抛过来的。SCB->BFAR会给出出错的地址，配合 map 文件一查就知道是哪个变量。

第二板斧：取中断栈帧。异常发生时硬件会自动压栈 8 个寄存器：R0、R1、R2、R3、R12、LR、PC、xPSR。在HardFault_Handler里判断 LR 的 bit2，为 0 说明用的是 MSP，为 1 说明用的是 PSP（也就是任务上下文）。找到对应的栈指针，偏移 24 字节就是出错的 PC。这个 PC 值就是罪魁祸首的指令地址，用arm-none-eabi-addr2line -e app.elf 0x08001abc就能直接定位到源码行号。

第三板斧：检查那个经典的 Thumb 位问题。Cortex-M 只能执行 Thumb 指令，函数指针的最低位必须是 1。如果你从向量表或者手写的跳转表里取函数地址时忘了保留最低位，调用时会立刻 HardFault，而且报的是 UNDEFINSTR，看起来毫无头绪。用函数指针数组做状态机的时候特别容易踩。

6.4 一份可以贴在工位上的速查表

其中"printf卡死"这一条值得单独说。ARM 工具链默认可能启用了半主机（semihosting），也就是通过调试器把 I/O 请求转给主机。裸机上没有调试器接管的场合，一条BKPT指令会让程序直接停住。GCC 侧加-specs=nosys.specs提供空的桩函数，ARMCC 侧用 MicroLIB 或者加#pragma import(__use_no_semihosting)，都能避开这个坑。我自己更推荐的做法是直接重写_write，把printf输出重定向到串口，这样既是可用的日志，也没有半主机风险。

7. 把这段路走通之后，能多做什么

7.1 IAP 升级本质上是一次栈和向量表的搬运

理解了启动流程，IAP 升级就不再神秘。App 被烧到了0x08008000这样的偏移地址上，它自带一张完整的向量表。Bootloader 要做的事情就三步：

typedef void (*app_entry_t)(void); void jump_to_app(uint32_t app_addr) { uint32_t sp = *(volatile uint32_t *)app_addr; uint32_t pc = *(volatile uint32_t *)(app_addr + 4); __disable_irq(); /* 关全局中断 */ HAL_RCC_DeInit(); /* 复位时钟，关闭外设 */ SysTick->CTRL = 0; /* 关掉 SysTick */ for (int i = 0; i < 8; i++) { /* 清所有 NVIC 使能与挂起位 */ NVIC->ICER[i] = 0xFFFFFFFF; NVIC->ICPR[i] = 0xFFFFFFFF; } __set_MSP(sp); /* 手工设置主栈指针 */ SCB->VTOR = app_addr; /* 向量表重定位 */ __enable_irq(); ((app_entry_t)pc)(); }

这几步为什么一个都不能少？__set_MSP是因为 App 的栈顶可能和 Bootloader 不同，栈还留在 Bootloader 的区域里会让 App 一开中断就踩到自己的数据。SCB->VTOR = app_addr是因为中断入口必须跟着向量表走，不改的话中断还是会跳回 Bootloader 的旧表。清 NVIC 是因为 Bootloader 里可能开过某些外设中断，跳过去之后这些中断对应的处理函数在 App 里可能是完全不同的东西，一个挂起的中断标志就能让 App 在第一条指令前就崩掉。

还有个坑：跳转前一定要关掉看门狗，或者让 App 立刻接手喂狗。否则 Bootloader 里开的那只狗，在 App 还没来得及初始化它的时候就先咬一口。

7.2 RTOS 启动，其实也是在 main 里换了张桌子

裸机程序只有一个栈，就是 MSP。上了 FreeRTOS 之后，每个任务有自己的栈，靠 PSP 切换。xTaskCreate的时候，系统会从堆里分一块空间，人为构造一个假的上下文栈帧，把任务的入口函数地址、参数、寄存器初值都摆好。调度器一启动，第一次上下文切换就把 PSP 指过去，然后"返回"到任务入口。

看明白这一点，就能理解为什么vTaskStartScheduler()正常情况下永远不会返回——它不是"启动"完就继续往下走，而是把自己变成了第一个任务或者进入了空闲任务。如果它返回了，多半是内存不够创建空闲任务，这时候要注意堆配置configTOTAL_HEAP_SIZE是不是太小。

同样也能理解为什么中断里不能用会阻塞的 API，为什么 ISR 里要有xxxFromISR版本，为什么主栈（MSP）在 RTOS 里其实只服务于中断上下文。这些规则不是凭空规定的，全部源自"栈切换"这个机制。

7.3 低功耗唤醒的两条不同路径

低功耗这一块，启动流程的知识直接影响方案选择。Stop 模式唤醒后，CPU 从进入低功耗后的下一条指令继续执行，不经过复位，不重走启动代码，所有 SRAM 内容、外设寄存器状态全部保留。这就是为什么 Stop 模式的唤醒时间只有几微秒。

Standby 模式就不一样了，它基本等于一次软复位。唤醒之后会重新走一遍从0x00000000取栈顶、取复位向量的完整流程，SRAM 内容丢失，所有外设回到复位值。所谓"从 Standby 唤醒"和"按了一下复位键"在软件视角上几乎没区别。所以用 Standby 做低功耗方案，必须在唤醒后重新初始化一切，并且要在复位原因寄存器里区分"上电复位"和"Standby 唤醒"，否则会出现每次唤醒都重新走一遍上电流程的尴尬。

如果一个项目要做长时间待机加间歇采集，这两种模式的取舍往往决定了整体功耗预算。我个人的经验是，唤醒后要跑的工作超过几百微秒的，优先考虑 Stop；只有长时间不工作的场景才值得用 Standby 去换那几微安的静态电流。

7.4 我在实际项目里踩过的一些坑

最后分享几条不那么"教科书"的经验。

第一，启动阶段的时序在某些行业里是硬指标。做车载以太网节点或者数字电源这类应用时，很多主机厂或者系统方案会规定从上电到 CAN 或者以太网可以正常收发的时间上限。这段时间里，SystemInit的时钟等待、HAL 库的初始化、外设驱动的启动顺序都会算进去。我见过为了把启动时间压下来，把HAL_Init之后的初始化从逐个外设串行改成按依赖关系分组并行的做法，效果很明显。先把关键链路跑通再补其余部分，是常用思路。

第二，浮点输出的代价要提前算。一个printf("%f")在启用nano.specs的情况下也会拉进十几 KB 的代码。在 64KB Flash 的芯片上，这一个格式符就可能吃掉四分之一的容量。确认不需要浮点打印时，用-Wl,-u,_printf_float的反向操作，或者改打印定点数，都能省下可观空间。

第三，-Wall一定要开，而且不要长期忽略任何警告。启动阶段的很多问题，编译期其实就有提示了——比如函数指针类型不匹配、变量未初始化、段属性冲突。因为警告太多而关掉它，等于主动放弃了成本最低的一层防护。

第四，调试器和真实启动流程是有差异的。有些调试器在下载后会自动复位并 halt 在main，有些会保留中断状态，有些在 attach 模式下会跳过部分初始化。判断一个问题和启动流程有没有关系，最可靠的办法是拔掉调试器、断电、上电、看现象。我遇到过一次只在热复位时出现的启动失败，最后发现是某个外设状态在复位后没有完全清干净，冷启动才能重现。

第五，.map文件要养成定期看的习惯。芯片容量吃紧的时候，盯着 map 文件里排在前面的几个大户，往往能一眼看出是哪个库被整个链进来了。这类问题的修复成本通常只有几分钟，收益却是好几 KB 的 Flash。