STM32从上电复位到第一个任务：启动流程与RTOS切换全解析

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

很多人写STM32代码，main函数里第一行就是HAL_Init()，前面发生了什么基本靠脑补。我刚开始搞STM32那会儿也一样，觉得复位之后CPU自然就跑到main了，中间那些启动文件、向量表、链接脚本，全是Keil自动生成的，不用管。直到有一次做一个带uC/OS-II的项目，系统跑着跑着偶尔在启动阶段就卡死，连第一个任务都没进去，我才被迫把从复位向量到第一个任务这条链路完整捋了一遍。捋完之后发现，这里面藏着不少平时根本不会注意的细节，而这些细节恰恰是排查启动类问题的关键。

这篇内容就是把我自己踩过的坑、验证过的流程、以及实际调试中总结出来的经验，完整地拆开讲一遍。核心围绕STM32从上电复位到第一个用户任务运行的全过程，涉及复位向量表的定位、启动文件的执行顺序、时钟系统的初始化、C运行时环境的建立，以及uC/OS-II环境下PendSV如何完成第一次任务切换。适合已经能写STM32裸机程序、但对底层启动机制一知半解的开发者，也适合正在用RTOS做项目、遇到启动异常不知道从哪下手的人。读完之后，你至少能做到：拿到一个启动就挂的板子，知道该从哪几个关键点去查，而不是盲目地换芯片、换下载器。

STM32的启动流程，本质上就是一条从硬件复位到软件接管的时间线。这条时间线上有几个关键节点：复位向量取址、栈指针初始化、Reset_Handler执行、时钟配置、数据段搬运、main调用、RTOS初始化、第一次任务切换。每个节点出问题，表现都不一样。比如栈指针没设对，可能一进main就HardFault；时钟没配好，串口打印出来全是乱码；PendSV优先级设错，任务切换直接卡死。下面我按这条时间线的顺序，逐个拆解。

2. 复位向量与启动文件的底层逻辑

2.1 复位向量到底存在哪，怎么被找到

Cortex-M内核规定，复位后CPU会从地址0x00000000处读取两个32位值：第一个是初始栈指针（MSP），第二个是复位向量（Reset Handler的地址）。注意，这里说的是“从地址0x00000000读取”，但实际STM32的Flash是从0x08000000开始的，那怎么对应上的？这就涉及到STM32的存储器映射和启动模式选择。

STM32有三种启动模式，通过BOOT0和BOOT1引脚（部分型号只有BOOT0）来选：

所谓“别名”，就是芯片内部把物理地址0x08000000的内容映射到了0x00000000这个CPU复位时必然访问的地址上。所以你编译出来的向量表放在Flash最前面，CPU复位后就能正确读到MSP和Reset Handler地址。

这里有个容易踩的坑：如果你用Keil或IAR，链接脚本里Flash起始地址写的是0x08000000，但向量表偏移寄存器SCB->VTOR默认值也是0x00000000。在大多数情况下，因为别名机制，0x00000000和0x08000000内容一样，所以中断也能正常响应。但如果你做了IAP升级、或者把程序分成了Bootloader和App两部分，App的向量表不在Flash最前面，就必须手动设置SCB->VTOR = 0x08004000之类的偏移值，否则中断一来就跳飞到Bootloader的向量表里去了。

提示：判断向量表是否被正确设置，可以在调试器里直接查看SCB->VTOR寄存器的值，对比你的链接脚本中Flash起始地址。

2.2 启动文件里那些汇编代码，每一行都有用

以STM32F1的startup_stm32f10x_md.s为例，复位之后执行的第一段代码就是Reset_Handler。这个函数不长，但每一步都不能少。我把它拆成几个阶段来看。

第一阶段是栈指针和向量表的初始化。实际上MSP已经在复位时由硬件从向量表第一个字自动加载了，不需要软件再设。但如果你用的是RTOS，后面任务切换时会用到PSP，那是另一回事。向量表这边，启动文件里通常有一句LDR R0, =SystemInit和BLX R0，调用SystemInit函数。这个函数在标准库或HAL库里都有，主要工作是配置时钟系统——把外部晶振打开、PLL倍频、切换系统时钟源到PLL。很多人以为时钟是在main里配的，其实在SystemInit里就已经配好了，main里的SystemClock_Config是HAL库后来加的，两者有重叠，但启动阶段的时钟配置是保证后续代码能跑起来的前提。

