STM32上电到第一个任务：复位向量、启动流程与uC/OS-II调度机制

1. 上电那一瞬间，芯片里到底发生了什么

很多人做 STM32 开发，习惯性地在main()函数第一行打断点，然后点下载、复位、运行，看着程序停在main入口，就觉得"启动流程"这件事已经理解了。但如果你真的追问一句：从芯片上电到main()被调用，中间这几毫秒里 CPU 到底执行了哪些指令？栈指针是谁设置的？.data段的数据是怎么从 Flash 搬到 RAM 的？SystemInit()是在什么时机被调用的？——能完整答上来的人其实不多。

这篇内容就是想把 STM32 从上电复位到第一个任务跑起来这条链路彻底拆开讲清楚。核心关键词包括STM32、复位向量、启动流程、uC/OS-II、PendSV。我会从最底层的复位向量表讲起，一路走到启动文件、时钟初始化、C 运行时环境搭建，最后落到 RTOS 里第一个任务是怎么被调度器"请"上 CPU 的。中间会穿插我在实际项目中踩过的坑，比如栈顶地址配错导致 HardFault、.bss段没清零导致全局变量初值随机、PendSV 优先级设错导致任务切换异常等。

适合阅读的人群：已经能用 STM32 点灯、跑串口，但对自己写的代码"为什么能跑起来"没有完整认知的开发者；正在学习 uC/OS-II 或类似 RTOS，想搞明白任务切换底层机制的人；以及准备做 Bootloader、OTA 升级，需要精确控制启动流程的工程师。不管你是用标准库、HAL 库还是寄存器直接操作，这条链路都是一样的，区别只在于封装层次。

我下面会按照真实的执行顺序来组织内容，而不是按照教科书那种"先讲概念再讲实现"的方式。因为启动流程本身就是一个严格的时间序列，任何一步的顺序错了，后面全都跑不起来。

2. 复位向量表：CPU 醒来后看到的第一张地图

2.1 为什么是 0x08000000 这个地址

STM32 基于 ARM Cortex-M 内核，复位后 CPU 的行为是硬件固定的：它会从地址0x00000000处读取两个字。第一个字加载到MSP（主栈指针），第二个字加载到PC（程序计数器），然后从 PC 指向的地址开始执行。这个过程没有任何软件参与，是内核硬件逻辑直接完成的。

那为什么我们平时说 STM32 的启动地址是0x08000000？因为 STM32 的 Flash 物理起始地址就是0x08000000，而芯片内部做了一个地址重映射：复位后，0x00000000会被映射到0x08000000（当 BOOT0=0 时）。所以你烧录到 Flash 最前面的那两个 32 位数据，就分别成了初始 MSP 和复位向量。

这里有个很容易被忽略的细节：MSP 的值不是随便填的，它必须是 RAM 中一段合法地址的栈顶。在启动文件里，你会看到类似这样的定义：

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

__initial_sp就是栈顶地址，它等于Stack_Mem + Stack_Size。注意栈是向下增长的，所以栈顶是最高地址。如果这个值配错了，比如指向了 Flash 区域或者越过了 RAM 边界，第一次压栈就会触发 HardFault，而且这种错误往往在main()之前就发生了，调试器甚至停不下来，非常难查。

2.2 向量表里到底放了什么

紧接着 MSP 之后，就是一张向量表。前几项的顺序是固定的：

再往后就是各个外设中断的入口，比如 EXTI0、USART1、TIM2 等等。这张表的顺序由 Cortex-M 内核和具体芯片型号共同决定，不能随意改动。

我见过有同事在写 Bootloader 时，想把 APP 的向量表挪到别的位置，结果忘了改SCB->VTOR寄存器，导致中断一触发就跳到 Bootloader 的 Handler 里去了。VTOR（向量表偏移寄存器）是 Cortex-M3 及以上才有的，M0/M0+ 没有这个寄存器，向量表位置是固定的。这一点在做双区升级方案时必须提前确认芯片型号。

2.3 复位向量为什么指向 Reset_Handler

复位向量里存的是Reset_Handler的地址。CPU 加载完 MSP 和 PC 之后，就直接跳到Reset_Handler开始执行。这个函数是启动文件里用汇编写的，是整个 C 程序真正的入口。它的工作可以概括成三件事：设置时钟、搬运数据段、跳进 C 世界。

很多人以为main()是入口，其实在main()之前，Reset_Handler已经默默干了一大堆活。如果你在main()里发现某个全局变量初值不对，或者SystemCoreClock的值是错的，问题大概率就出在这一段。

