1. 上电那一刻，芯片到底在干什么

很多人调 STM32 调了几年，写业务逻辑、配外设、跑 RTOS 都不在话下，但一旦遇到“程序跑不起来”“HardFault 一上电就挂”“跳转 bootloader 后卡死”这类问题，就开始抓瞎。根子往往不在业务代码，而在从上电到main()之间那段“黑盒”——也就是复位向量到第一个任务的完整启动链路。这篇东西就是把这根链路从头到尾拆开讲清楚，包括裸机启动和带 uC/OS-II 的启动两条线，顺带把 PendSV、MSP/PSP 切换、向量表重定位这些容易踩坑的点讲透。

先把结论摆前面：STM32 上电后，CPU 干的第一件事不是执行你的main，而是从地址 0x00000000 处取两个 32 位值——第一个是初始 MSP（主堆栈指针），第二个是复位向量（Reset_Handler 的地址）。取完这两个值，硬件自动把 MSP 设好，然后跳到 Reset_Handler。这中间没有任何“操作系统”参与，全是硬件行为。理解这一点，后面所有启动细节都能串起来。

这篇文章适合谁看？如果你写过 STM32 的裸机工程、用过标准库或 HAL 库、跑过 FreeRTOS 或 uC/OS-II，但从来没认真看过startup_stm32fxxx.s和system_stm32fxxx.c，那这篇就是给你补课的。如果你正在做 bootloader、OTA 升级、或者多任务系统里遇到栈溢出、任务切换异常，那这篇更值得逐字读。我会尽量用“人话”讲，不堆术语，但该有的细节一个不少。

2. 启动链路整体设计：从硬件取向量到 C 世界

2.1 为什么启动代码要用汇编写

STM32 的启动文件（startup_stm32f103xb.s这类）是汇编写的，很多人第一次看到就头大。为什么不用 C？因为上电瞬间 C 运行环境还不存在——栈指针没设、.data段没从 Flash 搬到 RAM、.bss段没清零。这些事必须用汇编手动做，做完才能跳进 C 的main。用 C 写启动代码，编译器生成的函数序言（prologue）会默认栈已经可用，但那时候 MSP 还没初始化，直接崩。

启动文件干的事，按顺序大致是这几件：

1. 定义向量表（Vector Table），放在 Flash 起始地址，第一项是初始 MSP，第二项是 Reset_Handler。
2. 定义Reset_Handler，里面调用SystemInit()（配置时钟、向量表重定位等），然后调用__main（注意不是main）。
3. __main是 C 库函数（ARM 的 microlib 或标准库提供），它负责把.data段从 Flash 拷贝到 RAM、把.bss段清零，最后才调用用户的main()。

这里有个经典误区：很多人以为 Reset_Handler 直接跳main。实际上中间隔了一个__main，它是 C 库的入口，做数据段初始化的。你如果在main之前想用全局变量，能用的前提就是__main已经把.data搬好了。

2.2 向量表长什么样，为什么第一项是栈指针

向量表本质是一个 32 位数组，放在 Flash 最前面（默认 0x08000000）。前几项固定：

为什么第一项是栈指针而不是代码地址？这是 ARM Cortex-M 的设计约定：上电时硬件需要先有一个可用的栈，才能执行任何函数调用。所以向量表第一项直接放栈顶地址，硬件取出来就塞进 MSP，第二项才是代码入口。这个设计让启动流程不需要任何软件干预就能建立最基本的运行环境。

栈顶地址怎么来的？在启动文件里通常写成__initial_sp，它由链接脚本（.sct文件或STM32F103XB_FLASH.ld）根据 RAM 大小自动算出。比如 STM32F103C8T6 有 20KB RAM，起始 0x20000000，栈顶一般设成 0x20005000（RAM 末尾），栈向下增长。

2.3 SystemInit 到底做了什么

SystemInit()在system_stm32f1xx.c里，上电后由 Reset_Handler 调用。它主要干三件事：

• 配置时钟：把 HSI（内部 8MHz RC）切到 HSE（外部晶振），再通过 PLL 倍频到 72MHz（F1 系列）。这一步决定了你后面所有外设的时钟基准。
• 配置向量表偏移：通过SCB->VTOR寄存器设置向量表基地址。默认是 0x08000000，但如果你做 bootloader，APP 的向量表可能被重定位到 0x08008000，这里就要改。
• 使能 Flash 预取：F1 系列需要开FLASH->ACR的预取位，否则 72MHz 下取指会变慢。

很多人调时钟调不通，问题就出在 SystemInit 里 HSE 起振失败，代码卡在等待 HSERDY 标志的死循环里。这时候要么换晶振，要么在 SystemInit 里加超时退出，回退到 HSI。

