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

很多人写STM32代码，习惯性地从main()函数第一行开始看，觉得程序就是从这里跑起来的。但如果你真的拿调试器去跟踪一次上电过程，会发现main()之前已经有一大堆事情发生了——时钟被配置了、内存被初始化了、中断向量表被建立了。这些东西不是魔法，而是一套非常确定的启动流程在起作用。

这篇文章要拆解的就是这个流程：从芯片复位引脚被拉高、CPU取出第一条指令开始，一直到RTOS创建第一个用户任务为止，中间到底经历了哪些阶段，每个阶段做了什么，为什么这么设计。涉及到的关键词包括复位向量、启动流程、uC/OS-II、PendSV等。适合有一定STM32裸机开发基础、想搞清楚底层启动机制的朋友，也适合正在移植RTOS、被启动文件和汇编代码困扰的开发者。

我自己的经验是，不理解启动流程，很多问题根本没法排查。比如全局变量初值不对、中断进不去、RTOS任务切换异常，这些问题的根因往往就藏在启动文件那几十行汇编里。下面我按实际执行顺序，一层一层往下拆。

2. 复位向量与启动模式：CPU醒来后的第一件事

2.1 复位向量的本质是什么

Cortex-M系列内核在设计上有一个固定约定：复位后，CPU会从地址0x00000000处取出主堆栈指针（MSP）的初始值，然后从地址0x00000004处取出复位向量（Reset Vector），也就是第一条要执行的指令地址。这两个值不是运行时计算的，而是芯片设计时硬性规定的。

复位向量本身是一个32位地址，指向的是Reset_Handler函数。在STM32的启动文件（startup_stm32xxxx.s）里，你会看到这样一段：

__Vectors DCD __initial_sp ; Top of Stack DCD Reset_Handler ; Reset Handler DCD NMI_Handler ; NMI Handler DCD HardFault_Handler ; Hard Fault Handler ...

这里__initial_sp是栈顶地址，通常指向SRAM的末尾。为什么栈顶要放在SRAM末尾？因为Cortex-M的栈是满递减栈，从高地址向低地址生长，放在末尾可以最大化利用连续空间，避免栈增长时撞到其他数据区。

2.2 启动模式选择：BOOT引脚决定了映射关系

STM32芯片内部有多个物理存储区域：主Flash、系统存储器、内嵌SRAM。复位后，哪个区域被映射到0x00000000地址，是由BOOT0和BOOT1引脚的电平决定的。这个映射过程由芯片内部的硬件逻辑完成，不需要软件干预。

这里有个容易踩的坑：很多人用串口下载程序后忘了把BOOT0拨回低电平，结果重新上电后程序不跑，以为是代码问题，其实是芯片进了系统存储器。我早期就因为这个折腾过一下午。

注意：部分STM32型号（如F4系列）的BOOT1与GPIO复用，需要在选项字节中配置，不能单纯靠外部引脚判断。

2.3 从复位向量到Reset_Handler

CPU取出复位向量后，跳转到Reset_Handler。这个函数是启动文件里第一个真正执行的代码，它做的事情非常关键，但很多人从来没打开看过。典型的Reset_Handler逻辑如下：

Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main IMPORT SystemInit LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP

可以看到，它先调用SystemInit，然后跳转到__main。注意这里的__main不是我们写的main()函数，而是C库的入口。这个区别非常关键，后面会详细说。

3. SystemInit与时钟树：让芯片跑起来的准备工作

3.1 SystemInit到底做了什么

SystemInit函数通常定义在system_stm32xxxx.c文件里，它的核心任务是配置时钟系统。STM32复位后默认使用内部的HSI振荡器（通常8MHz或16MHz），这个时钟精度和频率都不够用，所以需要在启动阶段切换到外部晶振（HSE）并配置PLL倍频。

以STM32F103为例，典型的配置目标是72MHz系统时钟。计算过程是这样的：

• HSE = 8MHz
• PLL倍频系数 = 9
• PLL输出 = 8MHz × 9 = 72MHz
• AHB预分频 = 1，所以HCLK = 72MHz
• APB1预分频 = 2，所以PCLK1 = 36MHz（最高36MHz）
• APB2预分频 = 1，所以PCLK2 = 72MHz