第二阶段是数据段搬运。C语言里初始化的全局变量和静态变量，它们的初始值存在Flash里，但运行时需要拷贝到RAM中。启动文件里的_sidata、_sdata、_edata这几个符号就是用来标记Flash中初始值起始地址、RAM中数据段起始和结束地址的。汇编代码会循环把Flash里的值搬到RAM。如果这一步出问题，表现就是全局变量初值不对，比如你定义int flag = 1;，结果运行时flag是0或者随机值。

第三阶段是BSS段清零。未初始化的全局变量和静态变量放在BSS段，启动代码会把从_sbss到_ebss这段RAM全部写0。如果BSS段没清零，那些“默认应该是0”的变量就会是上电后的随机值，这种bug非常隐蔽，因为大部分时候RAM上电后恰好是0，但偶尔不是，导致程序行为不稳定。

第四阶段是调用__libc_init_array，这是C库的初始化，主要用来调用C++的全局构造函数。如果你用C++写STM32，全局对象的构造函数就是在这里被调用的。纯C项目这一步也不能省，因为标准库可能依赖一些初始化。

最后才跳到main。所以从复位到main，中间经历了：硬件加载MSP、跳转Reset Handler、SystemInit配时钟、搬运数据段、清零BSS、C库初始化、调用main。这条链上任何一环断了，都到不了main。

2.3 链接脚本和启动文件的配合关系

启动文件里的那些符号——_sidata、_sdata、_edata、_sbss、_ebss——并不是汇编文件自己定义的，而是在链接脚本（.ld文件或Keil的.sct文件）里定义的。链接器根据各个段的大小和位置，计算出这些符号的地址，启动文件再引用它们。

以GCC的.ld文件为例，典型的数据段定义是这样的：

_estack = 0x20005000; _sidata = LOADADDR(.data); .data : { _sdata = .; *(.data*) _edata = .; } >RAM AT> FLASH .bss : { _sbss = .; *(.bss*) _ebss = .; } >RAM

LOADADDR(.data)就是数据段在Flash中的加载地址，也就是_sidata。AT> FLASH表示这个段的加载地址在Flash，运行地址在RAM。链接器会自动处理地址转换，启动文件只需要按符号搬运就行。

如果你自己改链接脚本，比如把RAM起始地址改了、或者增加了自定义段，一定要同步检查启动文件里的符号是否还匹配。我见过有人把栈顶地址_estack改错了，结果一上电就HardFault，查了半天以为是芯片坏了。

3. 从main到第一个任务：RTOS启动的关键路径

3.1 main函数里那些初始化，顺序不能乱

到了main之后，裸机项目和RTOS项目的分叉就开始了。裸机项目比较简单，初始化外设、写业务逻辑就行。但RTOS项目，main里的初始化顺序直接影响系统能不能正常启动。

以uC/OS-II为例，典型的main结构是这样的：