3. 核心细节拆解：MSP、PSP 与 PendSV 的三角关系

3.1 MSP 和 PSP 到底怎么分工

Cortex-M 有两个栈指针：**MSP（主栈指针）**和PSP（进程栈指针）。上电默认用 MSP，所有中断和异常处理都用 MSP。那 PSP 什么时候用？答案是：跑 RTOS 的时候，任务用 PSP，中断用 MSP。

为什么要分开？因为任务栈和中断栈混在一起会出大问题。假设任务栈只有 512 字节，中断来了往同一个栈压寄存器，很容易溢出。分开之后，中断永远用 MSP（通常栈空间大），任务用 PSP（每个任务独立栈），互不干扰。

切换动作发生在CONTROL寄存器的 bit1。写 1 表示线程模式用 PSP，写 0 表示用 MSP。注意：中断处理模式下永远用 MSP，CONTROL 的 bit1 在 handler 模式下被忽略。这是硬件强制的，防止你在中断里误切栈。

3.2 PendSV 为什么是 RTOS 切换任务的最佳选择

uC/OS-II 和 FreeRTOS 都用PendSV做任务切换，而不是用 SysTick 直接切。原因很讲究：

• SysTick 是周期性中断，如果直接在 SysTick handler 里做上下文切换，会打断其他中断的响应，导致中断延迟不可控。
• PendSV 是一个可挂起的异常，优先级可以设成最低。这样所有其他中断都能先处理完，最后才轮到 PendSV 做任务切换，保证中断响应实时性。

具体做法是：SysTick handler 里只做一件事——触发 PendSV（写ICSR寄存器的PENDSVSET位）。PendSV handler 里才真正做上下文保存和恢复。这样任务切换被“推迟”到所有高优先级中断处理完之后，系统实时性最好。

PendSV handler 的汇编大概长这样（简化版）：

PendSV_Handler: MRS R0, PSP ; 取当前任务的 PSP CBZ R0, PendSV_NoSave ; 如果是第一次，跳过保存 STMDB R0!, {R4-R11} ; 保存 R4-R11 到任务栈 LDR R1, =OSTCBCurPtr ; 取当前 TCB 指针 LDR R1, [R1] STR R0, [R1] ; 更新 TCB 的栈指针 PendSV_NoSave: PUSH {LR} BL OSIntExit ; 调用 OS 调度器 POP {LR} LDR R0, =OSTCBHighRdyPtr LDR R0, [R0] LDR R0, [R0] ; 取最高优先级任务的栈指针 LDMIA R0!, {R4-R11} ; 恢复 R4-R11 MSR PSP, R0 ; 更新 PSP ORR LR, LR, #0x04 ; 确保返回后使用 PSP BX LR

这段代码的关键点：R4-R11 是手动保存的，R0-R3、R12、LR、PC、xPSR 是硬件自动压栈的。这是 ARM 的约定，硬件压栈发生在异常入口，软件只需要保存剩下的寄存器。

3.3 第一次任务切换的特殊处理

系统启动后，第一个任务怎么跑起来？这里有个“第一次”的特殊情况。在OSStart()里，会先找到最高优先级任务，然后手动设置 PSP 指向该任务的栈，再触发 PendSV。但第一次进 PendSV 时，当前没有“正在运行的任务”，所以PSP可能是 0 或者无效值，代码里用CBZ R0, PendSV_NoSave跳过保存步骤。

这个细节如果处理不好，第一次任务切换就会 HardFault。我见过有人在移植 uC/OS-II 时忘了处理这个分支，结果一上电就挂，查了半天以为是栈大小问题，其实是第一次切换时访问了非法 PSP。

4. 实操过程：从复位到第一个任务的完整复现

4.1 裸机启动的完整流程

先看不带 RTOS 的情况。假设你用 Keil 建了一个 STM32F103 标准库工程，上电后发生的事按时间顺序是：

1. 硬件取向量：从 0x08000000 取 MSP，从 0x08000004 取 Reset_Handler 地址，跳过去。
2. 执行 Reset_Handler：调用SystemInit()，配置 72MHz 时钟和向量表。
3. 调用__main：C 库函数，拷贝.data段、清零.bss段。
4. 调用main()：进入你的业务代码。

这个过程可以用调试器验证。在 Keil 里，把断点设在main第一行，然后复位，看 Call Stack 窗口，你会看到main上面是__main，再上面是Reset_Handler。这就是完整的调用链。

如果你想更细地看，可以在 Reset_Handler 第一行设断点，单步走。你会看到 MSP 的值在第一步就被硬件设好了，值是链接脚本里定义的__initial_sp。

4.2 带 uC/OS-II 的启动流程

带 RTOS 的情况多了一层：main()里不再直接跑业务，而是初始化 OS、创建任务、调用OSStart()。完整链路是：

