STM32从复位到main启动流程详解：向量表、启动文件与IAP重定位

调试器连上去，点下复位，PC没有停在main，而是停在一个看起来完全陌生的地址上，反汇编窗口里全是ldr、str、b这种汇编指令——这是我刚接触 STM32 那会儿最常遇到的场面。当时我的做法是直接翻代码找main，然后在第一行打个断点，至于断点之前那几百毫秒里芯片到底干了什么，完全是黑箱。后来遇到程序跑飞、变量初值莫名其妙、烧录完不启动、加了段自定义数据就崩这类问题，才发现绕不开这块内容：STM32 从复位释放到进入main，中间有一条非常明确的执行链条，链条上任何一环出问题，现象都长得差不多，但原因天差地别。

这篇内容讲的就是这条链条。从内核复位后取哪两个地址、BOOT 引脚把哪块存储映射到零地址开始，一路拆到启动文件里的汇编、链接脚本里的符号、C 运行时初始化，再到 IAP 升级时怎么把向量表搬个地方。适合已经能跑通点灯、但被启动相关的问题卡住过的朋友，也适合想搞清楚"为什么.data要搬、.bss要清"这类底层细节的人。我不打算只给你结论，每一步都会说清楚为什么这么做、不这么做会出什么现象。

1. 复位那一刻，内核到底去了哪里

1.1 从零地址取出的两个字

Cortex-M 内核的复位行为非常"死板"，也非常好记：复位信号释放后，它去地址0x00000000读第一个 32 位字塞进MSP（主栈指针），再去0x00000004读第二个 32 位字塞进PC（程序计数器），然后从这个 PC 开始取指。整个过程不经过任何软件，也不需要你写一行代码。

这两个字的含义是固定的：第一个是栈顶地址，第二个是复位向量，也就是复位后第一条指令的地址。它们的值从哪来？来自编译器放在 Flash 最前面的那张中断向量表。表的第一项是栈顶，第二项是复位入口，往后依次是 NMI、HardFault、各种外设中断的入口地址。

这里有个关键点，很多人第一次看到会困惑：向量表在 Flash 里，Flash 的起始地址明明是0x08000000，凭什么内核去0x00000000能读到？答案是地址别名映射。芯片内部做了地址重映射，把启动区域的起始地址映射到0x00000000，所以你从0x00000000读和从0x08000000读，拿到的是同一份数据。这个设计的好处是内核不用关心具体芯片把代码放在哪，只要保证零地址处有合法的向量表就行。

我在调试器里验证这一点的方法很土但很有效：复位后立刻暂停，看MSP寄存器的值，再去看0x08000000处的内存，两个数应该完全一致。如果不一致，说明芯片根本没从你期望的地方启动，八成是 BOOT 配置或者烧录地址的问题，这时候再往下查启动文件就是浪费时间。

顺带说一句栈顶的值是怎么算出来的。它通常等于RAM 起始地址 + RAM 大小，比如 64K RAM 从0x20000000开始，栈顶就是0x20010000。栈是向下生长的，所以栈顶取最高地址，第一次压栈会写到0x2000FFFC。这个细节很重要，后面算栈溢出边界的时候要用。

1.2 BOOT 引脚决定的三种入口

芯片上电时到底把哪块存储映射到零地址，取决于 BOOT 引脚的组合。以常见的中小容量系列为例：

正常量产板子都是 BOOT0 拉低、从主 Flash 启动，这也是唯一一种"上电就跑你的代码"的模式。第二种模式进的是出厂预置的那段引导程序，通常用来配合串口之类的接口做下载，你写的程序在这时候根本不执行。第三种从 SRAM 启动，一般只用于调试或者极小规模的验证，因为 SRAM 掉电就没了，每次上电都得重新灌代码。

我见过最典型的一个坑：板子上的 BOOT0 通过一个电阻下拉，但那个电阻焊成了 10K，而旁边的调试接口又引出了一根线，上电瞬间被外部设备拉高，结果芯片进了系统存储器模式。现象就是"烧录成功但程序不跑"，而烧录器往往能正常识别芯片，因为烧录走的是调试接口，跟启动模式无关。所以遇到"烧录没问题却不启动"，第一件事是拿万用表量 BOOT0 在上电瞬间的电平，别急着怀疑代码。

还有一点容易被忽略：BOOT 引脚只在复位释放的那一瞬间被采样，之后就自由了。所以完全可以在程序跑起来之后把 BOOT0 引脚复用成普通 IO。但如果设计上 BOOT0 接了按键或者外部器件，就要保证复位期间的电平是确定的，加上下拉或上拉电阻，别让它悬空。