这些配置通过写RCC_CFGR、RCC_CR等寄存器完成。配置完成后，代码会等待PLL锁定标志位，确认时钟稳定后才切换系统时钟源。

3.2 向量表重定位的必要性

在SystemInit之后、进入main()之前，还有一个容易被忽略的操作：向量表重定位。STM32的向量表默认位于Flash起始地址（0x08000000），但通过SCB->VTOR寄存器可以将向量表搬到其他位置。

为什么需要重定位？两个典型场景：

1. Bootloader + App架构：Bootloader占用Flash前几十KB，App从某个偏移地址开始。App运行时需要把自己的向量表地址写入VTOR，否则中断会跳到Bootloader的向量表里去。
2. RAM中运行代码：调试阶段把代码加载到SRAM运行，向量表也需要相应调整。

重定位的代码通常长这样：

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;

其中VECT_TAB_OFFSET就是App相对于Flash起始地址的偏移量。这个值必须和链接脚本里的起始地址一致，否则中断向量会错位。

3.3 启动阶段的时钟配置经验

实际项目中，我一般不会把复杂的时钟配置全塞在SystemInit里。原因很简单：SystemInit在main()之前执行，此时看门狗可能还没初始化，如果时钟配置出错导致死循环，芯片会一直卡在那里，连喂狗的机会都没有。

更稳妥的做法是：SystemInit里只做最基本的时钟切换（比如切到HSE），把PLL配置、外设时钟使能放到main()里按需处理。这样即使出问题，也能通过调试器看到卡在哪一步。

4. __main与内存初始化：C运行时环境的建立

4.1 __main不是main

这是初学者最容易混淆的地方。启动文件里跳转的__main是C库的入口函数，由编译器工具链提供，不是我们写的main()。__main内部会调用__scatterload，完成代码段和数据段的重定位。

具体来说，它做三件事：

1. 把RW段（已初始化全局变量）从Flash拷贝到SRAM：全局变量如int g_count = 5;，初值存在Flash里，运行时必须搬到SRAM才能被读写。
2. 把ZI段（未初始化全局变量）在SRAM中清零：int g_buf[100];这种没有显式初值的变量，需要全部置零。
3. 初始化栈和堆：设置MSP，初始化堆管理器（如果用了malloc）。

这三步做完，C运行时环境才算建立起来，然后__main才会调用我们写的main()。

4.2 链接脚本与内存布局

RW段拷贝和ZI段清零的地址范围，是由链接脚本（.sct文件或.ld文件）决定的。以Keil的分散加载文件为例：