1. 硬件取向量，跳 Reset_Handler。
2. SystemInit 配时钟。
3. __main初始化数据段。
4. main()执行：
   • OSInit()：初始化 OS 内核，创建空闲任务。
   • 创建至少一个用户任务（OSTaskCreate）。
   • OSStart()：启动调度器。
5. OSStart()内部：
   • 找到最高优先级任务。
   • 设置 PSP 指向该任务栈。
   • 触发 PendSV。
6. PendSV handler 执行第一次任务切换，跳到任务入口函数。

这里的关键是OSStart()里的 PSP 设置。uC/OS-II 的OSStartHighRdy()是汇编写的，它会从最高优先级任务的 TCB 里取出栈指针，减去硬件压栈的 8 个寄存器（R0-R3、R12、LR、PC、xPSR）占用的 32 字节，然后设给 PSP。这样 PendSV 返回时，硬件自动从 PSP 弹出那 8 个寄存器，PC 就指向任务入口。

4.3 向量表重定位的实操

做 bootloader 时，APP 的向量表不在 0x08000000，而在比如 0x08008000。这时候需要两步：

第一步，在 APP 的SystemInit()里改SCB->VTOR：

SCB->VTOR = 0x08008000;

第二步，在 bootloader 跳转前，设置 MSP 并跳转到 APP 的 Reset_Handler：

typedef void (*pFunction)(void); pFunction JumpToApp; uint32_t appMsp = *(volatile uint32_t*)0x08008000; uint32_t appReset = *(volatile uint32_t*)0x08008004; __set_MSP(appMsp); JumpToApp = (pFunction)appReset; JumpToApp();

注意跳转前要关掉所有中断和外设，否则 APP 里重新初始化时会冲突。我踩过的坑是：bootloader 里开了 SysTick，跳转前没关，APP 里又初始化一遍，结果 SysTick 中断向量指向的还是 bootloader 的 handler，一进中断就跳飞。

5. 常见问题与排查技巧实录

5.1 上电就 HardFault 怎么查

HardFault 是启动阶段最常见的故障。排查思路：

• 先看是不是栈溢出。把 MSP 初始值打印出来，看是不是落在 RAM 范围内。如果链接脚本写错，MSP 可能指向非法地址。
• 再看向量表。如果 VTOR 没设对，中断来了会跳到错误地址。用调试器看SCB->VTOR的值。
• 最后看时钟。如果 HSE 起振失败，SystemInit 卡死，表现像 HardFault 但其实是死循环。

有个技巧：在 HardFault_Handler 里加死循环，然后用调试器看 LR 寄存器的值，能判断是从线程模式还是 handler 模式进来的。LR 的 bit2 为 0 表示 handler 模式，为 1 表示线程模式。

5.2 任务切换后跑飞的原因

跑 RTOS 时任务切换后跑飞，常见原因：

uC/OS-II 在 Cortex-M3 上默认不保存 FPU 寄存器（M3 没有 FPU），但如果你用 M4/M7，任务里用了浮点，就必须在 PendSV 里额外保存 S0-S15 和 FPSCR。这个坑很多人踩，表现是浮点计算结果莫名其妙出错。

5.3 向量表偏移忘了改的后果

做 OTA 升级时，APP 的向量表偏移如果忘了改，中断会跳到 bootloader 的向量表。表现是：APP 能跑，但一进中断就执行 bootloader 的 handler，通常直接 HardFault。这个问题的隐蔽性在于，如果 APP 没开中断，可能一直不触发，直到某个外设中断来了才挂。

排查方法：在 APP 的main里打印SCB->VTOR，确认是不是 APP 的向量表地址。如果不是，检查 SystemInit 里的VECT_TAB_OFFSET宏。

6. 几个容易被忽略的启动细节

6.1__main和main的区别

前面提过，Reset_Handler 调用的是__main而不是main。__main是 ARM C 库的入口，它做数据段初始化，然后才调main。如果你用 microlib，__main的行为略有不同，但核心逻辑一样。

有个细节：__main还会初始化堆（heap）。如果你在main之前用了malloc，能用的前提是__main已经把堆设好了。但一般不建议在启动阶段用堆，因为堆大小在链接脚本里定，容易溢出。

6.2 中断向量表的对齐要求

Cortex-M 要求向量表至少 128 字节对齐（VTOR 的低 7 位保留）。如果你把向量表放在 0x08008000，这是 256 字节对齐，没问题。但如果放在 0x08008080，就违反了 128 字节对齐，硬件行为未定义。做 bootloader 时，APP 起始地址要选 128 字节对齐的，比如 0x08008000、0x08010000。

6.3 启动阶段的看门狗处理