int main(void) { BSP_Init(); // 板级初始化，配时钟、GPIO、串口 OSInit(); // uC/OS-II内核初始化 OSTaskCreate(TaskStart, // 创建起始任务 (void *)0, &TaskStartStk[APP_TASK_START_STK_SIZE - 1], APP_TASK_START_PRIO); OSStart(); // 启动多任务调度 return 0; }

这里有几个关键点。BSP_Init必须在OSInit之前，因为内核初始化可能依赖系统时钟，比如OSTimeTick需要定时器中断。OSTaskCreate创建的是第一个任务，但此时调度器还没启动，任务不会运行。OSStart才是真正启动调度器，它会找到最高优先级的就绪任务，然后切换过去。

OSStart内部做的事情，就是找到最高优先级任务的任务控制块（TCB），然后把它的栈指针加载到CPU的PSP，再触发一次异常返回，让CPU从PSP指向的栈里恢复上下文，从而“进入”这个任务。这个过程在Cortex-M上是通过PendSV异常来完成的。

3.2 PendSV在第一次任务切换中扮演什么角色

Cortex-M内核有三个系统异常：SysTick、PendSV、SVC。其中PendSV是可挂起的系统服务异常，它的特点是优先级可以设成最低，而且可以手动挂起。RTOS利用这个特性来实现任务切换：当需要切换任务时，先把PendSV挂起，等当前中断处理完、所有高优先级异常都退出后，PendSV才执行，在PendSV处理程序里完成实际的上下文保存和恢复。

第一次任务切换稍微特殊一点。OSStart调用时，系统还在MSP（主栈）上运行，没有“当前任务”的概念。uC/OS-II的做法是：手动构造一个假的异常返回现场，把PSP指向第一个任务的栈，然后触发PendSV。PendSV处理程序里，它会认为“上一个任务”的上下文已经保存在PSP指向的栈里了（实际上是手动构造的），然后恢复“下一个任务”的上下文——也就是第一个任务的上下文。

具体来说，OSStartHighRdy这段汇编会做几件事：

1. 调用OSTaskSwHook，这是用户钩子函数，可以在这里做硬件相关的操作。
2. 把OSTCBHighRdy指向最高优先级任务的TCB，然后从TCB里取出栈指针，加载到PSP。
3. 设置PendSV的优先级为最低（通常是0xFF）。
4. 触发PendSV异常。
5. 在PendSV_Handler里，保存当前上下文（此时是MSP上的启动代码上下文），然后恢复PSP指向的任务上下文。
6. 异常返回时，CPU从PSP恢复寄存器，正式进入第一个任务。

这里有个细节：PendSV_Handler里保存和恢复上下文的顺序，必须和硬件自动压栈的顺序一致。Cortex-M在异常入口会自动把xPSR、PC、LR、R12、R3、R2、R1、R0压入当前栈（如果是任务上下文，就是PSP）。所以RTOS的上下文切换代码只需要手动保存R4-R11，剩下的硬件已经做了。如果顺序搞错，任务切换后寄存器值就乱了，表现就是任务跑飞或者HardFault。

3.3 任务栈的初始化，为什么第一个任务栈要特殊处理

每个任务都有自己的栈空间，在创建任务时由用户提供。OSTaskCreate会把任务的初始上下文压入这个栈，包括PC指向任务函数入口、LR指向任务退出处理函数、以及一些初始寄存器值。这样当任务第一次被调度时，PendSV恢复上下文，CPU就能从任务函数入口开始执行。

第一个任务和后续任务的区别在于：后续任务切换时，当前任务的上下文是真实保存在栈里的；而第一个任务切换时，“当前任务”的上下文是手动构造的，实际上就是启动代码的上下文。uC/OS-II在OSStartHighRdy里会模拟一次上下文保存，把当前MSP上的寄存器值压入一个临时区域，然后切换到第一个任务的PSP。这个临时区域其实就是启动代码的栈，之后不会再被使用。

如果第一个任务的栈大小不够，或者栈顶地址没对齐（Cortex-M要求栈8字节对齐），第一次任务切换就可能出问题。我遇到过因为栈顶没对齐导致进入任务后HardFault的情况，查了很久才发现是OSTaskCreate时栈顶指针传错了。

4. 实操验证：用调试器跟踪启动全流程

4.1 硬件和工具准备

要验证启动流程，光看代码不够，得用调试器实际跟踪。我用的组合是STM32F103C8T6最小系统板加ST-Link V2，软件用Keil MDK 5或者STM32CubeIDE都行。Keil的调试器可以看寄存器、看内存、设断点，足够用了。

接线很简单：ST-Link的SWDIO、SWCLK、GND、3.3V分别接到板子上对应的引脚。注意有些最小系统板的SWD接口顺序不一样，接之前先用万用表确认一下，别把电源接反了。

4.2 在关键节点设断点

我通常会在以下几个位置设断点：

• Reset_Handler的第一条指令：确认复位后PC确实跳到了这里。
• SystemInit入口：确认时钟配置函数被调用。
• main入口：确认启动文件执行完毕。
• OSStart入口：确认RTOS初始化完成。
• PendSV_Handler入口：确认第一次任务切换触发。
• 第一个任务函数的入口：确认任务真正运行。

在Keil里，打开调试模式后，在反汇编窗口找到这些函数的地址，按F9设断点。然后按F5全速运行，看程序是否在每个断点处停下。如果某个断点没停，说明前面的流程出了问题。

4.3 查看向量表和栈指针

复位后第一时间，在Keil的Memory窗口输入0x00000000，可以看到前两个字：第一个是MSP的初始值，通常是0x20005000（对于64KB RAM的F103，栈顶在RAM末尾）；第二个是Reset Handler的地址，通常是0x08000xxx。如果这两个值不对，比如MSP是0或者Reset Handler指向奇怪的地方，那说明向量表有问题，可能是链接脚本配错了，或者启动模式选错了。

还可以在Register窗口看MSP和PSP的值。复位后MSP应该是0x20005000，PSP通常是0。进入第一个任务后，PSP会变成任务栈的地址，MSP还是原来的值（因为中断处理用MSP）。

4.4 单步跟踪PendSV切换过程

PendSV的切换过程是启动流程里最微妙的部分。我建议在PendSV_Handler入口设断点，然后单步执行，观察每一步寄存器的变化。

进入PendSV_Handler时，硬件已经自动把xPSR、PC、LR、R12、R3-R0压入了PSP指向的栈（如果是任务上下文）。此时LR的值是0xFFFFFFFD，表示异常返回后使用PSP。然后RTOS代码会手动压入R4-R11，保存当前任务的完整上下文。接着从下一个任务的TCB里取出栈指针，恢复R4-R11，再更新PSP。最后执行异常返回指令，硬件自动从PSP弹出xPSR、PC等，跳转到任务函数。

单步执行时，重点看PSP的值是否在切换前后发生了变化，以及PC最终是否指向了任务函数入口。如果PC指向了奇怪的地方，检查任务函数的地址是否正确写入了任务栈。

注意：单步执行PendSV时，不要在中断入口处停留太久，因为SysTick可能在此期间触发，导致嵌套异常，干扰调试。可以在进入PendSV前先关掉SysTick中断，调完再打开。

5. 常见启动问题与排查速查

5.1 启动阶段HardFault的几种典型原因

启动阶段HardFault是最常见的问题，表现就是程序一下载就挂，连main都进不去。根据我的经验，原因主要有这几类：

其中PendSV优先级配置错误特别隐蔽。Cortex-M的NVIC优先级分组决定了抢占优先级和子优先级的位数。如果PendSV的优先级不是最低，它可能在SysTick或其他中断处理过程中被抢占，导致上下文切换嵌套，最终栈溢出或寄存器错乱。uC/OS-II要求PendSV优先级设为最低，通常写NVIC_SetPriority(PendSV_IRQn, 0xFF)。

5.2 全局变量初值不对，怎么查

如果程序能跑到main，但全局变量的初值和代码里写的不一样，比如int flag = 1;结果flag是0，那基本可以确定是数据段搬运出了问题。排查步骤：

1. 在调试器里查看_sidata、_sdata、_edata三个符号的地址。_sidata应该在Flash区域（0x08000xxx），_sdata和_edata应该在RAM区域（0x20000xxx）。
2. 检查_sidata到_sidata + (_edata - _sdata)这段Flash内容，是否和_sdata到_edata的RAM内容一致。如果不一致，说明搬运代码没执行或者执行错了。
3. 检查链接脚本里.data段的AT> FLASH是否正确。如果漏了这句，数据段的加载地址和运行地址会一样，都在RAM，但RAM上电后没有初始值，搬运就搬了个寂寞。

还有一种情况是BSS段没清零。如果未初始化的全局变量上电后不是0，检查_sbss到_ebss这段RAM是否被写0。有些启动文件用LDR和STR循环清零，如果循环条件写错，可能只清了部分。

5.3 任务切换后跑飞，从哪下手

任务切换后跑飞，通常表现为第一个任务执行几条指令后就HardFault，或者直接跳到莫名其妙的地方。排查思路：

• 检查任务栈大小。如果任务里调用了printf或者浮点运算，栈需求会比较大。我一般给任务栈至少512字节，复杂的给1KB以上。
• 检查任务函数的声明。OSTaskCreate要求任务函数是void (*)(void *)类型，如果写成void task(void)，参数传递会出错，导致栈上的参数不对。
• 检查PendSV_Handler是否被正确链接。有些工程里同时有标准库的PendSV_Handler和RTOS的PendSV_Handler，链接器可能选了错误的那个。可以在PendSV_Handler里加一句GPIO翻转，用示波器看是否被执行。
• 检查栈8字节对齐。Cortex-M的异常入口要求栈8字节对齐，如果任务栈顶不是8字节对齐，第一次异常返回时可能触发HardFault。OSTaskCreate的栈顶参数应该是&stack[Size - 1]，并且Size最好是8的倍数。

5.4 时钟配置错误导致串口乱码

串口打印乱码是启动阶段另一个高频问题。根本原因通常是系统时钟频率和串口波特率计算不匹配。比如SystemInit里把系统时钟配成了72MHz，但串口初始化时按8MHz算波特率，打印出来就是乱码。

排查方法：在main里第一行就打印SystemCoreClock的值，看是否和预期一致。如果不一致，检查SystemInit里的PLL配置和晶振频率是否匹配。有些板子的晶振是8MHz，有些是12MHz，如果代码里写死了8MHz，换板子就会出问题。

另外，HAL库的HAL_Init()会调用HAL_InitTick()，里面用SysTick配置1ms中断。如果SysTick时钟源选的是HCLK/8而不是HCLK，延时函数的时间基准就会差8倍。这个在HAL_Init里可以配，但很多人不注意。

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

6.1 中断向量表的实际布局

向量表不只是复位向量和几个异常，它包含了所有外设中断的入口地址。STM32F103的向量表有60多个条目，每个条目4字节。启动文件里用DCD指令逐个列出这些处理函数的地址。如果某个中断处理函数没定义，链接器会用一个默认的弱符号（通常是死循环）填充。这意味着如果你使能了某个中断但没写处理函数，中断一来就死循环。

我建议在启动文件里把用不到的中断处理函数都改成空函数或者直接删掉，让链接器用默认的。但要注意，有些中断在库函数里已经定义了弱符号，你自己再定义会覆盖它。如果两个都定义了，链接器可能报重复定义错误。

6.2 SystemInit到底做了什么

SystemInit是标准库和HAL库都有的函数，在启动文件里被调用。它的主要工作是：

• 使能外部高速晶振（HSE）。
• 配置PLL倍频系数。
• 切换系统时钟源到PLL。
• 配置AHB、APB1、APB2的分频系数。
• 设置Flash等待周期。

对于STM32F1，如果HSE是8MHz，PLL倍频9倍，系统时钟就是72MHz。AHB不分频，APB1二分频（36MHz），APB2不分频（72MHz）。Flash等待周期需要设为2，因为72MHz下Flash访问需要插入等待状态。

如果SystemInit里HSE起振失败，它会自动切换到HSI（内部8MHz RC振荡器），系统时钟变成8MHz。这时候串口波特率如果按72MHz算，就会乱码。所以调试时如果发现时钟不对，先检查HSE是否起振。

6.3 启动时间到底花在哪

从复位到第一个任务运行，时间主要花在几个地方：HSE起振等待（通常几毫秒）、PLL锁定等待（几百微秒）、Flash搬运数据段（取决于数据段大小，通常几十微秒）、RTOS初始化（几微秒）。整体下来，从上电到任务运行，大概在10毫秒以内。

如果启动时间明显偏长，比如几百毫秒才进任务，检查HSE起振超时时间是否设得太长。标准库的HSEStartUp_TimeOut默认是0x0500，大概几毫秒。如果晶振质量差，起振慢，可以适当加大这个值，但不要太大，否则起振失败时等待时间过长。

6.4 低功耗模式下的启动差异

如果项目里用了低功耗模式，比如待机模式唤醒后，启动流程和上电复位不完全一样。待机模式唤醒相当于一次复位，但有些寄存器状态会保留，比如备份域寄存器。如果启动代码里依赖这些寄存器的初始值，可能会出问题。我一般会在启动早期就把备份域寄存器读出来判断唤醒源，再做相应处理。

7. 我个人的几条实操建议

启动流程这东西，平时不出问题的时候感觉不到它的存在，一旦出问题就是致命性的，而且往往很难查。我自己的习惯是，每做一个新项目，第一件事就是在调试器里把启动流程走一遍，确认每个关键节点都正常。具体来说：

第一，在Reset_Handler、SystemInit、main、OSStart、PendSV_Handler、第一个任务入口这六个位置设断点，全速跑一遍，看是否都能停住。这一步花不了五分钟，但能提前发现大部分启动问题。

第二，在main的第一行打印SystemCoreClock和SCB->VTOR的值，确认时钟和向量表都正确。串口打印是最直观的验证手段，比看寄存器方便。

第三，任务栈大小宁大勿小。我一般给起始任务1KB栈，其他任务512字节起步。如果任务里用了浮点、printf、递归，栈还要加大。栈溢出是RTOS项目里最难查的问题之一，提前留足余量比事后调试划算得多。

第四，PendSV和SysTick的优先级一定要检查。PendSV必须是最低优先级，SysTick可以比PendSV高，但不要和PendSV同优先级。NVIC优先级分组建议用NVIC_PriorityGroup_4，全部用作抢占优先级，这样优先级关系最清晰。

第五，如果用了IAP或者多程序分区，向量表偏移一定要设对。SCB->VTOR = FLASH_BASE | OFFSET，其中OFFSET是应用程序起始地址相对于Flash基址的偏移。设完之后最好在调试器里确认一下SCB->VTOR的值。

最后再分享一个小技巧：如果怀疑启动阶段有问题但不确定具体位置，可以在启动文件里加几个GPIO翻转指令，用示波器看波形。比如在Reset_Handler开头翻转一个IO，在SystemInit入口翻转另一个，在main入口再翻转一个。这样用示波器就能看到启动各阶段的时间分布，比单步调试直观得多。这个方法我在排查一个启动偶发卡死的项目时用过，最后定位到是HSE起振偶尔超时，换了晶振负载电容就好了。