Cortex-M 启动流程：从上电复位到 main()，芯片都干了什么

很多工程师写了几年 Cortex-M 代码，却没细想过：上电那一刻到 main() 第一行之间，芯片到底经历了什么。理解启动流程，HardFault 定位、bootloader 跳转、启动时间优化这些硬骨头才啃得动。

一、复位后第一件事：找向量表

Cortex-M 上电复位后，硬件自动从地址 0x00000000 取栈顶指针（MSP 初始值），从 0x00000004 取复位向量（Reset_Handler 地址），然后跳转执行。注意这是硬件行为，不需要任何软件参与——所以向量表必须烧在复位后能取到的地址，这是 bootloader 和 APP 分区设计的起点。

二、Reset_Handler 干的三件事

复位处理函数一般做三步：1）系统时钟初始化（从内部低速时钟切换到目标主频，配置 PLL）；2）数据段搬运——把 Flash 里的 .data 初始值拷贝到 RAM，把 .bss 清零；3）调用 SystemInit（CMSIS 标准）和 __main，最终进入 main()。__main 还会做 C 库初始化（堆栈、静态构造等），这就是为什么 main() 之前全局变量已经可用。

三、启动时间的账

对需要快速启动的场景（比如上电 100ms 内要点亮或响应），启动时间要逐项拆：时钟稳定等待、Flash 读取速度、.data 搬运量、C 库初始化。常见优化：用内部高速时钟先跑起来再切 PLL、精简 .data 段、对时间关键的外设初始化前移到 main() 之前按优先级排。经验规律：启动慢八成是时钟等待和 C 库初始化在吃时间，先量再动手。

四、bootloader 跳转的坑

带 bootloader 的系统，跳转到 APP 前必须做三件事：关闭中断并清 pending、重定位向量表（设置 VTOR 指向 APP 的向量表）、正确设置 MSP 为 APP 的栈顶。漏掉任何一步，APP 跑起来就会出现莫名其妙的 HardFault。调试技巧：跳转后第一时间在 APP 的 Reset_Handler 入口打断点，看 MSP 和 VTOR 对不对，八成问题现形。

五、HardFault 和启动的关联

很多 HardFault 本质是启动阶段埋的雷：栈顶指针取错（向量表损坏或地址映射不对）、时钟没起振就访问外设、.bss 未清零导致状态机初值错乱。定位套路：先看 LR 和堆栈回溯，再看 BFAR/MMFAR 寄存器判断是取指 fault 还是数据访问 fault，最后对照启动流程一步步排除。

结论：启动流程是 Cortex-M 的"地基"，花半天时间把复位向量、数据搬运、时钟初始化这条链路吃透，后面所有底层调试都会顺得多。

Cortex-M 从上电到 main() 大致走过这几步：1）芯片取复位向量，跳转到启动代码 Reset_Handler；2）设置栈指针（MSP），这一步必须在任何 C 代码能跑之前完成；3）初始化时钟树（PLL、总线分频）——因为复位后通常跑内部低速时钟，不配 PLL 就跑不到标称主频；4）初始化存储器（copy .data 段到 RAM、清零 .bss 段）；5）调用 SystemInit 和可选的库初始化（如 HAL_Init）；6）最后跳 main()。最容易被忽略的是第 3 步顺序——如果在时钟还没配好时就去初始化依赖高速时钟的外设，会直接卡死。排查启动问题时，在 Reset_Handler 打断点是最高效的入口。