如果开了独立看门狗（IWDG），上电后它就开始计数。如果启动流程太长（比如 SystemInit 里等 HSE 起振超时），看门狗可能先复位。处理办法：在 Reset_Handler 最前面就喂一次狗，或者用窗口看门狗（WWDG）并合理设置窗口。

我遇到过一个问题：bootloader 里开了 IWDG，跳转 APP 前没关，APP 启动慢，看门狗复位，结果一直卡在 bootloader 和 APP 之间循环。解决办法是跳转前关掉 IWDG，APP 里重新初始化。

6.4 启动时间的测量

想知道从上电到main花了多久？可以用 GPIO 翻转加示波器测。在 Reset_Handler 第一行拉高一个 IO，在main第一行拉低，示波器上看脉宽就是启动时间。F103 在 72MHz 下，这段通常几十微秒到几百微秒，取决于时钟配置和数据段大小。

如果启动时间太长，优化方向：减少.data段大小（少用初始化全局变量）、加快 HSE 起振（换晶振或调负载电容）、关掉不必要的 SystemInit 步骤。

7. 从启动流程延伸出去的几个实战场景

7.1 bootloader 与 APP 的向量表协作

做 bootloader 时，APP 的向量表重定位是必须的。但还有个细节：APP 里的SystemInit会重新配时钟，如果 bootloader 已经配好了，APP 再配一遍可能出问题。稳妥做法是 APP 的 SystemInit 里判断时钟是否已经配好，配好就跳过。

另外，APP 的链接脚本要把起始地址改成 0x08008000，否则编译出来的向量表还在 0x08000000，和 bootloader 冲突。

7.2 OTA 升级中的启动跳转

OTA 升级时，新固件下载到备份区，校验通过后跳转到备份区运行。这时候启动流程变成：bootloader 判断升级标志，如果有效，重定位向量表到备份区，跳转。跳转前要确保备份区的向量表第一项（MSP）和 第二项（Reset_Handler）是有效的，否则跳过去直接挂。

校验方法：读备份区前 8 字节，检查 MSP 是否在 RAM 范围内，Reset_Handler 是否在 Flash 范围内。这两个检查能过滤掉大部分下载不完整的情况。

7.3 多任务系统里的栈规划

跑 uC/OS-II 时，每个任务要有独立栈。栈大小怎么定？经验值：简单任务 128 字节，复杂任务 512 字节到 1KB。但这是估算，实际要用OSTaskStkChk()检查栈使用率，留 30% 余量。

MSP 的栈（中断栈）也要规划。如果中断嵌套深，MSP 栈要大。F103 的 20KB RAM，通常 MSP 给 1KB，剩下给任务栈和全局变量。

有个坑：uC/OS-II 的OSTaskCreate里栈是从上往下增长的，传入的栈顶地址要是栈的高地址端。如果传反了，任务一跑就踩到别的内存。

8. 我个人的几条实操心得

调启动流程这些年，踩过的坑比写过的代码还多。几条心得分享出来，能帮你少走弯路。

第一，永远在 Reset_Handler 第一行设断点。不管什么问题，先确认启动流程走到哪一步了。如果连 Reset_Handler 都没进，那是硬件问题（供电、晶振、复位电路）；如果进了但没到main，那是 SystemInit 或__main的问题；如果到了main但跑飞，那是业务代码或 RTOS 配置的问题。这个三分法能快速定位问题域。

第二，向量表重定位后一定要验证。在 APP 的main里打印SCB->VTOR，确认值对。我见过有人改了VECT_TAB_OFFSET但忘了在 SystemInit 里用，结果 VTOR 还是默认值，中断全跳错。

第三，PendSV 优先级设成最低。这是 RTOS 移植的铁律。如果 PendSV 优先级比 SysTick 高，任务切换会打断 SysTick，导致系统节拍不准。uC/OS-II 的OS_CPU_SysTickInit里会设优先级，确认一下。

第四，第一次任务切换单独测。移植 RTOS 时，先创建一个任务，里面只翻转 IO，确认能跑起来。再加第二个任务，确认能切换。最后才加业务逻辑。这样出问题容易定位。

第五，启动时间要心里有数。如果产品对启动时间敏感（比如需要快速响应的设备），启动流程的每一步都要优化。我做过一个项目，启动时间从 200ms 优化到 50ms，主要靠减少.data段和加快时钟配置。

最后说个小事：很多人问“为什么我的 STM32 上电后 LED 闪一下就灭”。这通常是启动阶段看门狗复位，或者电源不稳导致反复复位。用示波器看复位引脚，如果有周期性脉冲，就是复位电路问题；如果复位引脚稳定但程序跑飞，就是启动流程问题。分清楚这两类，排查方向完全不同。