1. 上电那一瞬间，芯片里到底在忙什么
很多人写STM32代码，习惯性地从main()函数第一行开始看，觉得程序就是从那里跑起来的。但如果你真的拿调试器单步跟过复位后的执行流，就会发现main()之前其实已经跑了一大段"看不见的代码"——这段代码决定了你的栈指针从哪来、中断向量表放在哪、.data段怎么从Flash搬到RAM、.bss段怎么清零。搞不清楚这段流程，遇到"程序下载进去不跑""进不了main""HardFault一上电就触发"这类问题，就只能靠猜。
这篇内容就是想把STM32从上电复位到第一个任务跑起来这条链路完整拆一遍。核心关键词是复位向量、启动流程、uC/OS-II、PendSV，但我会把Cortex-M内核的复位行为、启动文件的汇编逻辑、链接脚本的段布局、以及RTOS启动第一个任务时PendSV干了什么，全部串起来讲。适合已经能点亮LED、但想搞清楚"底层到底发生了什么"的嵌入式开发者，也适合正在准备面试或者做毕业设计、需要把启动流程讲明白的同学。
我不会只贴一段启动文件就完事，而是按"硬件复位→取向量→执行启动代码→跳main→RTOS接管→PendSV切换第一个任务"这个真实顺序，把每一步的意图、参数、易错点都摊开。中间会穿插我自己踩过的坑，比如向量表偏移没设导致中断跑飞、栈顶地址写错导致一上电就HardFault、PendSV优先级配错导致任务切换卡死这些。看完你应该能对着自己的工程，把这条链路一步步复现出来。
2. 复位不是"从头开始"，而是内核的一次强制约定
2.1 Cortex-M的复位行为：硬件替你做了三件事
先明确一个概念：STM32的复位流程，一半是ARM Cortex-M内核规定的，一半是ST在芯片层面实现的。内核规定的是"复位后必须做什么"，ST决定的是"复位向量表放在哪、启动模式怎么选"。
Cortex-M内核在复位时，硬件自动完成三件关键事情：
第一，从地址0x00000000处读取初始主栈指针（MSP）的值，加载到SP寄存器。注意，这里读的是"向量表的第0个32位字"，不是代码。第二，从地址0x00000004处读取复位向量，也就是复位处理函数的入口地址，加载到PC寄存器。第三，把LR设置为0xFFFFFFFF，表示当前处于线程模式、使用MSP，并且是从复位异常返回的状态。
这三件事是硬件行为，不需要你写任何代码。所以你在调试器里刚attach上去、还没执行任何指令时，SP和PC就已经有值了。如果你看到SP是个乱七八糟的值，那基本可以断定向量表的前4个字节被写坏了，或者启动模式选错了导致映射的地址不对。
提示：很多人以为复位后PC指向
main，其实不是。PC指向的是Reset_Handler，这是启动文件里定义的汇编函数，main是它最后调用的。
2.2 向量表第0项为什么是栈顶而不是函数地址
这是初学者最容易困惑的点：为什么向量表第一个字放的是栈指针，而不是某个函数地址？
原因在于Cortex-M的设计哲学——它没有独立的"设置栈指针"指令，复位后必须立刻有一个可用的栈，否则连异常处理都没法压栈。所以ARM干脆把"初始SP值"也当成向量表的一项，由硬件在取复位向量的同时把SP也加载好。这样从复位向量开始执行的第一条指令起，栈就是可用的。
这也解释了一个经典问题：为什么栈顶地址通常写成RAM末尾的地址（比如0x20020000）？因为Cortex-M的栈是满递减栈，SP指向最后一个入栈元素，栈从高地址往低地址生长。把初始SP设在RAM最高地址，栈就有最大的生长空间。如果你把栈顶设成RAM起始地址，第一次压栈就会往下越界，直接HardFault。
2.3 启动模式与地址映射：0x00000000到底映射到哪
STM32有个"启动模式"的概念，通过BOOT0/BOOT1引脚决定。但要注意，Cortex-M看到的永远是0x00000000这个地址，至于这个地址物理上映射到Flash、系统存储器还是SRAM，是芯片内部的重映射逻辑决定的。
以常见的STM32F1为例，主Flash启动时，0x00000000被映射到0x08000000（Flash起始）。所以你编译出来的向量表虽然链接在0x08000000，但内核复位时从0x00000000读，读到的其实是同一块内容。这个"别名映射"机制是理解启动流程的关键，也是为什么你在链接脚本里看到Flash起始是0x08000000，但复位却能正常工作的原因。
| 启动模式 | BOOT0 | BOOT1 | 0x00000000映射到 | 典型用途 |
|---|---|---|---|---|
| 主Flash | 0 | X | 0x08000000 | 正常运行 |
| 系统存储器 | 1 | 0 | 系统Bootloader | 串口下载 |
| 内嵌SRAM | 1 | 1 | 0x20000000 | 调试特殊场景 |
这里有个实操心得：如果你用调试器下载程序后，发现必须按一下复位才能跑，或者干脆不跑，先检查BOOT引脚。我遇到过好几次，板子上的BOOT0被误拉高，程序下载进Flash了但芯片从系统存储器启动，跑的是出厂Bootloader，当然不进你的main。
3. 启动文件里的汇编，每一行都在为C环境铺路
3.1 Reset_Handler的三段式结构
打开startup_stm32f10x_md.s这类启动文件，你会看到Reset_Handler大概长这样：
Reset_Handler: LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0看起来很简单，但背后藏着三段逻辑。第一段是调用SystemInit，这是ST提供的C函数，负责配置时钟树（把HSE打开、PLL倍频、切换系统时钟源）、设置向量表偏移（SCB->VTOR）。第二段是跳转到__main，注意这不是你写的main，而是C库的入口。第三段由C库完成，它负责把.data段从Flash拷贝到RAM、把.bss段清零、初始化堆，最后才调用你写的main。
很多人以为main是启动文件直接调的，其实中间隔了一个C库的__main。这个区别在排查"全局变量初值不对"时特别有用——如果你的.data段拷贝出了问题，main里看到的全局变量就是错的。
3.2 SystemInit里最容易被忽略的一行：VTOR设置
SystemInit里有一行代码经常被忽视：
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;这行代码设置的是向量表偏移寄存器。默认情况下，Cortex-M从0x00000000取向量，但如果你用了Bootloader+App的分区方案，App的向量表在Flash里是偏移的（比如偏移0x8000），这时候就必须把VTOR设成0x08008000，否则中断触发时内核还去0x00000000找中断服务函数，找到的是Bootloader的向量表，直接跑飞。
我踩过的坑：做IAP升级时，App里忘了改VTOR，结果串口中断一进来就HardFault。查了半天以为是串口配置问题，最后发现是向量表没偏移。这个坑的隐蔽性在于，主程序能正常跑，只有中断出问题，很容易误判。
3.3 链接脚本如何决定段的布局
启动文件里的__main之所以知道要把.data从哪搬到哪，是因为链接脚本（.ld文件）定义了段的加载地址和运行地址。以GCC的链接脚本为例：
_estack = 0x20020000; MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K } SECTIONS { .text : { *(.isr_vector) *(.text*) } > FLASH .data : { *(.data*) } > RAM AT> FLASH .bss : { *(.bss*) } > RAM }关键在.data : { } > RAM AT> FLASH这一行。它告诉链接器：.data段的运行地址在RAM，但加载地址（初始值存放处）在Flash。启动代码就是根据这个"加载地址"和"运行地址"的差值，把数据从Flash搬到RAM。.bss段没有AT>，因为它不需要初始值，启动代码只负责把它清零。
理解这一点，你就能解释为什么增大全局数组会导致Flash占用增加——因为.data段的初始值要存在Flash里。而如果数组是未初始化的（放.bss），就不占Flash。
4. 从main到RTOS：多任务环境是怎么接管的
4.1 裸机main和RTOS main的本质区别
裸机程序里，main通常是一个while(1)大循环，所有逻辑顺序执行。而用了uC/OS-II之后，main的主要工作是初始化硬件、创建任务、启动调度器，然后OSStart()一调用，就再也不会回到main了。
int main(void) { BSP_Init(); OSInit(); OSTaskCreate(Task1, ..., PRIO_TASK1); OSTaskCreate(Task2, ..., PRIO_TASK2); OSStart(); return 0; }OSStart()之后，控制权交给RTOS。RTOS要做的第一件事是找到优先级最高的就绪任务，然后切换到它的上下文。这个"切换"在Cortex-M上，核心就是PendSV异常。
4.2 PendSV为什么是任务切换的最佳载体
Cortex-M有三个系统异常：SysTick、SVC、PendSV。为什么uC/OS-II和FreeRTOS都选PendSV做任务切换，而不是SVC或者直接在SysTick里切？
原因有三。第一，PendSV的优先级可以设成最低。这样它不会打断其他中断，所有中断处理完后才执行切换，保证了中断的实时性。第二，PendSV是"可挂起"的，你可以通过写ICSR寄存器把它挂起，等内核空闲时自动执行，不需要立即切换。第三，SVC是同步异常，用于系统调用，如果在SVC里做切换，会限制调用场景。
配置PendSV优先级的代码通常长这样：
NVIC_SetPriority(PendSV_IRQn, 0xFF); NVIC_SetPriority(SysTick_IRQn, 0x00);把PendSV设成最低优先级（数值最大），SysTick设成较高优先级。这样SysTick触发时，如果发现有更高优先级任务就绪，就挂起PendSV，等当前中断退出后，PendSV才执行真正的上下文切换。
注意：如果你把PendSV优先级设得比某个中断还高，那个中断里如果调用了RTOS API导致切换，就可能出现优先级反转或者栈错乱。这是RTOS移植时最常见的配置错误之一。
4.3 第一个任务是怎么"跳"进去的
OSStart()最终会调用一个汇编函数（uC/OS-II里叫OSStartHighRdy），它的逻辑是：找到最高优先级任务的TCB，从TCB里恢复SP，然后触发一次PendSV（或者直接手动出栈），让内核从任务栈里恢复寄存器，PC就被设成任务的入口地址。
具体来说，任务创建时，RTOS会在任务的栈里伪造一个"异常压栈帧"，把R0-R3、R12、LR、PC、xPSR都填好，其中PC填的是任务函数地址。当PendSV处理程序执行出栈操作时，硬件自动从栈里恢复这些寄存器，PC一恢复，CPU就跳到了任务函数。这就是"第一个任务启动"的本质——不是call进去的，而是通过异常返回"骗"进去的。
这个机制解释了为什么任务函数不能有返回值，也解释了为什么任务栈大小要算准——伪造的栈帧加上任务自己的局部变量，都在这块栈里。
5. 那些让启动流程翻车的典型场景
5.1 一上电就HardFault：先查栈顶和向量表
上电即HardFault，九成是这两个原因之一：初始SP值非法，或者复位向量指向了非法地址。
排查方法：用调试器连上，复位后立刻暂停，看SP和PC的值。SP应该在RAM范围内（比如0x20000000到0x20020000之间），PC应该指向Flash里的Reset_Handler。如果SP是0xFFFFFFFF或者0，说明向量表前4字节没写对，检查链接脚本里_estack的定义，以及启动文件里向量表是不是放在了.isr_vector段的最前面。
如果PC指向了奇怪的地方，检查启动文件里的向量表定义有没有被编译器优化掉，或者SCB->VTOR被设成了错误的值。
5.2 中断进不去：VTOR和优先级分组
中断进不去，但主程序正常，优先查VTOR。尤其是用了Bootloader或者把程序烧到了非默认地址的场景。另一个常见原因是优先级分组没设对，NVIC_PriorityGroupConfig如果没调用或者调错了，抢占优先级和子优先级的位数分配就不对，可能导致中断被屏蔽。
我遇到过一次，中断服务函数写对了、使能了、VTOR也设了，就是不进。最后发现是__disable_irq()之后忘了__enable_irq()，全局中断被关了。这种低级错误在复杂工程里反而容易漏。
5.3 RTOS启动后任务不跑：PendSV和SysTick的优先级
RTOS启动后任务不切换，或者只有第一个任务跑，通常是PendSV或SysTick配置有问题。检查两点：PendSV优先级是不是最低，SysTick是不是正常触发。
如果SysTick中断没进，检查SysTick的重装载值是否合理（跟系统时钟匹配），以及SysTick中断有没有被使能。如果PendSV没触发，检查ICSR寄存器的PENDSVSET位有没有被写。
还有一个隐蔽的坑：在某些STM32型号上，如果用了低功耗模式，SysTick可能会停，导致RTOS调度器"睡着"。这时候需要改用其他定时器做系统节拍。
| 故障现象 | 最可能原因 | 排查手段 |
|---|---|---|
| 上电即HardFault | 初始SP非法/向量表错 | 复位后看SP、PC |
| 主程序跑但中断不进 | VTOR未设/全局中断关 | 查SCB->VTOR、PRIMASK |
| RTOS任务不切换 | PendSV优先级错 | 查NVIC优先级配置 |
| 第一个任务跑飞 | 任务栈伪造帧错 | 查任务栈大小和初始化 |
6. 把这条链路真正跑一遍的实操建议
如果你想把整个流程亲手验证一遍，我建议按这个顺序来。先建一个最小裸机工程，只点亮一个LED，用调试器单步跟Reset_Handler，看SP和PC怎么变，看SystemInit里时钟怎么配。然后手动在main之前插一个断点，观察.data段拷贝前后的内存变化。接着加一个串口中断，故意把VTOR改错，看HardFault怎么触发，再用调试器看SCB->CFSR寄存器定位是哪个异常。
最后移植一个最小RTOS（uC/OS-II或者FreeRTOS都行），只创建两个任务，一个闪灯一个串口打印。在PendSV处理函数里打断点，看每次切换时栈指针怎么变、任务栈里压了什么。这一步做完，你对"从复位向量到第一个任务"这条链路就不再是纸面上的理解，而是能对着寄存器和内存亲眼看到的过程。
我个人在实际项目里的体会是，启动流程这块知识，看十遍文档不如单步跟一遍。尤其是VTOR和PendSV这两个点，文档里讲得比较抽象，只有真正在调试器里看到向量表偏移前后的差异、看到PendSV触发时栈的切换，才能形成肌肉记忆。后面再遇到IAP升级、RTOS移植、低功耗唤醒这些场景，排查起来会快很多。