3. Reset_Handler 里的三段式流水线

3.1 第一步：调用 SystemInit 把时钟拉起来

Reset_Handler的第一件事通常是调用SystemInit()。这个函数在system_stm32fxxx.c里，主要工作是配置时钟树：使能 HSE、配置 PLL、切换系统时钟源、设置 Flash 等待周期等。

为什么这一步要放在最前面？因为后面搬运.data段、清零.bss段都需要访问 RAM，而 RAM 的访问速度跟系统时钟有关。如果时钟没配好就跑搬运，虽然功能上也能跑（复位后默认用的是内部 HSI），但速度会慢很多，而且如果代码里依赖SystemCoreClock变量做延时计算，值不对会导致后续所有时序全乱。

这里有个实际经验：如果你用的是自定义时钟配置，比如把主频超到 168MHz 甚至更高，一定要在SystemInit()里把 Flash 的等待周期（Latency）设对。设少了会取指错误，表现为程序跑飞或者随机 HardFault；设多了只是性能损失，不会出错。我一般会留一档余量，宁可慢一点也要稳。

另外，SystemInit()里还会设置向量表偏移（如果定义了VECT_TAB_OFFSET）。在 Bootloader + APP 的方案里，APP 的SystemInit()需要把 VTOR 指向 APP 自己的向量表，否则中断会跑错地方。

3.2 第二步：搬运 .data 和清零 .bss

C 语言里，全局变量和静态变量分几种情况：

• 已初始化且初值非零：存在 Flash 里，运行时需要搬到 RAM，这就是.data段。
• 已初始化但初值为零：理论上可以放.bss段，运行时清零即可。
• 未初始化：放.bss段，运行时清零。

搬运过程在启动文件里是这样写的（以 Keil 的 armasm 为例）：

LDR R0, =|Image$$RW_IRAM1$$Base| ; RAM 中 .data 起始地址 LDR R1, =|Image$$ER_IROM1$$Base| ; Flash 中 .data 起始地址 LDR R2, =|Image$$RW_IRAM1$$Length| ; .data 长度 MOV R3, #0 CMP R2, #0 BEQ BSS_Init DATA_Copy: LDR R4, [R1, R3] STR R4, [R0, R3] ADD R3, R3, #4 CMP R3, R2 BCC DATA_Copy

这段代码的逻辑很直白：从 Flash 里逐字读到 RAM。但这里有个坑：链接脚本里的段地址和长度必须和实际匹配。如果你手动改过分散加载文件（.sct），把某个段放到了错误的地址，搬运就会覆盖掉其他数据，表现为程序一上电就死，或者某些变量莫名其妙被改。

.bss段的清零更简单，就是把一段 RAM 全部写 0。注意.bss段不占 Flash 空间，只占 RAM，所以如果你的全局数组很大，Flash 占用不会增加，但 RAM 会。

提示：如果你发现某个全局变量上电后初值不是 0 也不是你写的值，先检查它是不是被放到了.bss段但没清零，或者被.data搬运覆盖了。

3.3 第三步：跳进 main，但 C 环境还没完全就绪

搬运和清零做完之后，Reset_Handler会调用__main（注意是双下划线），这是 ARM 编译器提供的 C 库入口。__main会做一些库级别的初始化，比如堆的初始化，然后才调用我们写的main()。

这里要区分__main和main：前者是编译器运行时库的入口，后者是用户代码入口。很多人看启动文件时把这两个搞混，以为Reset_Handler直接跳main，其实中间还隔了一层。

到这一步，C 运行时环境才算基本就绪：栈有了、堆有了、全局变量初始化了、时钟配好了。接下来才是我们熟悉的main()函数。

4. 从裸机 main 到 RTOS 调度器：多出来的那几层

4.1 裸机程序和 RTOS 程序在启动阶段的差异

裸机程序里，main()通常是一个while(1)大循环，所有逻辑都在里面顺序执行或者靠中断驱动。启动流程到main()就结束了。

但用了 uC/OS-II 这类 RTOS 之后，main()里做的事情变成了：初始化硬件、调用OSInit()、创建任务、调用OSStart()。OSStart()会启动调度器，然后永远不会返回。从这一刻起，CPU 的控制权就交给了调度器，程序进入多任务并发执行的状态。

这个转变的关键在于：调度器需要一套自己的上下文切换机制，而这套机制依赖 Cortex-M 内核提供的两个特殊异常：SVC和PendSV。

4.2 SVC：第一次任务切换的发起者