对于较新的系列，BOOT1 不再单独引出引脚，而是做进了选项字节里，通过编程工具配置。这时候就没有"接线接错"的问题了，但要小心选项字节被误改——有些批量工具会把整片选项字节重写一遍，把启动配置一起改掉。

2. 启动文件不是黑盒：逐行拆开 startup_stm32xxxx.s

2.1 栈和堆的预留，以及 _estack 的作用

启动文件最前面通常是这么几行：

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

这段的意思是：在STACK段里预留 0x400 字节（1KB），__initial_sp这个符号标注在预留空间的末尾，也就是栈顶。因为它紧跟在SPACE之后、地址更高的一侧，所以天然就是"栈生长方向的反方向"，正好符合 Cortex-M 向下生长的约定。

堆的写法和栈类似，Heap_Size加上__heap_base/__heap_limit两个符号。这里我要说一句可能有点反直觉的话：大多数裸机项目根本用不到堆。只要你不调用malloc，不new对象，堆就是一个纯粹占着 RAM 不干活的摆设。很多工程模板默认给 0x200 字节，看着不多，但在 RAM 只有 20K 的型号上也是笔可观的浪费。我的习惯是：确认代码里没有动态分配，直接把Heap_Size改成 0，省下来的 RAM 给栈或者大数据缓冲区。

栈的大小则完全相反，宁可给大也不能给小。1KB 是很多模板的默认值，看起来够用，但只要你在中断里调了稍微深一点的函数、或者用了printf这种内部栈开销很大的库函数，就很容易踩穿。踩穿的后果不是报错，而是悄悄覆盖掉相邻的.bss变量，然后你在完全无关的地方看到一个被改坏的全局变量，排查起来极其痛苦。

我自己的经验值：只有主循环和几个浅层中断的小项目，0x400 够；带printf、带浮点运算、带递归或者深层函数调用链的，直接上 0x800 甚至 0x1000。RAM 实在紧张的话，先看看有没有大的全局数组能挪到别处，别从栈上抠。

2.2 向量表、弱符号与 Default_Handler 的用意

向量表这一段在汇编文件里长这样：

AREA RESET, DATA, READONLY EXPORT __Vectors EXPORT __Vectors_End EXPORT __Vectors_Size __Vectors DCD __initial_sp ; 栈顶 DCD Reset_Handler ; 复位 DCD NMI_Handler DCD HardFault_Handler DCD MemManage_Handler DCD BusFault_Handler DCD UsageFault_Handler DCD 0 DCD 0 DCD 0 DCD 0 DCD SVC_Handler DCD DebugMon_Handler DCD PendSV_Handler DCD SysTick_Handler ; ... 后面是各外设中断

前面四个 0 是保留位，这是内核规定的，不能省。每个中断入口都要占一个 32 位字，位置和中断号严格对应，错一个位置，中断就会跳到错误的函数里去。

重点在弱符号机制。启动文件里给每个中断都写了一个WEAK属性的默认实现，通常是：

Default_Handler PROC EXPORT Default_Handler [WEAK] B . ENDP

B .是一条跳回自己的指令，也就是死循环。为什么这么设计？因为芯片里可能有几十个中断源，你的项目实际只用了三五个，剩下的如果没定义，链接就会报错。用弱符号先占个位，你在 C 文件里定义同名函数，链接器就会用你的强符号覆盖掉弱符号；你没定义，就用这个死循环顶着。这样既保证了链接能过，又不会因为某个意外触发的中断跳到野地址去。

但这个"善意"也会带来麻烦。我遇到过不止一次：某个外设的中断标志没清干净，中断反复触发，而对应的处理函数又没实现，程序就死在这个B .里。调试器暂停后 PC 指向Default_Handler，但你看调用栈是空的，因为这是异常入口，没有正常的返回地址链。这种情况只能靠看外设的中断标志寄存器来判断是谁干的。

一个实用技巧：在调试阶段把Default_Handler改成记录当前的中断号再死循环，或者干脆在里面的B .前面加个断点。这样一停下来就能通过IPSR寄存器（在 xPSR 的低 9 位）直接读出当前是几号异常，对照向量表就知道是谁触发的，比一个个关外设快得多。

3. Reset_Handler 里的三段活：搬数据、清内存、跳 main

