1. 上电之后第一秒到底发生了什么做嵌入式开发这么久我带过不少刚入行的新人发现一个很有意思的现象大家写 STM32 程序都是打开 Keil、点一下编译、插上调试器、下载、运行灯亮了就欢呼灯不亮就怀疑人生。很少有人真正想过一个问题——芯片复位之后、main() 函数的第一行代码执行之前这中间的几百微秒到底发生了什么我为什么突然想聊这个因为之前有个项目Bootloader 跳转 APP 的时候偶尔会死机还有一个 RTOS 项目任务切换时发现了诡异的栈溢出问题。追根溯源两个问题最终都落到了对启动流程的理解不够透彻上。你如果不清楚复位向量是干什么的、启动文件是怎么一步步把控制权交给 main 的、RTOS 调度器又是怎么无中生有地把第一个任务送上 CPU 的那排查这类问题就只能靠运气。这篇文章我就把 STM32 上电启动的完整链路彻底拆开揉碎了讲一遍适合刚学 STM32 的初学者建立整体认知也适合做了几年开发但一直对启动流程一知半解的老同学查漏补缺。1.1 复位向量到底在哪一张上电后的第一份地图先说一个最基础但很多人理解有偏差的概念复位向量Reset Vector。ARM Cortex-M 内核有一条硬性规定芯片上电复位后CPU 会从地址 0x00000000读取一个 32 位数据作为主栈指针MSP的初始值再从地址 0x00000004读取一个 32 位数据作为复位后第一条指令的地址然后跳过去执行。地址 0x00000004 里存的那个值就是复位向量的本质——它不是一个跳转指令而是一个地址值。这跟传统的 51 单片机不一样51 是复位后直接跳到 0x0000 地址去执行。Cortex-M 的这套设计把栈在哪、程序从哪开始两个信息固化在固定地址上CPU 不需要任何外部配置就能拉起运行环境。这里有个重要的细节我们烧录程序时代码一般放在 0x08000000Flash 起始地址。但 CPU 上电后找的是 0x00000000那它是怎么找到我们的代码的答案藏在 STM32 的存储映射里。STM32 内部有一个别名映射机制芯片根据 BOOT 引脚的电平状态决定把哪一块物理存储器的地址映射到 0x00000000 这个零地址区BOOT0BOOT1启动介质映射到 0x00000000 的物理空间0任意主 Flash0x0800000010系统存储器Bootloader0x1FFF000011内嵌 SRAM0x20000000绝大多数正常开发场景都是 BOOT0 拉低也就是从主 Flash 启动。这时 CPU 虽然访问的是 0x00000000但实际读到的是 0x08000000 处的内容。我们调试时看到的程序入口地址 0x08000000 也不难理解了。1.2 向量表一个排好队的中断地址簿复位向量不是孤零零存在的它只是整个**中断向量表Vector Table**的第一个有效成员。向量表说白了就是一张存放着各类函数地址的表位置最靠前的两个特殊成员初始栈指针、复位向量后面的成员各类异常和中断的服务函数入口地址比如 NMI、HardFault、SVC、PendSV、SysTick以及芯片外设的中断EXTI、TIM、UART、I2C 等Cortex-M 内核规定向量表的偏移必须是 2 的整数次幂通常按 128 字节对齐因为 VTOR 寄存器向量表偏移寄存器的低位会被忽略。在 STM32 的正点原子或标准库工程里你可以打开startup_stm32f10x_hd.s文件开头就是一大串 DCD 伪指令把各个中断服务函数地址按顺序排好。系统复位后CPU 会从 0x00000000经过映射后是 0x08000000读取第一个字给 MSP然后从 0x08000004 读取复位向量并跳转执行。这里我还想强调一个非常关键的进阶点向量表的位置并不总是固定在 Flash 开头。当你做 Bootloader APP 的架构时APP 可能被放在 0x08010000 等偏移地址。此时如果不修改 VTOR 寄存器中断一来 CPU 仍然会去 Flash 开头找中断服务函数地址结果找到的全是 Bootloader 里的函数或者压根不对程序直接跑飞。这就是很多 Bootloader 跳转后中断不响应的根本原因。解决办法是 APP 启动早期执行SCB-VTOR APP_BASE_ADDRESS来重定向向量表。这个细节后面讲 Bootloader 跳转时还会再提。1.3 BOOT 引脚与启动介质别在硬件上栽跟头BOOT 引脚的配置在开发调试期容易被忽略但产品量产阶段它就是个坑。我记得有个同事做一款手持设备样机调试时一切正常量产烧录完程序贴上外壳后居然出现一批设备上电没反应。折腾了半天发现是产线测试时有人把 BOOT0 跳线帽插到了 1 的位置芯片每次上电都进系统存储器自带的 Bootloader应用程序根本没跑起来。这个问题的本质就是启动介质选择。BOOT01、BOOT10 时芯片映射的是系统存储器里面是芯片出厂预烧录的 Bootloader它主要用于串口下载程序不会主动跳转执行用户 Flash 里的代码。实操建议产品设计时尽量不要把 BOOT0/BOOT1 引脚裸露给用户或者默认焊接 10k 下拉电阻拉低避免悬空导致启动介质不稳定。在产品中需要支持 IAPIn-Application Programming升级时才通过代码或按键组合把 BOOT0 拉高进入系统 Bootloader完成后必须确认切回主 Flash。调试阶段如果发现程序跑起来了但不受控制第一步检查 BOOT 引脚第二步才去怀疑固件。2. 启动文件一颗螺丝钉都不能少确认了复位向量、启动介质之后CPU 跳到了复位向量指向的位置也就是启动文件里的Reset_Handler函数。以 STM32F103 的启动文件为例这部分代码可以说是整个启动流程里的总导演。2.1 startup 文件里都有什么启动文件startup_stm32f10x_hd.s的典型内容可以分成这几块栈Stack空间定义堆Heap空间定义中断向量表Reset_Handler 汇编函数异常与中断服务函数的弱定义Weak Definition栈的定义很简单Stack_Size EQU 0x400 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_spEQU 0x400表示栈大小为 1KB。有人觉得 1KB 太小直接改成 0x1000也没问题但你要清楚这个改动对内存布局的影响——栈空间是分配在 SRAM 里的栈加大堆或全局变量的可用空间就变小。我在做多线程任务时尤其注意栈大小任务栈和主栈是两回事启动文件里定义的是主栈MSP 使用的栈RTOS 里每个任务有自己的栈这些后面详谈。中断向量表在启动文件里长这样截取部分__Vectors DCD __initial_sp ; Top of Stack DCD Reset_Handler ; Reset Handler DCD NMI_Handler ; NMI Handler DCD HardFault_Handler ; Hard Fault Handler DCD MemManage_Handler ; MPU Fault Handler DCD BusFault_Handler ; Bus Fault Handler DCD UsageFault_Handler ; Usage Fault Handler ...注意第一个 DCD 后面的值是__initial_sp它就是栈顶地址。这再次印证了前面的结论芯片上电会从 0x08000000 读到的第一个值就是栈顶第二个值才是 Reset_Handler 的地址。启动文件末尾还用ALIGN、END等伪指令保证向量表对齐到合理边界。这块内容大多数人不需要手动改但具备阅读能力非常重要。2.2 Reset_Handler 的日常工作清单Reset_Handler 的汇编实现标准库版本一般是这样的Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT __main LDR R0, SystemInit BLX R0 LDR R0, __main BX R0 ENDP不要被这段汇编吓到它只干三件事把 SystemInit 函数的地址装载到 R0然后调用它。SystemInit 是芯片厂商提供的系统初始化函数主要完成配置 Flash 预取缓冲、设置时钟树PLL、分频器等、使能外设总线时钟。你会发现 SystemInit 里通常会做一套默认时钟配置比如 F103 把系统时钟从 8MHz HSI 切换到 72MHz PLL。如果你在工程里想自定义时钟可以改 SystemInit 或在自己的代码里重配但顺序上它必须在 main 之前先跑完否则后面的代码拿到的时钟是默认低速状态。把 __main 的地址装载到 R0然后跳过去。这里注意__main 不是我们写的 main()而是 C 库的入口函数。它负责建立 C 运行环境。很多人以为 Reset_Handler 之后直接进 main其实中间隔了一道 C 库初始化工序。结束 Reset_Handler。后面就是 C 的世界了。我之前调试过一个诡异 bug串口发送的数据开头总是多一个字节的乱码最终定位到是 SystemInit 里的时钟切换配置没生效导致 UART 波特率分频算错了。如果当时对启动流程的调用顺序有清晰的认知可能更快联想到 SystemInit 这一环。2.3 __main 到 mainC 运行环境的幕后搭建__main 是 ARM C 库提供的入口它内部会做这样几件事拷贝 RW 段把初始值非零的全局变量RW data从 Flash 拷贝到 SRAM。清零 ZI 段把初始值为零的全局变量区域ZI dataBSS 段清零。初始化堆为 malloc 等动态内存函数准备好堆空间。调用 main()。这就像你要在一张白纸上画画之前得先把桌子擦干净、把画笔摆放整齐。没有 __main 的这层收拾你的全局变量初始值可能全是乱码malloc 也必然失败。Keil 工程里你可以在__main的汇编处打断点然后单步走会依次看到__scatterload装载段拷贝、__rt_entry运行时入口等步骤。强烈建议初学者做一次这个操作比看十遍文档都管用。这里还有一个容易被忽略的坑C 库的底层函数如 printf 重定向、heap 大小与启动文件里的堆定义关系密切。如果你在代码里大量使用 malloc 而不注意 Heap 大小可能在某个特殊内存分配场景下直接返回 NULL 指针。传统上大家会把堆加大一点但更推荐的思路是尽量使用静态分配嵌入式环境里动态内存的碎片风险和不确定性太高。3. 从 main() 到第一个任务RTOS 是怎么凭空变出任务的如果你只是裸机开发到 main() 就算完成了启动流程。但实际项目中越来越多的工程师会引入 RTOSFreeRTOS、RT-Thread、UCOS 等。那么问题来了main() 里调用了 vTaskStartScheduler() 之后第一个任务是怎么被欺骗成它一直在运行、然后被切换走的这里面的核心机制涉及三兄弟SVC、PendSV、SysTick。它们仨在中断向量表里的位置紧挨着在调度器里却各司其职。3.1 裸机 main()一个无限循环的世界裸机开发无非是初始化硬件、初始化变量、while(1) 里做轮询或中断处理。main() 之后就没有所谓的启动流程了CPU 永远在循环里跑。如果你是裸机开发者理解到上一节的内容已经足够。但一旦引入 RTOSmain() 的角色就变成了系统的孵化器它要做的事情多了起来初始化堆、创建任务、创建队列/信号量、然后启动调度器。调度器启动之后main() 通常就不再作为一个普通函数返回了它被调度器吸收了。3.2 vTaskStartScheduler 如何骗出第一个任务以 FreeRTOS 为例vTaskStartScheduler()内部干了一连串事情后会调用SVC 0指令或在新版本中使用svc 0汇编指令触发一个 SVC 异常。SVCSupervisor Call是一个请求内核服务的软中断。为什么要通过 SVC 来启动因为调度器需要从线程模式切换到特权模式SVC 异常正好能完成一次特权的提升还能趁机做上下文切换的初始化工作。关键的原理在pxPortInitialiseStack()函数它会给每个任务伪造一个刚开始运行的寄存器现场包括 xPSR、PC指向任务函数地址、LR、R0-R12 等。这些值被压入任务自己的栈中看起来就像是这个任务刚刚被一个中断打断才压栈保存了现场。然后当 SVC 异常处理函数vPortSVCHandler执行时它会获取当前要运行的任务的栈指针从pxCurrentTCB里拿任务栈顶。把这个栈顶指针加载到 PSP进程栈指针。从任务栈里弹出所有伪造的寄存器值。执行异常返回PC 直接跳转到了任务函数。任务函数的第一行代码就这样被凭空执行起来了。用一句话总结就是调度器把第一个任务伪装成了一个被中断打断过、现在恢复现场的任务。这种设计非常巧妙因为它让后续所有的任务切换都能用同一个机制——中断触发 现场保存/恢复。3.3 PendSV 与 SysTick调度器的左右手有了第一个任务之后下一个问题就是怎么切换任务SysTick提供系统节拍相当于一个周期性闹钟。每个 tick 到来时内核知道该看看要不要调度了。在时间片轮转调度里多个同优先级任务靠 tick 轮换。PendSV可挂起的系统调用是真正的任务切换执行者。它有个特性——可以设置为最低优先级并且等待其他中断处理完再执行。这样当 UART 中断正在处理时PendSV 不会打断它避免了上下文切换与中断服务函数之间的资源竞争。调度器流程大致是SysTick 触发 - 内核判断是否需要切换 - 需要则置位 PendSV - PendSV 处理函数里保存当前任务现场、切换 TCB、恢复下一个任务现场 - 异常返回新任务继续执行。这里我需要提醒一个常见误区很多人把任务栈的大小设置得刚刚好比如函数调用链非常深、用了比较大的局部数组结果一压栈就把栈底踩穿了。RTOS 的启动阶段和运行阶段一样都可能因为栈溢出引发 HardFault。后面我们会专门聊这个。3.4 从 Bootloader 跳转 APP 时的启动再造如果你做过带 Bootloader 的架构需要额外理解二次启动的概念。APP 的启动本质上也是从复位向量开始只是它的入口不是真正的上电复位而是 Bootloader 通过跳转指令主动切过去的。Bootloader 跳转 APP 之前的准备工作关闭全局中断等待所有中断处理完后清掉挂起的中断标志。把 APP 向量表地址写入 SCB-VTOR。重新设置 MSP__set_MSP(*(volatile uint32_t *)APP_ADDR)也就是读 APP 向量表的第一个字把主栈指针切到 APP 定义的栈顶。取出 APP 复位向量的地址(void *)(*(volatile uint32_t *)(APP_ADDR 4))然后函数指针跳转过去。这一步如果遗漏后果很典型APP 里跑起来了但调了中断就死机或者在跳转瞬间直接 HardFault。我自己踩过一个大坑Bootloader 跳转前没有把外设时钟重新配置APP 的 SystemInit 虽然会重设时钟但某个外设在上一个程序里被打开且继续跑着跳转后新程序对这个外设的状态完全不知情中断标志也没清结果 APP 起来后一开串口就进中断风暴。经验是Bootloader 要把用过的外设彻底 DeInit 一遍或者 APP 启动早期对所有外设做一次完整的复位配置。4. 启动阶段最常见的坑与排查实录这一节我整理了近几年大家问得最多、我也实际踩过的启动阶段问题希望能帮你在遇到类似情况时少走弯路。4.1 一上电就 HardFault定位三板斧HardFault 是 Cortex-M 最常见也最令人头疼的异常之一。很多人遇到 HardFault 就懵了其实定位方法非常固定第一板斧确定是哪个栈在起作用。看 LR链接寄存器的值LR 如果等于0xFFFFFFF9说明使用的是 MSP线程模式/主栈。LR 如果等于0xFFFFFFFD说明使用的是 PSP进程栈RTOS 环境常见。这个区分很重要因为 HardFault 现场的寄存器组保存在当前使用的栈里。如果是 PSP你需要把 PSP 指针带到 Keil 的 Watch 窗口里才能看到任务栈里的现场值。第二板斧看 PC 和 LR 是多少。这两个值指向的是发生异常时正在执行的指令地址和返回地址。把它们对应到编译出的 map 文件或反汇编文件基本能定位到是哪个函数炸了。第三板斧查 Fault 状态寄存器。在调试器的寄存器窗口里找CFSR可配置故障状态寄存器、HFSR硬故障状态寄存器、BFAR、MMFAR等能区分 Bus Fault、Usage Fault、MemManage Fault 的具体原因。比如CFSR里IBUSERR位置位说明取指令时访问了非法地址——很可能是函数指针跳错了位置。4.2 调试器连不上、程序反复复位这类问题常见于量产板。排查优先级我建议按这个顺序检查电源和复位电路NRST 引脚如果波形有抖动或异常低电平拉低芯片会一直在复位状态。检查 SWD 引脚是否被复用STM32 的 PA13/PA14 是 SWDIO/SWCLKPA15、PB3、PB4 是 JTAG 相关引脚。很多工程为了省引脚会把它们配置成普通 GPIO一旦烧录过这种程序重新连接调试器就会失败。低功耗模式误入代码里过早进入 STOP/STANDBY 模式导致 CPU 不响应调试请求。针对第 2 点有一个恢复手段使用 ST-Link Utility 的 Connect Under Reset 功能先让芯片停在复位状态再连接调试器然后擦除 Flash程序就恢复了。这也是我在量产阶段必教给产线工程师的技能。4.3 启动阶段问题排查速查表下面这张表适用于上电启动后完全不工作或行为异常的场景现象可能原因排查重点程序完全没跑BOOT 引脚配置错误BOOT0/BOOT1 电平程序没跑且电流异常电源电压不足/纹波过大万用表/示波器测 3.3V 与 NRST下载程序后无法连接调试器SWD/JTAG 引脚被复用Connect Under Reset 全擦除上电后系统时钟不对SystemInit 时钟配置失败检查外部晶振、PLL 参数main 之前 HardFault向量表错位 / 栈指针错误VTOR、__initial_sp 地址RTOS 第一个任务不运行SVC/PendSV 优先级配置错误配置 PendSV 为最低优先级跳 APP 后中断失效没有重定位向量表SCB-VTOR 设置变量初始值不对RW/ZI 段拷贝问题检查分散加载文件sct4.4 启动流程实战中容易被忽略的寄存器级细节很多教科书只会告诉你启动文件跳转到 main但实际工程里你会碰到更多硬件层面的坑。我分享几个自己调试中真实遇到过的细节第一个是做低功耗唤醒后的启动路径。STM32 从 STOP 模式唤醒后不会经过完整的 Reset_Handler 流程CPU 会继续执行唤醒点之后的代码但系统时钟可能已被硬件重置为默认的 HSI。很多工程师在这里踩坑任务恢复正常了但串口波特率全错就是因为你没有在唤醒代码里重新调用 SystemInit 或重新配置 PLL。更隐蔽的是 Standby 模式唤醒那是一次真正的复位但它走的是NRST 复位或唤醒复位路径和上电复位不完全等同。具体差异在各型号的参考手册里有张复位源表格值得翻一翻。第二个是 IWDG独立看门狗导致的循环复位。这类问题让人非常抓狂芯片刚启动看门狗就开始计时如果你在启动早期初始化 IWDG 后又恰好在设置超时参数前发生了某种阻塞比如等待 Flash 操作、等待外部器件应答IWDG 超时芯片复位然后又重复这个过程表现为永远卡在启动异常里。我用示波器测 NRST 引脚时会看到一系列规律的复位脉冲非常典型。解决思路很简单确认是否是看门狗复位通过RCC-CSR里的复位标志来区分然后在初始化流程里尽快喂狗或者设计上让看门狗在关键初始化完成之后再开启。第三个是 Flash 预取缓冲和指令延时WS配置。这是很多人完全忽略的启动细节。STM32 的 Flash 接口有一个等待状态寄存器FLASH_ACR它决定了 CPU 在访问 Flash 时插入几个等待周期。如果你主频较高却没有正确设置 WS 值Flash 读取时序就比 CPU 慢轻则程序偶尔跑飞重则启动后随机死机。SystemInit 里其实已经处理了这部分但如果你自己写了过早起频的代码或跳过了 SystemInit问题就会出现。之前有个项目把 SystemInit 精简掉、自己用寄存器配置时钟结果发现运行到某个耗时函数就会随机崩溃最后就是 WS 配置不对导致的。第四个是任务上下文切换时的栈对齐问题。ARM Cortex-M 内核要求栈指针在进入异常处理时保持 8 字节对齐AAPCS 调用约定。RTOS 创建任务栈时如果初始栈帧的地址没有按 8 字节对齐某些使用浮点或双字加载的代码就可能出错。古怪的是这类问题只在特定编译器优化级别下才暴露排查起来非常隐蔽。检查你的 RTOS 移植层里pxPortInitialiseStack对栈指针的处理以及在任务入口使用__ALIGN(8)等对齐宏是这类问题常见的解法。4.5 现场调试的三个小技巧最后分享几个我在实际调试启动流程时常用的技巧在 Reset_Handler 入口打断点。Keil 里进入 Debug 后自动停在 Reset_Handler这时候可以单步观察 SystemInit、__main 的调用过程。既能看到时序也能确认时钟配置是否生效。在 main() 开头观察全局变量。如果发现有变量初值不是预期值说明 RW/ZI 段初始化有问题回溯分散加载文件.sct或启动文件。用 RTT/串口打印启动阶段耗时。在 SystemInit 之前记录 SysTick 或 DWT 计数器值在 main 里再读一次能算出从复位到 main 的耗时。这个数据在做低功耗唤醒时间优化时非常有用。关于启动流程的完整理解我个人的体会是别把它当成IDE 自动生成的东西就跳过不看。启动文件虽然很多年都不需要改一次但一旦你的项目进入 Bootloader 开发、低功耗唤醒优化、或者 FreeRTOS/CubeMX 的深度定制阶段前面偷的懒都会在调试时加倍还回来。花一个下午把启动文件从头到尾通读一遍把断点打进每一段关键代码实际走一遍启动流程这个投入的回报远超你的预期。
STM32上电启动全解析：从复位向量到RTOS任务切换的完整链路
1. 上电之后第一秒到底发生了什么做嵌入式开发这么久我带过不少刚入行的新人发现一个很有意思的现象大家写 STM32 程序都是打开 Keil、点一下编译、插上调试器、下载、运行灯亮了就欢呼灯不亮就怀疑人生。很少有人真正想过一个问题——芯片复位之后、main() 函数的第一行代码执行之前这中间的几百微秒到底发生了什么我为什么突然想聊这个因为之前有个项目Bootloader 跳转 APP 的时候偶尔会死机还有一个 RTOS 项目任务切换时发现了诡异的栈溢出问题。追根溯源两个问题最终都落到了对启动流程的理解不够透彻上。你如果不清楚复位向量是干什么的、启动文件是怎么一步步把控制权交给 main 的、RTOS 调度器又是怎么无中生有地把第一个任务送上 CPU 的那排查这类问题就只能靠运气。这篇文章我就把 STM32 上电启动的完整链路彻底拆开揉碎了讲一遍适合刚学 STM32 的初学者建立整体认知也适合做了几年开发但一直对启动流程一知半解的老同学查漏补缺。1.1 复位向量到底在哪一张上电后的第一份地图先说一个最基础但很多人理解有偏差的概念复位向量Reset Vector。ARM Cortex-M 内核有一条硬性规定芯片上电复位后CPU 会从地址 0x00000000读取一个 32 位数据作为主栈指针MSP的初始值再从地址 0x00000004读取一个 32 位数据作为复位后第一条指令的地址然后跳过去执行。地址 0x00000004 里存的那个值就是复位向量的本质——它不是一个跳转指令而是一个地址值。这跟传统的 51 单片机不一样51 是复位后直接跳到 0x0000 地址去执行。Cortex-M 的这套设计把栈在哪、程序从哪开始两个信息固化在固定地址上CPU 不需要任何外部配置就能拉起运行环境。这里有个重要的细节我们烧录程序时代码一般放在 0x08000000Flash 起始地址。但 CPU 上电后找的是 0x00000000那它是怎么找到我们的代码的答案藏在 STM32 的存储映射里。STM32 内部有一个别名映射机制芯片根据 BOOT 引脚的电平状态决定把哪一块物理存储器的地址映射到 0x00000000 这个零地址区BOOT0BOOT1启动介质映射到 0x00000000 的物理空间0任意主 Flash0x0800000010系统存储器Bootloader0x1FFF000011内嵌 SRAM0x20000000绝大多数正常开发场景都是 BOOT0 拉低也就是从主 Flash 启动。这时 CPU 虽然访问的是 0x00000000但实际读到的是 0x08000000 处的内容。我们调试时看到的程序入口地址 0x08000000 也不难理解了。1.2 向量表一个排好队的中断地址簿复位向量不是孤零零存在的它只是整个**中断向量表Vector Table**的第一个有效成员。向量表说白了就是一张存放着各类函数地址的表位置最靠前的两个特殊成员初始栈指针、复位向量后面的成员各类异常和中断的服务函数入口地址比如 NMI、HardFault、SVC、PendSV、SysTick以及芯片外设的中断EXTI、TIM、UART、I2C 等Cortex-M 内核规定向量表的偏移必须是 2 的整数次幂通常按 128 字节对齐因为 VTOR 寄存器向量表偏移寄存器的低位会被忽略。在 STM32 的正点原子或标准库工程里你可以打开startup_stm32f10x_hd.s文件开头就是一大串 DCD 伪指令把各个中断服务函数地址按顺序排好。系统复位后CPU 会从 0x00000000经过映射后是 0x08000000读取第一个字给 MSP然后从 0x08000004 读取复位向量并跳转执行。这里我还想强调一个非常关键的进阶点向量表的位置并不总是固定在 Flash 开头。当你做 Bootloader APP 的架构时APP 可能被放在 0x08010000 等偏移地址。此时如果不修改 VTOR 寄存器中断一来 CPU 仍然会去 Flash 开头找中断服务函数地址结果找到的全是 Bootloader 里的函数或者压根不对程序直接跑飞。这就是很多 Bootloader 跳转后中断不响应的根本原因。解决办法是 APP 启动早期执行SCB-VTOR APP_BASE_ADDRESS来重定向向量表。这个细节后面讲 Bootloader 跳转时还会再提。1.3 BOOT 引脚与启动介质别在硬件上栽跟头BOOT 引脚的配置在开发调试期容易被忽略但产品量产阶段它就是个坑。我记得有个同事做一款手持设备样机调试时一切正常量产烧录完程序贴上外壳后居然出现一批设备上电没反应。折腾了半天发现是产线测试时有人把 BOOT0 跳线帽插到了 1 的位置芯片每次上电都进系统存储器自带的 Bootloader应用程序根本没跑起来。这个问题的本质就是启动介质选择。BOOT01、BOOT10 时芯片映射的是系统存储器里面是芯片出厂预烧录的 Bootloader它主要用于串口下载程序不会主动跳转执行用户 Flash 里的代码。实操建议产品设计时尽量不要把 BOOT0/BOOT1 引脚裸露给用户或者默认焊接 10k 下拉电阻拉低避免悬空导致启动介质不稳定。在产品中需要支持 IAPIn-Application Programming升级时才通过代码或按键组合把 BOOT0 拉高进入系统 Bootloader完成后必须确认切回主 Flash。调试阶段如果发现程序跑起来了但不受控制第一步检查 BOOT 引脚第二步才去怀疑固件。2. 启动文件一颗螺丝钉都不能少确认了复位向量、启动介质之后CPU 跳到了复位向量指向的位置也就是启动文件里的Reset_Handler函数。以 STM32F103 的启动文件为例这部分代码可以说是整个启动流程里的总导演。2.1 startup 文件里都有什么启动文件startup_stm32f10x_hd.s的典型内容可以分成这几块栈Stack空间定义堆Heap空间定义中断向量表Reset_Handler 汇编函数异常与中断服务函数的弱定义Weak Definition栈的定义很简单Stack_Size EQU 0x400 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_spEQU 0x400表示栈大小为 1KB。有人觉得 1KB 太小直接改成 0x1000也没问题但你要清楚这个改动对内存布局的影响——栈空间是分配在 SRAM 里的栈加大堆或全局变量的可用空间就变小。我在做多线程任务时尤其注意栈大小任务栈和主栈是两回事启动文件里定义的是主栈MSP 使用的栈RTOS 里每个任务有自己的栈这些后面详谈。中断向量表在启动文件里长这样截取部分__Vectors DCD __initial_sp ; Top of Stack DCD Reset_Handler ; Reset Handler DCD NMI_Handler ; NMI Handler DCD HardFault_Handler ; Hard Fault Handler DCD MemManage_Handler ; MPU Fault Handler DCD BusFault_Handler ; Bus Fault Handler DCD UsageFault_Handler ; Usage Fault Handler ...注意第一个 DCD 后面的值是__initial_sp它就是栈顶地址。这再次印证了前面的结论芯片上电会从 0x08000000 读到的第一个值就是栈顶第二个值才是 Reset_Handler 的地址。启动文件末尾还用ALIGN、END等伪指令保证向量表对齐到合理边界。这块内容大多数人不需要手动改但具备阅读能力非常重要。2.2 Reset_Handler 的日常工作清单Reset_Handler 的汇编实现标准库版本一般是这样的Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT __main LDR R0, SystemInit BLX R0 LDR R0, __main BX R0 ENDP不要被这段汇编吓到它只干三件事把 SystemInit 函数的地址装载到 R0然后调用它。SystemInit 是芯片厂商提供的系统初始化函数主要完成配置 Flash 预取缓冲、设置时钟树PLL、分频器等、使能外设总线时钟。你会发现 SystemInit 里通常会做一套默认时钟配置比如 F103 把系统时钟从 8MHz HSI 切换到 72MHz PLL。如果你在工程里想自定义时钟可以改 SystemInit 或在自己的代码里重配但顺序上它必须在 main 之前先跑完否则后面的代码拿到的时钟是默认低速状态。把 __main 的地址装载到 R0然后跳过去。这里注意__main 不是我们写的 main()而是 C 库的入口函数。它负责建立 C 运行环境。很多人以为 Reset_Handler 之后直接进 main其实中间隔了一道 C 库初始化工序。结束 Reset_Handler。后面就是 C 的世界了。我之前调试过一个诡异 bug串口发送的数据开头总是多一个字节的乱码最终定位到是 SystemInit 里的时钟切换配置没生效导致 UART 波特率分频算错了。如果当时对启动流程的调用顺序有清晰的认知可能更快联想到 SystemInit 这一环。2.3 __main 到 mainC 运行环境的幕后搭建__main 是 ARM C 库提供的入口它内部会做这样几件事拷贝 RW 段把初始值非零的全局变量RW data从 Flash 拷贝到 SRAM。清零 ZI 段把初始值为零的全局变量区域ZI dataBSS 段清零。初始化堆为 malloc 等动态内存函数准备好堆空间。调用 main()。这就像你要在一张白纸上画画之前得先把桌子擦干净、把画笔摆放整齐。没有 __main 的这层收拾你的全局变量初始值可能全是乱码malloc 也必然失败。Keil 工程里你可以在__main的汇编处打断点然后单步走会依次看到__scatterload装载段拷贝、__rt_entry运行时入口等步骤。强烈建议初学者做一次这个操作比看十遍文档都管用。这里还有一个容易被忽略的坑C 库的底层函数如 printf 重定向、heap 大小与启动文件里的堆定义关系密切。如果你在代码里大量使用 malloc 而不注意 Heap 大小可能在某个特殊内存分配场景下直接返回 NULL 指针。传统上大家会把堆加大一点但更推荐的思路是尽量使用静态分配嵌入式环境里动态内存的碎片风险和不确定性太高。3. 从 main() 到第一个任务RTOS 是怎么凭空变出任务的如果你只是裸机开发到 main() 就算完成了启动流程。但实际项目中越来越多的工程师会引入 RTOSFreeRTOS、RT-Thread、UCOS 等。那么问题来了main() 里调用了 vTaskStartScheduler() 之后第一个任务是怎么被欺骗成它一直在运行、然后被切换走的这里面的核心机制涉及三兄弟SVC、PendSV、SysTick。它们仨在中断向量表里的位置紧挨着在调度器里却各司其职。3.1 裸机 main()一个无限循环的世界裸机开发无非是初始化硬件、初始化变量、while(1) 里做轮询或中断处理。main() 之后就没有所谓的启动流程了CPU 永远在循环里跑。如果你是裸机开发者理解到上一节的内容已经足够。但一旦引入 RTOSmain() 的角色就变成了系统的孵化器它要做的事情多了起来初始化堆、创建任务、创建队列/信号量、然后启动调度器。调度器启动之后main() 通常就不再作为一个普通函数返回了它被调度器吸收了。3.2 vTaskStartScheduler 如何骗出第一个任务以 FreeRTOS 为例vTaskStartScheduler()内部干了一连串事情后会调用SVC 0指令或在新版本中使用svc 0汇编指令触发一个 SVC 异常。SVCSupervisor Call是一个请求内核服务的软中断。为什么要通过 SVC 来启动因为调度器需要从线程模式切换到特权模式SVC 异常正好能完成一次特权的提升还能趁机做上下文切换的初始化工作。关键的原理在pxPortInitialiseStack()函数它会给每个任务伪造一个刚开始运行的寄存器现场包括 xPSR、PC指向任务函数地址、LR、R0-R12 等。这些值被压入任务自己的栈中看起来就像是这个任务刚刚被一个中断打断才压栈保存了现场。然后当 SVC 异常处理函数vPortSVCHandler执行时它会获取当前要运行的任务的栈指针从pxCurrentTCB里拿任务栈顶。把这个栈顶指针加载到 PSP进程栈指针。从任务栈里弹出所有伪造的寄存器值。执行异常返回PC 直接跳转到了任务函数。任务函数的第一行代码就这样被凭空执行起来了。用一句话总结就是调度器把第一个任务伪装成了一个被中断打断过、现在恢复现场的任务。这种设计非常巧妙因为它让后续所有的任务切换都能用同一个机制——中断触发 现场保存/恢复。3.3 PendSV 与 SysTick调度器的左右手有了第一个任务之后下一个问题就是怎么切换任务SysTick提供系统节拍相当于一个周期性闹钟。每个 tick 到来时内核知道该看看要不要调度了。在时间片轮转调度里多个同优先级任务靠 tick 轮换。PendSV可挂起的系统调用是真正的任务切换执行者。它有个特性——可以设置为最低优先级并且等待其他中断处理完再执行。这样当 UART 中断正在处理时PendSV 不会打断它避免了上下文切换与中断服务函数之间的资源竞争。调度器流程大致是SysTick 触发 - 内核判断是否需要切换 - 需要则置位 PendSV - PendSV 处理函数里保存当前任务现场、切换 TCB、恢复下一个任务现场 - 异常返回新任务继续执行。这里我需要提醒一个常见误区很多人把任务栈的大小设置得刚刚好比如函数调用链非常深、用了比较大的局部数组结果一压栈就把栈底踩穿了。RTOS 的启动阶段和运行阶段一样都可能因为栈溢出引发 HardFault。后面我们会专门聊这个。3.4 从 Bootloader 跳转 APP 时的启动再造如果你做过带 Bootloader 的架构需要额外理解二次启动的概念。APP 的启动本质上也是从复位向量开始只是它的入口不是真正的上电复位而是 Bootloader 通过跳转指令主动切过去的。Bootloader 跳转 APP 之前的准备工作关闭全局中断等待所有中断处理完后清掉挂起的中断标志。把 APP 向量表地址写入 SCB-VTOR。重新设置 MSP__set_MSP(*(volatile uint32_t *)APP_ADDR)也就是读 APP 向量表的第一个字把主栈指针切到 APP 定义的栈顶。取出 APP 复位向量的地址(void *)(*(volatile uint32_t *)(APP_ADDR 4))然后函数指针跳转过去。这一步如果遗漏后果很典型APP 里跑起来了但调了中断就死机或者在跳转瞬间直接 HardFault。我自己踩过一个大坑Bootloader 跳转前没有把外设时钟重新配置APP 的 SystemInit 虽然会重设时钟但某个外设在上一个程序里被打开且继续跑着跳转后新程序对这个外设的状态完全不知情中断标志也没清结果 APP 起来后一开串口就进中断风暴。经验是Bootloader 要把用过的外设彻底 DeInit 一遍或者 APP 启动早期对所有外设做一次完整的复位配置。4. 启动阶段最常见的坑与排查实录这一节我整理了近几年大家问得最多、我也实际踩过的启动阶段问题希望能帮你在遇到类似情况时少走弯路。4.1 一上电就 HardFault定位三板斧HardFault 是 Cortex-M 最常见也最令人头疼的异常之一。很多人遇到 HardFault 就懵了其实定位方法非常固定第一板斧确定是哪个栈在起作用。看 LR链接寄存器的值LR 如果等于0xFFFFFFF9说明使用的是 MSP线程模式/主栈。LR 如果等于0xFFFFFFFD说明使用的是 PSP进程栈RTOS 环境常见。这个区分很重要因为 HardFault 现场的寄存器组保存在当前使用的栈里。如果是 PSP你需要把 PSP 指针带到 Keil 的 Watch 窗口里才能看到任务栈里的现场值。第二板斧看 PC 和 LR 是多少。这两个值指向的是发生异常时正在执行的指令地址和返回地址。把它们对应到编译出的 map 文件或反汇编文件基本能定位到是哪个函数炸了。第三板斧查 Fault 状态寄存器。在调试器的寄存器窗口里找CFSR可配置故障状态寄存器、HFSR硬故障状态寄存器、BFAR、MMFAR等能区分 Bus Fault、Usage Fault、MemManage Fault 的具体原因。比如CFSR里IBUSERR位置位说明取指令时访问了非法地址——很可能是函数指针跳错了位置。4.2 调试器连不上、程序反复复位这类问题常见于量产板。排查优先级我建议按这个顺序检查电源和复位电路NRST 引脚如果波形有抖动或异常低电平拉低芯片会一直在复位状态。检查 SWD 引脚是否被复用STM32 的 PA13/PA14 是 SWDIO/SWCLKPA15、PB3、PB4 是 JTAG 相关引脚。很多工程为了省引脚会把它们配置成普通 GPIO一旦烧录过这种程序重新连接调试器就会失败。低功耗模式误入代码里过早进入 STOP/STANDBY 模式导致 CPU 不响应调试请求。针对第 2 点有一个恢复手段使用 ST-Link Utility 的 Connect Under Reset 功能先让芯片停在复位状态再连接调试器然后擦除 Flash程序就恢复了。这也是我在量产阶段必教给产线工程师的技能。4.3 启动阶段问题排查速查表下面这张表适用于上电启动后完全不工作或行为异常的场景现象可能原因排查重点程序完全没跑BOOT 引脚配置错误BOOT0/BOOT1 电平程序没跑且电流异常电源电压不足/纹波过大万用表/示波器测 3.3V 与 NRST下载程序后无法连接调试器SWD/JTAG 引脚被复用Connect Under Reset 全擦除上电后系统时钟不对SystemInit 时钟配置失败检查外部晶振、PLL 参数main 之前 HardFault向量表错位 / 栈指针错误VTOR、__initial_sp 地址RTOS 第一个任务不运行SVC/PendSV 优先级配置错误配置 PendSV 为最低优先级跳 APP 后中断失效没有重定位向量表SCB-VTOR 设置变量初始值不对RW/ZI 段拷贝问题检查分散加载文件sct4.4 启动流程实战中容易被忽略的寄存器级细节很多教科书只会告诉你启动文件跳转到 main但实际工程里你会碰到更多硬件层面的坑。我分享几个自己调试中真实遇到过的细节第一个是做低功耗唤醒后的启动路径。STM32 从 STOP 模式唤醒后不会经过完整的 Reset_Handler 流程CPU 会继续执行唤醒点之后的代码但系统时钟可能已被硬件重置为默认的 HSI。很多工程师在这里踩坑任务恢复正常了但串口波特率全错就是因为你没有在唤醒代码里重新调用 SystemInit 或重新配置 PLL。更隐蔽的是 Standby 模式唤醒那是一次真正的复位但它走的是NRST 复位或唤醒复位路径和上电复位不完全等同。具体差异在各型号的参考手册里有张复位源表格值得翻一翻。第二个是 IWDG独立看门狗导致的循环复位。这类问题让人非常抓狂芯片刚启动看门狗就开始计时如果你在启动早期初始化 IWDG 后又恰好在设置超时参数前发生了某种阻塞比如等待 Flash 操作、等待外部器件应答IWDG 超时芯片复位然后又重复这个过程表现为永远卡在启动异常里。我用示波器测 NRST 引脚时会看到一系列规律的复位脉冲非常典型。解决思路很简单确认是否是看门狗复位通过RCC-CSR里的复位标志来区分然后在初始化流程里尽快喂狗或者设计上让看门狗在关键初始化完成之后再开启。第三个是 Flash 预取缓冲和指令延时WS配置。这是很多人完全忽略的启动细节。STM32 的 Flash 接口有一个等待状态寄存器FLASH_ACR它决定了 CPU 在访问 Flash 时插入几个等待周期。如果你主频较高却没有正确设置 WS 值Flash 读取时序就比 CPU 慢轻则程序偶尔跑飞重则启动后随机死机。SystemInit 里其实已经处理了这部分但如果你自己写了过早起频的代码或跳过了 SystemInit问题就会出现。之前有个项目把 SystemInit 精简掉、自己用寄存器配置时钟结果发现运行到某个耗时函数就会随机崩溃最后就是 WS 配置不对导致的。第四个是任务上下文切换时的栈对齐问题。ARM Cortex-M 内核要求栈指针在进入异常处理时保持 8 字节对齐AAPCS 调用约定。RTOS 创建任务栈时如果初始栈帧的地址没有按 8 字节对齐某些使用浮点或双字加载的代码就可能出错。古怪的是这类问题只在特定编译器优化级别下才暴露排查起来非常隐蔽。检查你的 RTOS 移植层里pxPortInitialiseStack对栈指针的处理以及在任务入口使用__ALIGN(8)等对齐宏是这类问题常见的解法。4.5 现场调试的三个小技巧最后分享几个我在实际调试启动流程时常用的技巧在 Reset_Handler 入口打断点。Keil 里进入 Debug 后自动停在 Reset_Handler这时候可以单步观察 SystemInit、__main 的调用过程。既能看到时序也能确认时钟配置是否生效。在 main() 开头观察全局变量。如果发现有变量初值不是预期值说明 RW/ZI 段初始化有问题回溯分散加载文件.sct或启动文件。用 RTT/串口打印启动阶段耗时。在 SystemInit 之前记录 SysTick 或 DWT 计数器值在 main 里再读一次能算出从复位到 main 的耗时。这个数据在做低功耗唤醒时间优化时非常有用。关于启动流程的完整理解我个人的体会是别把它当成IDE 自动生成的东西就跳过不看。启动文件虽然很多年都不需要改一次但一旦你的项目进入 Bootloader 开发、低功耗唤醒优化、或者 FreeRTOS/CubeMX 的深度定制阶段前面偷的懒都会在调试时加倍还回来。花一个下午把启动文件从头到尾通读一遍把断点打进每一段关键代码实际走一遍启动流程这个投入的回报远超你的预期。