OSStart()最终会调用OSStartHighRdy()，这个函数会触发一次SVC 异常（通过SVCall指令）。SVC 的作用是：在中断上下文里完成第一次任务切换，把 CPU 交给优先级最高的就绪任务。

为什么第一次切换要用 SVC 而不是直接跳转？因为 RTOS 需要模拟一个"从中断返回"的场景，这样才能正确地恢复任务的上下文（寄存器组、栈指针等）。如果直接跳过去，任务的栈帧格式不对，后续切换就会出错。

SVC 的优先级通常设得比较高，但不能高于 PendSV（后面会讲原因）。在 uC/OS-II 的移植代码里，OS_CPU_SysTickHandler和OS_CPU_PendSVHandler是两个核心的中断服务函数。

4.3 PendSV：任务切换的真正执行者

PendSV 是 Cortex-M 专门为 RTOS 设计的异常，它的特点是：可以像普通中断一样被挂起，但优先级可以设成最低。这样设计的好处是，当有其他中断正在处理时，PendSV 会被推迟，直到所有高优先级中断都处理完，才执行任务切换。这保证了中断响应的实时性，也避免了在中断里做上下文切换带来的复杂性。

任务切换的触发流程通常是这样的：

1. SysTick 定时器中断触发，调用OSTimeTick()更新延时计数。
2. 如果需要进行任务调度，就把 PendSV 异常挂起（写SCB->ICSR的PENDSVSET位）。
3. SysTick 中断返回后，由于 PendSV 优先级最低，CPU 会先处理其他挂起的中断（如果有）。
4. 所有高优先级中断处理完毕，PendSV 开始执行，在PendSV_Handler里完成寄存器压栈、任务控制块切换、寄存器出栈。
5. PendSV 返回，CPU 开始执行新任务的代码。

这里最关键的一点是PendSV 的优先级必须设为最低。如果 PendSV 优先级高于某个中断，那么在这个中断处理期间如果触发了任务切换，PendSV 会打断中断，导致中断处理被延迟，严重时会造成数据竞争。我见过有人把 PendSV 和 SysTick 设成同一优先级，结果系统跑着跑着就死机，查了很久才发现是优先级配置的问题。

4.4 第一个任务是怎么"跑起来"的

回到最初的问题：从复位向量到第一个任务，中间到底经历了什么？

完整的链路是这样的：

1. 上电，CPU 从0x00000000读取 MSP 和复位向量。
2. 跳转到Reset_Handler，调用SystemInit()配置时钟。
3. 搬运.data段，清零.bss段。
4. 调用__main，进入 C 运行时，最终调用main()。
5. main()里初始化硬件，调用OSInit()初始化 RTOS 内核。
6. 创建至少一个任务（通常是起始任务），调用OSStart()。
7. OSStart()找到最高优先级就绪任务，调用OSStartHighRdy()。
8. OSStartHighRdy()触发 SVC 异常。
9. SVC 处理函数里，从任务控制块恢复第一个任务的上下文（栈指针、寄存器）。
10. 异常返回，CPU 开始执行第一个任务的代码。

从第 8 步开始，程序就进入了 RTOS 的世界，main()的栈不再被使用，每个任务有自己的栈空间。这也是为什么 RTOS 程序里，main()的栈可以设得很小，因为它在调度器启动后就不再被使用了。

5. 那些年我在启动流程上踩过的坑

5.1 栈溢出导致的 HardFault：现象和排查

栈溢出是启动阶段最隐蔽的问题之一。现象通常是：程序在main()之前就死了，调试器显示停在HardFault_Handler，但调用栈是乱的，看不出是谁调用了谁。

排查方法：在HardFault_Handler里读取LR寄存器的值，判断出错前使用的是 MSP 还是 PSP。如果是 MSP，说明是启动阶段或者中断里出的问题；如果是 PSP，说明是某个任务栈溢出。然后查看SCB->CFSR寄存器，确定是总线错误、用法错误还是内存管理错误。

我遇到过一次，是因为启动文件里Stack_Size设得太小（只有 0x200），而SystemInit()里调用了一些库函数，压栈深度超过了这个值，直接把栈顶冲掉了。把Stack_Size改成 0x400 之后问题消失。经验值：启动阶段的栈至少留 1KB，如果用了 printf 之类的库函数，留 2KB 更稳妥。

5.2 .bss 段没清零：全局变量初值随机

有一次做一个项目，发现某个全局标志位上电后偶尔是 1，偶尔是 0，导致程序行为不一致。查了半天，发现是这个变量被编译器放到了.bss段，但启动文件里的清零循环长度算错了，漏掉了最后几个字节。