LR_IROM1 0x08000000 0x00010000 { ER_IROM1 0x08000000 0x00010000 { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00005000 { .ANY (+RW +ZI) } }

这里RESET段被强制放在最前面，确保向量表位于Flash起始位置。RW_IRAM1定义了SRAM的起始地址和大小，RW和ZI数据都分配在这个区域。

如果链接脚本写错了，比如SRAM大小超过了实际芯片容量，编译能过但运行会出问题——变量被分配到不存在的地址，读写时触发HardFault。这种问题在换芯片型号时特别常见。

4.3 启动文件里的栈和堆配置

启动文件开头通常有这两行：

Stack_Size EQU 0x00000400 Heap_Size EQU 0x00000200

Stack_Size是栈大小，默认1KB。这个值在裸机程序里通常够用，但如果用了RTOS、开了递归、或者有大型局部数组，1KB很容易溢出。栈溢出不会报错，只会默默覆盖相邻内存，导致各种诡异问题。

Heap_Size是堆大小，只有用malloc时才需要关注。嵌入式项目里我一般建议尽量不用动态内存，如果非用不可，堆大小要留足余量，并且做好分配失败的处理。

实操心得：栈溢出是嵌入式最难排查的问题之一。我的习惯是在栈顶和栈底各放一个魔术字（比如0xDEADBEEF），定期检查魔术字是否被改写，能提前发现溢出趋势。

5. 从main()到RTOS启动：裸机与操作系统的分界

5.1 裸机程序的main()结构

如果没有RTOS，main()的结构通常很直接：

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); while (1) { // 业务逻辑 } }

初始化外设，然后进死循环。这种结构简单可靠，适合功能单一的场景。但一旦业务变复杂，多个任务需要"同时"运行，裸机的前后台架构就会力不从心——一个延时函数就能把整个系统卡住。

5.2 uC/OS-II的启动流程

引入uC/OS-II后，main()的结构变成：

int main(void) { BSP_Init(); OSInit(); OSTaskCreate(Task1, ...); OSTaskCreate(Task2, ...); OSStart(); return 0; }

OSInit()初始化内核数据结构，OSTaskCreate()创建任务，OSStart()启动调度器。OSStart()会找到优先级最高的就绪任务，然后切换到它的上下文开始执行。从这一刻起，程序就不再是顺序执行了，而是由调度器接管。

这里有个关键点：OSStart()之后代码永远不会返回。如果它返回了，说明系统出了问题。

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

OSStart()内部会调用OSStartHighRdy()，这是一个汇编函数，负责：

1. 设置PendSV优先级为最低
2. 从最高优先级任务的TCB中取出栈指针
3. 恢复该任务的CPU寄存器
4. 执行异常返回，跳转到任务入口

任务入口通常是这样的：

void Task1(void *p_arg) { while (1) { // 任务代码 OSTimeDly(100); } }

注意任务函数必须是死循环，不能返回。如果返回了，uC/OS-II会调用OSTaskReturnHook()，通常直接进入错误处理。

6. PendSV与任务切换：RTOS的心跳

6.1 为什么用PendSV做上下文切换

Cortex-M有三个系统异常：SVC、PendSV、SysTick。uC/OS-II用PendSV做任务切换，这是有讲究的。

PendSV的特点是可挂起——可以把它设置为"pending"状态，等CPU处理完更高优先级的异常后再执行。这样设计的好处是：任务切换不会打断中断服务程序。如果把切换逻辑放在SysTick里直接执行，可能会在中断嵌套时出问题。

具体做法是把PendSV优先级设为最低（0xFF），这样任何中断都能抢占它。当SysTick触发时，只做计数和设置PendSV挂起位，真正的切换延迟到所有中断处理完之后。

6.2 PendSV_Handler的汇编实现

PendSV_Handler是任务切换的核心，典型实现如下：

PendSV_Handler MRS R0, PSP ; 获取当前任务的栈指针 CBZ R0, PendSV_NoSave ; 如果是第一次，跳过保存 STMDB R0!, {R4-R11} ; 保存R4-R11 LDR R1, =OSTCBCur ; 获取当前TCB指针 LDR R1, [R1] STR R0, [R1] ; 更新TCB中的栈指针 PendSV_NoSave PUSH {LR} BL OSTaskSwHook ; 调用钩子函数 LDR R0, =OSTCBCur LDR R1, =OSTCBHighRdy LDR R2, [R1] STR R2, [R0] ; 切换当前TCB LDR R0, [R2] ; 获取新任务的栈指针 LDMIA R0!, {R4-R11} ; 恢复R4-R11 MSR PSP, R0 ; 更新PSP POP {LR} ORR LR, LR, #0x04 ; 确保返回后使用PSP BX LR

这段代码的关键在于：R4-R11需要手动保存，R0-R3、R12、LR、PC、xPSR由硬件自动保存。这是ARM架构的约定，硬件在异常入口自动压栈一部分寄存器，软件负责剩下的。

6.3 任务切换的完整时序

把整个切换过程串起来看：

1. SysTick中断触发，SysTick_Handler调用OSTimeTick()
2. OSTimeTick()递减延时计数，如果有任务延时到期，调用OS_Sched()
3. OS_Sched()找到最高优先级就绪任务，设置PendSV挂起位
4. SysTick中断返回，CPU检查到PendSV挂起
5. 执行PendSV_Handler，保存当前任务上下文，恢复新任务上下文
6. 异常返回，新任务开始执行

整个过程对用户任务是透明的，任务感觉自己一直在独占CPU。

7. 常见问题与排查技巧

7.1 程序下载后不运行

这是最高频的问题，排查顺序如下：

我遇到最多的是BOOT引脚问题，其次是链接脚本里SRAM大小写错。这两个问题都不难查，但不知道方向的话会浪费很多时间。

7.2 中断进不去

中断进不去的常见原因：

• 向量表地址不对：检查SCB->VTOR是否指向正确的向量表
• 中断优先级配置错误：NVIC优先级分组和抢占优先级设置不匹配
• 中断使能位没开：外设的中断使能位和NVIC的使能位都要设置
• 全局中断被关：检查是否在临界区里没出来

注意：uC/OS-II的临界区通过OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()成对使用，如果某处只进不出，全局中断会一直关闭，所有中断都进不来。

7.3 RTOS任务切换异常

任务切换异常通常表现为：任务跑飞、HardFault、或者某个任务永远不执行。排查思路：

1. 检查任务栈大小：每个任务的栈是独立的，栈太小会溢出。uC/OS-II可以用OSTaskStkChk()检查栈使用情况。
2. 检查PendSV优先级：必须设为最低，否则会打断其他中断。
3. 检查任务优先级：uC/OS-II不支持同优先级任务，优先级必须唯一。
4. 检查临界区：临界区内不能调用可能引起调度的函数。

7.4 全局变量初值不对

如果全局变量的初值不是代码里写的值，大概率是RW段拷贝出了问题。检查方向：

• 链接脚本里RW段的目标地址是否正确
• Flash和SRAM的地址范围是否匹配芯片实际容量
• 是否在启动文件中意外修改了__main的调用

这种问题在换芯片型号、改链接脚本后特别容易出现。

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

8.1 复位后外设时钟默认关闭

STM32复位后，除了SRAM和Flash，几乎所有外设的时钟都是关闭的。这意味着在main()里直接操作GPIO寄存器是无效的，必须先使能对应外设的时钟。这个设计是为了省电，但初学者经常忘记。

8.2 中断向量表的弱定义

启动文件里所有中断处理函数都是WEAK定义的，意思是"弱符号"。如果你在C文件里定义了同名函数，链接器会用你的版本覆盖启动文件里的。如果没定义，就用启动文件里的默认版本——通常是个死循环。

这个机制的好处是：不需要的中断不用写处理函数，不会报错。坏处是：如果中断处理函数名拼错了，链接器不会报错，中断触发后会跳进默认的死循环，表现为"程序卡死"。

8.3 SystemInit的调用时机

SystemInit在__main之前被调用，此时RW段还没拷贝，ZI段还没清零。所以SystemInit里不能使用全局变量，也不能假设全局变量有正确的初值。这个限制在写启动代码时要特别注意。

8.4 启动时间的优化

如果项目对启动时间有要求，可以从几个方面优化：

• 减少SystemInit里的等待循环（比如PLL锁定等待）
• 把非必要的外设初始化延后到任务里执行
• 使用更快的时钟源启动
• 减少RW段的数据量（少用带初值的全局变量）

我做过一个项目，启动时间从200ms优化到50ms，主要就是把外设初始化从main()开头挪到了各个任务里按需初始化。

9. 从启动流程看系统设计

把整个启动流程走一遍，会发现STM32的设计思路很清晰：硬件负责最基础的向量表映射和栈指针设置，启动文件负责时钟和内存初始化，C库负责运行时环境建立，应用代码负责业务逻辑。每一层职责明确，互不越界。

理解这个分层结构，对排查问题很有帮助。比如程序跑飞了，可以先判断是启动阶段的问题还是运行阶段的问题；中断异常了，可以先确认向量表是否正确；RTOS调度异常了，可以先检查PendSV和SysTick的配置。

我个人在实际项目中的体会是：启动流程这部分代码，平时可能几个月都不看一眼，但一旦出问题，往往是最难查的。花时间把这几百行汇编和启动代码搞清楚，性价比非常高。后面再遇到"程序下载后不跑"、"中断进不去"、"任务切换死机"这类问题，排查起来会快很多。

最后分享一个小技巧：如果怀疑是启动阶段的问题，可以在Reset_Handler的第一条指令处设断点，单步跟踪到main()，看每一步是否按预期执行。这个方法虽然笨，但非常有效，能定位到具体是哪一步出了问题。