3.1 .data 搬运与 .bss 清零，链接脚本符号的真实含义

复位入口的典型实现（GCC 模板）：

Reset_Handler: ldr r0, =_sdata ldr r1, =_edata ldr r2, =_sidata movs r3, #0 b LoopCopyDataInit CopyDataInit: ldr r4, [r2, r3] str r4, [r0, r3] adds r3, r3, #4 LoopCopyDataInit: adds r4, r0, r3 cmp r4, r1 bcc CopyDataInit ldr r2, =_sbss ldr r4, =_ebss movs r3, #0 b LoopFillZerobss FillZerobss: str r3, [r2], #4 LoopFillZerobss: cmp r2, r4 bcc FillZerobss bl SystemInit bl __libc_init_array bl main

这段汇编干的事，用 C 语言描述就是十几行：

/* 1. 把 .data 的初值从 Flash 搬到 RAM */ uint32_t *src = &_sidata; uint32_t *dst = &_sdata; while (dst < &_edata) { *dst++ = *src++; } /* 2. 把 .bss 全部清零 */ dst = &_sbss; while (dst < &_ebss) { *dst++ = 0; } /* 3. 初始化和跳转 */ SystemInit(); __libc_init_array(); main();

为什么要搬？因为带初值的全局变量和静态变量，初值必须掉电不丢，所以初值只能存在 Flash 里；但运行时变量又必须可读可写，而 Flash 不能随便写，所以必须复制到 RAM 里。这就形成了一个"影子"关系：.data段在 Flash 里有一份只读的初值副本，在 RAM 里有一份可读写的工作副本，启动时把前者拷到后者。

.bss是另一回事。它放的是"未初始化"或者"初始化为 0"的全局和静态变量。C 标准规定这类变量初值就是 0，编译器不用真的在 Flash 里存一堆 0，那样太浪费空间。它只记下"这块区域需要多大"，启动时统一清零就行。这也是为什么.bss不占 Flash 空间、只占 RAM。

链接脚本里那几个符号就是为这段汇编服务的：

MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 256K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 48K } _estack = ORIGIN(RAM) + LENGTH(RAM); SECTIONS { .isr_vector : { KEEP(*(.isr_vector)) } >FLASH .text : { *(.text*) *(.rodata*) _etext = .; } >FLASH _sidata = LOADADDR(.data); .data : { _sdata = .; *(.data*) _edata = .; } >RAM AT> FLASH .bss : { _sbss = .; *(.bss*) *(COMMON) _ebss = .; } >RAM }

几个符号的含义可以对照着看：

LOADADDR(.data)是链接脚本里一个特别有用的写法，它返回.data段的加载地址（也就是存在 Flash 里的位置），而不是运行地址。AT> FLASH的作用就是把两者的差值交给链接器处理，汇编里只要拿_sidata和_sdata两个符号就行，不用关心具体地址是多少。

这里有个实际会踩的坑：.bss的清零必须在.data搬运之后。因为有些链接脚本里.data和.bss在 RAM 里是相邻的，如果先清零再搬，搬运过程本身没问题；但如果有代码在搬运前就用到了全局变量，那就是读到了垃圾值。标准启动文件的顺序是对的，真正会出问题的是你自己往启动流程里插自定义代码的时候。

3.2 SystemInit 与构造函数的调用顺序

SystemInit这个名字是芯片厂商定的约定函数，链接脚本里不强制，但启动文件里会调用它。它主要干两件事：配置时钟（把系统时钟从内部高速时钟切到 PLL 输出）、把向量表偏移寄存器设置成正确的值（如果有需要）。

顺序上为什么是"搬数据 → 清 bss → SystemInit → 构造函数 → main"？因为：

• SystemInit里面可能用到全局变量，所以必须在.data和.bss准备好之后才能调。
• 构造函数（C++ 全局对象的构造、__attribute__((constructor))标记的函数）可能依赖时钟已经配好，比如里面要初始化串口打印日志，所以必须在SystemInit之后。
• main里面可能用到这些全局对象，所以构造函数必须在main之前。

__libc_init_array这个函数名看着唬人，其实逻辑很简单：它遍历.preinit_array和.init_array两个段，把里面存着的函数指针挨个调一遍。C++ 的全局对象构造、__attribute__((constructor))标注的函数，都会被编译器塞进.init_array。如果你的工程里没有 C++ 对象也没有 constructor 标注，这个段是空的，函数调用就是空转一遍，几乎没有开销。