这种问题的根源通常是链接脚本和启动文件不匹配。比如你在分散加载文件里新增了一个 RAM 段，但启动文件里的清零循环只覆盖了默认的.bss范围，新段里的变量就没被清零。解决办法：要么把新段合并到.bss，要么在启动文件里显式清零。

5.3 PendSV 优先级配置错误：任务切换卡死

前面提到过，PendSV 优先级必须最低。但"最低"具体是多少？在 Cortex-M 里，优先级数值越大，优先级越低。所以 PendSV 的优先级应该设成0xFF（如果只用了 4 位优先级，就是0xF0）。

我见过有人把 PendSV 设成0x00，结果 SysTick 中断里挂起 PendSV 后，PendSV 立刻抢占了 SysTick，导致 SysTick 的计数逻辑没执行完就被打断，系统时间计算全乱。正确做法：SysTick 优先级设为中等（比如 0x80），PendSV 设为最低（0xFF），SVC 设为最高（0x00）。

5.4 向量表偏移没设对：中断跑到 Bootloader 里

做 Bootloader 时，APP 的向量表通常放在0x08008000或更靠后的位置。如果 APP 的SystemInit()里没有设置SCB->VTOR = 0x08008000，那么中断触发时，CPU 还是会去0x08000000找中断入口，结果跳进了 Bootloader 的 Handler，程序行为完全错乱。

这个问题的现象是：APP 单独烧录时跑得好好的，一旦通过 Bootloader 跳转过去，中断就不响应了。排查方法：在 APP 的main()里打印SCB->VTOR的值，确认是否指向了正确的地址。

6. 一张表看清启动各阶段的关键动作

这张表建议收藏，每次启动出问题的时候按顺序排查，能省很多时间。

7. 调试启动流程的几个实用手段

7.1 用调试器看反汇编

在 Keil 或 IAR 里，复位后不要直接点 Run，而是单步执行（Step Into）。你会看到 CPU 从Reset_Handler开始，一条一条执行汇编指令。这是理解启动流程最直观的方式。重点观察：

• MSP 的初始值是多少，是否在 RAM 范围内。
• SystemInit()调用前后，时钟相关寄存器的变化。
• .data搬运循环执行了多少次，源地址和目的地址是否正确。
• 跳转到main()时，栈指针的位置。

7.2 在启动文件里加"探针"

如果不想单步调试，可以在启动文件的关键位置插入一段写寄存器的代码，比如点亮一个 LED 或者翻转一个 GPIO。这样通过示波器或者肉眼就能判断程序执行到了哪一步。

比如在Reset_Handler开头加：

LDR R0, =0x40020014 ; GPIOA_ODR LDR R1, [R0] ORR R1, R1, #0x20 ; PA5 置位 STR R1, [R0]

如果上电后 LED 亮了，说明至少执行到了这里。如果没亮，说明问题在更前面。

7.3 用 HardFault 处理函数打印现场

在HardFault_Handler里加一段代码，把出错时的寄存器值通过串口打印出来，能快速定位问题。关键寄存器包括：

• R0-R3：函数参数
• R12：临时寄存器
• LR：返回地址
• PC：出错时的指令地址
• xPSR：程序状态寄存器

把这些值打印出来，再结合反汇编文件，就能知道是哪条指令出的错。

8. 关于启动流程，我个人的几点体会

做了这么多年 STM32，我越来越觉得启动流程是嵌入式开发的"基本功"。它不像写业务逻辑那样有成就感，但一旦出问题，往往是最难查的。因为启动阶段没有 printf，没有断点，很多时候只能靠经验和寄存器状态去推断。

我的建议是：每个项目开始前，花半小时把启动文件从头到尾读一遍。不用逐行理解汇编，但要知道每一段在干什么。特别是Stack_Size、Heap_Size、向量表偏移这几个地方，根据项目实际需求调整。用 RTOS 的项目，还要确认 SVC、PendSV、SysTick 的优先级配置。

另外，如果你在做 Bootloader 或者 OTA，启动流程的每一个细节都会被放大。APP 的向量表位置、栈顶地址、时钟配置，都必须和 Bootloader 协调好。我一般会在 Bootloader 里加一个校验环节，跳转前检查 APP 的栈顶地址是否合法、复位向量是否在 Flash 范围内，避免跳转到一片空白区域导致死机。

最后分享一个小技巧：如果你不确定某个配置是否正确，可以先用 STM32CubeMX 生成一个最小工程，对比它的启动文件和时钟配置。CubeMX 生成的代码虽然有时候显得臃肿，但在启动流程这块是经过验证的，可以作为参考基准。