但这里有个真实的坑：在构造函数里调用printf常常出问题。因为printf依赖的底层输出接口可能还没初始化（比如串口外设、或者_write重定向里用到的缓冲区），在main之前调它会得到乱码甚至卡死。我见过一个项目把日志初始化写在一个全局对象的构造函数里，结果上电就死，查了两天才发现是printf内部申请了锁，而锁的初始化在更后面。结论很简单：构造函数里只做最保险的赋值，别碰外设。

还有一个细节值得注意：启动文件里那句bl main之后，通常跟着的是：

bx lr

或者B .。也就是说main函数如果返回了，程序会回到一个未定义的状态。正常写代码main里都是死循环，不该返回；但如果因为某种原因main被意外返回（比如有人写了个测试用的main只跑一遍），行为就不可预期。所以不管什么情况，main里都留个死循环兜底。

4. 工具链差异：GCC 的 __libc_init_array 与 ARMCC 的 __main

4.1 两种启动路径的对比

同一颗芯片，GCC 和 ARMCC 编译出来的启动流程是不一样的，这一点在移植代码时经常让人困惑。GCC 的路径比较直白：

复位向量 → Reset_Handler（汇编） → 搬 .data / 清 .bss（汇编里手写） → SystemInit → __libc_init_array → main

ARMCC 则把前两步交给了 C 库：

复位向量 → Reset_Handler（汇编） → __main（C 库入口） → __scatterload（按分散加载文件初始化 RW/ZI 段） → __rt_entry（C 库运行时初始化） → main

__main不是你的main，它是 C 库提供的启动入口，前面有两个下划线。它内部会读分散加载文件（.sct），把需要搬的段搬过去、需要清零的清零，然后才进你的main。

这个差异导致了一个很实际的现象：在 ARMCC 下你不能在main之前随便动.data段里的变量，因为那会儿它可能还没被初始化。而在 GCC 下，如果你在Reset_Handler里插代码，位置放错了同样会出问题。移植的时候必须确认新工具链里数据段初始化的位置。

GCC 的分散加载信息写在.ld文件里，ARMCC 写在.sct文件里，两者不通用的。移植工程时这两个文件都得重写，不能指望直接拷过来。

4.2 移植时容易踩的几个点

第一个是符号名不一致。GCC 用_estack、_sidata、_sdata、_edata，ARMCC 那边是Image$$RW_IRAM1$$Base这类带$$的链接器生成符号，还有__initial_sp、__heap_base这些。启动文件不能混用，混用就是链接错误。

第二个是向量表段名。GCC 的启动文件里段名是.isr_vector，链接脚本里必须用KEEP(*(.isr_vector))把它放在最前面，并且不能被优化掉。KEEP这个修饰很重要，因为向量表只被硬件引用、不被代码引用，没有KEEP的话链接器做垃圾回收时可能把它整个删掉，结果就是上电直接跑飞。我见过一个工程为了减小体积开了段回收（--gc-sections），忘了给向量表加KEEP，编译完全正常，烧进去就是不启动。

第三个是中断函数名的大小写和拼写。向量表里写的是USART1_IRQHandler，你 C 文件里写成USART1_IRQhandler，编译器不会报错，链接器也不会报错，因为两者根本没关系——你定义了一个没人调用的普通函数，中断来了还是进Default_Handler死循环。这种问题用nm命令查符号表最快：arm-none-eabi-nm 固件.elf | grep -i usart，看看你的函数在不在，名字对不对。

第四个是优化等级对启动代码的影响。启动文件是汇编，不受优化影响；但如果你用 C 语言实现了某些段初始化钩子，-O2下编译器可能认为某些写入是死代码给优化掉。涉及内存映射和硬件寄存器的操作，一律加volatile，这条没有例外。

5. 启动阶段的故障排查：从 HardFault 到"进了 main 却不对"

5.1 卡在 main 之前的三类原因

第一类：时钟没起来。现象是程序跑得极慢，本该秒级完成的初始化拖了很久，或者串口出来的全是乱码。原因常见于外部晶振没起振（焊接不良、负载电容不匹配、晶振型号选错），而SystemInit里配置 PLL 的代码又在死等晶振就绪标志。有些模板的等待循环没有超时退出，晶振不起振就永远卡在那儿。

排查方法：从内部高速时钟启动时，程序是能跑的，这时候可以用 GPIO 翻转配合示波器看主频对不对。或者直接在SystemInit返回处打断点，看时钟配置寄存器的实际值。我在板子还没焊晶振的时候，习惯先用内部时钟跑通，确认代码逻辑没问题，再切外部时钟，这样能快速区分是硬件问题还是软件问题。

第二类：看门狗在启动期间咬人。有些系列的看门狗在复位后是默认开启的，或者由选项字节控制。如果你的SystemInit里有时钟切换的等待、有 Flash 等待周期的配置，耗时可能超过看门狗的超时时间，芯片就在main之前被复位了。现象是程序反复重启，调试器里能看到 PC 一直在复位向量附近。

处理方法：在启动流程的最前面（Reset_Handler一进去）就先喂一次狗或者直接关掉，等初始化完成再开。这个操作要放在搬数据之前，因为搬数据本身在 RAM 很大的时候也要花时间。

第三类：供电和复位电路问题。电源上升沿太慢、复位电容太大导致复位释放延迟、或者电源纹波过大，都会让芯片在启动阶段表现异常。这类问题的特点是"有时候正常有时候不正常"，换个板子或者换颗芯片现象就变。用示波器看复位引脚和电源引脚的上电波形是最直接的，重点看复位释放时电源是否已经稳定在额定值以上。

5.2 段初始化遗漏和栈溢出的识别方法

段初始化问题的典型现象是：全局变量的初值不对。比如你写了uint32_t g_flag = 0x12345678;，运行时读出来是 0 或者垃圾值。原因可能是链接脚本里.data段的加载地址配错了，也可能是启动文件的搬运循环边界写错了。

判断方法很直接：在main的第一行打断点，看这个变量在内存里的值。如果不对，再去看_sidata、_sdata、_edata这三个符号的实际地址——这些符号在.map文件里都有，编译器也会在链接时输出。对照着看：_sidata应该在 Flash 范围（0x0800xxxx），_sdata和_edata应该在 RAM 范围（0x2000xxxx），而且_edata - _sdata应该等于这个段的大小。三个地址有一个不对，就是链接脚本的问题。

栈溢出更隐蔽，因为它是写坏别人的内存，而不是自己立刻出错。识别方法有这么几个：

一是在栈底放魔术字。在链接脚本里给STACK段末尾预留几十个字节，初始化时填上0xDEADBEEF，运行一段时间后检查这片区域有没有被改写。被改写了说明栈用超了。这个方法简单粗暴但非常有效，我几乎每个项目都会在调试版本里加。

二是看 MSP 的实时值。调试器暂停时读MSP，如果它离_estack - Stack_Size很近（比如只差几十字节），说明栈已经快到底了。注意是向下生长，所以危险的是 MSP 值变小，不是变大。

三是用调试器的栈使用分析功能，有些 IDE 能统计历史最深栈指针，这个数据比单次暂停准得多。

还有一个容易被忽略的：中断里的栈开销。主循环里栈用得再浅，中断进来会额外压栈（至少 8 个字，用了浮点还会更多），中断里再调函数就更深。所以评估栈大小要按"最深路径"算，而不是按主循环算。我的做法是专门写一个测试函数，把所有中断都人为触发一遍，同时在里面调最深的业务函数，然后看栈用到哪儿，这个值再乘 1.5 就是安全余量。

6. 把启动流程改成自己的：IAP、向量表重定位与启动耗时优化

6.1 VTOR 重定位与跳转前的现场清理

做 IAP 升级的时候，程序被分成两段：一段是 Bootloader，跑在 Flash 起始位置；另一段是应用程序，跑在偏移之后的位置，比如0x08008000。芯片复位后总是从0x08000000开始执行，所以先进 Bootloader，Bootloader 判断需要跳转，再跳到应用程序。

问题在于中断。应用程序编译时，向量表的地址是按它自己的链接地址算的，但内核默认还是去0x00000000找向量表（也就是 Bootloader 的表）。不解决这个问题，应用程序里的中断全都会跳到 Bootloader 的处理函数里去。

解决办法是设置VTOR（向量表偏移寄存器）：

/* 在应用程序的 SystemInit 里，或者 main 的最前面 */ SCB->VTOR = 0x08008000UL; __DSB(); /* 确保写入完成 */ __ISB(); /* 清空流水线，让后续取指用新配置 */

__DSB和__ISB这两句不能省。VTOR 的修改要能立刻对后续的异常响应生效，中间隔了内存屏障才保险。我见过因为省了这两句导致"偶尔第一次中断跳错地方"的问题，加了就好了。

Bootloader 跳转到应用程序的代码，关键是把现场清干净：

typedef void (*app_entry_t)(void); int jump_to_app(uint32_t app_addr) { uint32_t sp = *(volatile uint32_t *)app_addr; uint32_t pc = *(volatile uint32_t *)(app_addr + 4); /* 栈顶必须落在 SRAM 范围内，否则向量表无效 */ if ((sp & 0x2FFE0000U) != 0x20000000U) { return -1; } /* 1. 关全局中断 */ __disable_irq(); /* 2. 关掉所有已经打开的外设中断，清挂起标志 */ for (int i = 0; i < 8; i++) { NVIC->ICER[i] = 0xFFFFFFFFU; NVIC->ICPR[i] = 0xFFFFFFFFU; } /* 3. 关 systick */ SysTick->CTRL = 0; SysTick->LOAD = 0; SysTick->VAL = 0; /* 4. 重设栈指针和向量表 */ __set_MSP(sp); SCB->VTOR = app_addr; __DSB(); __ISB(); /* 5. 跳过去 */ ((app_entry_t)pc)(); return 0; }

每一步都有理由。关中断是因为跳转过程中如果来了中断，处理函数还是老程序的，栈已经换了，必崩。关外设中断是因为有些外设中断标志在跳转后还挂着，新程序的向量表里对应位置可能是别的函数，一进去就乱套。关 SysTick 是因为新程序会重新配置它，老配置留着会立刻产生一次中断。

第 4 步的顺序也有讲究：先设 MSP 再设 VTOR。因为设 VTOR 之后如果立刻来异常，压栈用的是新 MSP；如果 MSP 还是旧的（指向 Bootloader 的栈），而新程序的栈在别处，现场就错了。虽然关了中断理论上不会来异常，但 NMI 和 HardFault 是关不掉的，所以顺序还是要对。

6.2 启动耗时测量与裁剪

有些场景对启动时间敏感，比如要求上电后几十毫秒内就要响应外部信号。这时候需要量化启动到底花了多久。

最简单的测量方法：在Reset_Handler的第一条指令处把一个 GPIO 拉高，在main的第一行拉低，用示波器或者逻辑分析仪看这个脉冲的宽度。这个宽度就是"从复位到进 main"的纯启动时间，不含main里的业务初始化。如果要分段测量，就在SystemInit前后各加一个翻转，能看到时钟配置占了多少。

裁剪的方向主要有这么几个：

减少.data段的大小。搬运时间是和段大小成正比的。有些工程把所有常量缓冲区都定义成带初值的数组，全塞进.data，启动时一个个搬。这些数据如果只读，加个const就进 Flash 了，根本不占 RAM 也不占搬运时间。这一条能省下的时间往往比想象的多。

慎用大数组清零。.bss清零是逐字写，一个 10K 的缓冲区就要写 2560 次。如果这块缓冲区只在特定功能里用，可以考虑改成用时再初始化，或者放到自定义段里不参与启动清零。

延后外设初始化。SystemInit只做最小必要的事：时钟、Flash 等待周期、向量表。串口、SPI、定时器这些完全可以挪到main里按需初始化，甚至在第一次使用时才初始化（懒加载）。这样启动脉冲会短很多。

构造函数里少干活。C++ 全局对象的构造函数是在main之前跑的，里面每多一行耗时操作，启动时间就多一截。我见过在全局对象构造函数里做 Flash 参数读取的，一次读几百毫秒，整个启动就被拖住了。这类操作应该改成显式调用。

另外还有一个容易被忽略的点：Flash 等待周期。系统时钟提上去之后，Flash 的读取速度跟不上，必须插入等待周期。如果SystemInit里先切了时钟、后配等待周期，中间那段时间 CPU 从 Flash 取指可能出错。正确的顺序是先配等待周期，再切时钟。这个顺序在很多模板里是对的，但自己改时钟配置的时候很容易搞反，改完就出现"偶发跑飞"，非常难查。

我个人在实际操作中的体会是，启动这块内容看着枯燥，但它几乎是所有"玄学问题"的源头。程序跑飞、变量初值不对、中断进错函数、烧录后不启动，这些现象背后往往就是启动链条上的某一环没对上。与其出了问题到处加打印、换芯片、怀疑编译器，不如花半天时间把启动文件、链接脚本、.map文件这三样东西对着看一遍，把每个符号的地址和每个段的边界都搞清楚。这份功夫一次投入，后面能省掉很多次深夜排查。