1. 上电那一刻芯片到底在干什么很多人调 STM32 调了几年写业务逻辑、配外设、跑 RTOS 都不在话下但一旦遇到“程序跑不起来”“HardFault 一上电就挂”“跳转 bootloader 后卡死”这类问题就开始抓瞎。根子往往不在业务代码而在从上电到main()之间那段“黑盒”——也就是复位向量到第一个任务的完整启动链路。这篇东西就是把这根链路从头到尾拆开讲清楚包括裸机启动和带 uC/OS-II 的启动两条线顺带把 PendSV、MSP/PSP 切换、向量表重定位这些容易踩坑的点讲透。先把结论摆前面STM32 上电后CPU 干的第一件事不是执行你的main而是从地址 0x00000000 处取两个 32 位值——第一个是初始 MSP主堆栈指针第二个是复位向量Reset_Handler 的地址。取完这两个值硬件自动把 MSP 设好然后跳到 Reset_Handler。这中间没有任何“操作系统”参与全是硬件行为。理解这一点后面所有启动细节都能串起来。这篇文章适合谁看如果你写过 STM32 的裸机工程、用过标准库或 HAL 库、跑过 FreeRTOS 或 uC/OS-II但从来没认真看过startup_stm32fxxx.s和system_stm32fxxx.c那这篇就是给你补课的。如果你正在做 bootloader、OTA 升级、或者多任务系统里遇到栈溢出、任务切换异常那这篇更值得逐字读。我会尽量用“人话”讲不堆术语但该有的细节一个不少。2. 启动链路整体设计从硬件取向量到 C 世界2.1 为什么启动代码要用汇编写STM32 的启动文件startup_stm32f103xb.s这类是汇编写的很多人第一次看到就头大。为什么不用 C因为上电瞬间 C 运行环境还不存在——栈指针没设、.data段没从 Flash 搬到 RAM、.bss段没清零。这些事必须用汇编手动做做完才能跳进 C 的main。用 C 写启动代码编译器生成的函数序言prologue会默认栈已经可用但那时候 MSP 还没初始化直接崩。启动文件干的事按顺序大致是这几件定义向量表Vector Table放在 Flash 起始地址第一项是初始 MSP第二项是 Reset_Handler。定义Reset_Handler里面调用SystemInit()配置时钟、向量表重定位等然后调用__main注意不是main。__main是 C 库函数ARM 的 microlib 或标准库提供它负责把.data段从 Flash 拷贝到 RAM、把.bss段清零最后才调用用户的main()。这里有个经典误区很多人以为 Reset_Handler 直接跳main。实际上中间隔了一个__main它是 C 库的入口做数据段初始化的。你如果在main之前想用全局变量能用的前提就是__main已经把.data搬好了。2.2 向量表长什么样为什么第一项是栈指针向量表本质是一个 32 位数组放在 Flash 最前面默认 0x08000000。前几项固定偏移内容说明0x00初始 MSP 值上电后硬件自动加载到 MSP0x04Reset_Handler 地址上电/复位后跳转目标0x08NMI_Handler不可屏蔽中断0x0CHardFault_Handler硬件错误......其他异常和外设中断为什么第一项是栈指针而不是代码地址这是 ARM Cortex-M 的设计约定上电时硬件需要先有一个可用的栈才能执行任何函数调用。所以向量表第一项直接放栈顶地址硬件取出来就塞进 MSP第二项才是代码入口。这个设计让启动流程不需要任何软件干预就能建立最基本的运行环境。栈顶地址怎么来的在启动文件里通常写成__initial_sp它由链接脚本.sct文件或STM32F103XB_FLASH.ld根据 RAM 大小自动算出。比如 STM32F103C8T6 有 20KB RAM起始 0x20000000栈顶一般设成 0x20005000RAM 末尾栈向下增长。2.3 SystemInit 到底做了什么SystemInit()在system_stm32f1xx.c里上电后由 Reset_Handler 调用。它主要干三件事配置时钟把 HSI内部 8MHz RC切到 HSE外部晶振再通过 PLL 倍频到 72MHzF1 系列。这一步决定了你后面所有外设的时钟基准。配置向量表偏移通过SCB-VTOR寄存器设置向量表基地址。默认是 0x08000000但如果你做 bootloaderAPP 的向量表可能被重定位到 0x08008000这里就要改。使能 Flash 预取F1 系列需要开FLASH-ACR的预取位否则 72MHz 下取指会变慢。很多人调时钟调不通问题就出在 SystemInit 里 HSE 起振失败代码卡在等待 HSERDY 标志的死循环里。这时候要么换晶振要么在 SystemInit 里加超时退出回退到 HSI。3. 核心细节拆解MSP、PSP 与 PendSV 的三角关系3.1 MSP 和 PSP 到底怎么分工Cortex-M 有两个栈指针**MSP主栈指针**和PSP进程栈指针。上电默认用 MSP所有中断和异常处理都用 MSP。那 PSP 什么时候用答案是跑 RTOS 的时候任务用 PSP中断用 MSP。为什么要分开因为任务栈和中断栈混在一起会出大问题。假设任务栈只有 512 字节中断来了往同一个栈压寄存器很容易溢出。分开之后中断永远用 MSP通常栈空间大任务用 PSP每个任务独立栈互不干扰。切换动作发生在CONTROL寄存器的 bit1。写 1 表示线程模式用 PSP写 0 表示用 MSP。注意中断处理模式下永远用 MSPCONTROL 的 bit1 在 handler 模式下被忽略。这是硬件强制的防止你在中断里误切栈。3.2 PendSV 为什么是 RTOS 切换任务的最佳选择uC/OS-II 和 FreeRTOS 都用PendSV做任务切换而不是用 SysTick 直接切。原因很讲究SysTick 是周期性中断如果直接在 SysTick handler 里做上下文切换会打断其他中断的响应导致中断延迟不可控。PendSV 是一个可挂起的异常优先级可以设成最低。这样所有其他中断都能先处理完最后才轮到 PendSV 做任务切换保证中断响应实时性。具体做法是SysTick handler 里只做一件事——触发 PendSV写ICSR寄存器的PENDSVSET位。PendSV handler 里才真正做上下文保存和恢复。这样任务切换被“推迟”到所有高优先级中断处理完之后系统实时性最好。PendSV handler 的汇编大概长这样简化版PendSV_Handler: MRS R0, PSP ; 取当前任务的 PSP CBZ R0, PendSV_NoSave ; 如果是第一次跳过保存 STMDB R0!, {R4-R11} ; 保存 R4-R11 到任务栈 LDR R1, OSTCBCurPtr ; 取当前 TCB 指针 LDR R1, [R1] STR R0, [R1] ; 更新 TCB 的栈指针 PendSV_NoSave: PUSH {LR} BL OSIntExit ; 调用 OS 调度器 POP {LR} LDR R0, OSTCBHighRdyPtr LDR R0, [R0] LDR R0, [R0] ; 取最高优先级任务的栈指针 LDMIA R0!, {R4-R11} ; 恢复 R4-R11 MSR PSP, R0 ; 更新 PSP ORR LR, LR, #0x04 ; 确保返回后使用 PSP BX LR这段代码的关键点R4-R11 是手动保存的R0-R3、R12、LR、PC、xPSR 是硬件自动压栈的。这是 ARM 的约定硬件压栈发生在异常入口软件只需要保存剩下的寄存器。3.3 第一次任务切换的特殊处理系统启动后第一个任务怎么跑起来这里有个“第一次”的特殊情况。在OSStart()里会先找到最高优先级任务然后手动设置 PSP 指向该任务的栈再触发 PendSV。但第一次进 PendSV 时当前没有“正在运行的任务”所以PSP可能是 0 或者无效值代码里用CBZ R0, PendSV_NoSave跳过保存步骤。这个细节如果处理不好第一次任务切换就会 HardFault。我见过有人在移植 uC/OS-II 时忘了处理这个分支结果一上电就挂查了半天以为是栈大小问题其实是第一次切换时访问了非法 PSP。4. 实操过程从复位到第一个任务的完整复现4.1 裸机启动的完整流程先看不带 RTOS 的情况。假设你用 Keil 建了一个 STM32F103 标准库工程上电后发生的事按时间顺序是硬件取向量从 0x08000000 取 MSP从 0x08000004 取 Reset_Handler 地址跳过去。执行 Reset_Handler调用SystemInit()配置 72MHz 时钟和向量表。调用__mainC 库函数拷贝.data段、清零.bss段。调用main()进入你的业务代码。这个过程可以用调试器验证。在 Keil 里把断点设在main第一行然后复位看 Call Stack 窗口你会看到main上面是__main再上面是Reset_Handler。这就是完整的调用链。如果你想更细地看可以在 Reset_Handler 第一行设断点单步走。你会看到 MSP 的值在第一步就被硬件设好了值是链接脚本里定义的__initial_sp。4.2 带 uC/OS-II 的启动流程带 RTOS 的情况多了一层main()里不再直接跑业务而是初始化 OS、创建任务、调用OSStart()。完整链路是硬件取向量跳 Reset_Handler。SystemInit 配时钟。__main初始化数据段。main()执行OSInit()初始化 OS 内核创建空闲任务。创建至少一个用户任务OSTaskCreate。OSStart()启动调度器。OSStart()内部找到最高优先级任务。设置 PSP 指向该任务栈。触发 PendSV。PendSV handler 执行第一次任务切换跳到任务入口函数。这里的关键是OSStart()里的 PSP 设置。uC/OS-II 的OSStartHighRdy()是汇编写的它会从最高优先级任务的 TCB 里取出栈指针减去硬件压栈的 8 个寄存器R0-R3、R12、LR、PC、xPSR占用的 32 字节然后设给 PSP。这样 PendSV 返回时硬件自动从 PSP 弹出那 8 个寄存器PC 就指向任务入口。4.3 向量表重定位的实操做 bootloader 时APP 的向量表不在 0x08000000而在比如 0x08008000。这时候需要两步第一步在 APP 的SystemInit()里改SCB-VTORSCB-VTOR 0x08008000;第二步在 bootloader 跳转前设置 MSP 并跳转到 APP 的 Reset_Handlertypedef void (*pFunction)(void); pFunction JumpToApp; uint32_t appMsp *(volatile uint32_t*)0x08008000; uint32_t appReset *(volatile uint32_t*)0x08008004; __set_MSP(appMsp); JumpToApp (pFunction)appReset; JumpToApp();注意跳转前要关掉所有中断和外设否则 APP 里重新初始化时会冲突。我踩过的坑是bootloader 里开了 SysTick跳转前没关APP 里又初始化一遍结果 SysTick 中断向量指向的还是 bootloader 的 handler一进中断就跳飞。5. 常见问题与排查技巧实录5.1 上电就 HardFault 怎么查HardFault 是启动阶段最常见的故障。排查思路先看是不是栈溢出。把 MSP 初始值打印出来看是不是落在 RAM 范围内。如果链接脚本写错MSP 可能指向非法地址。再看向量表。如果 VTOR 没设对中断来了会跳到错误地址。用调试器看SCB-VTOR的值。最后看时钟。如果 HSE 起振失败SystemInit 卡死表现像 HardFault 但其实是死循环。有个技巧在 HardFault_Handler 里加死循环然后用调试器看 LR 寄存器的值能判断是从线程模式还是 handler 模式进来的。LR 的 bit2 为 0 表示 handler 模式为 1 表示线程模式。5.2 任务切换后跑飞的原因跑 RTOS 时任务切换后跑飞常见原因现象可能原因排查方法第一个任务就不跑PSP 设置错误看 OSStartHighRdy 汇编切换几次后挂任务栈溢出加大栈或开栈检查中断里切换挂PendSV 优先级不对设成最低优先级浮点任务挂没保存 FPU 寄存器开 lazy stacking 或手动保存uC/OS-II 在 Cortex-M3 上默认不保存 FPU 寄存器M3 没有 FPU但如果你用 M4/M7任务里用了浮点就必须在 PendSV 里额外保存 S0-S15 和 FPSCR。这个坑很多人踩表现是浮点计算结果莫名其妙出错。5.3 向量表偏移忘了改的后果做 OTA 升级时APP 的向量表偏移如果忘了改中断会跳到 bootloader 的向量表。表现是APP 能跑但一进中断就执行 bootloader 的 handler通常直接 HardFault。这个问题的隐蔽性在于如果 APP 没开中断可能一直不触发直到某个外设中断来了才挂。排查方法在 APP 的main里打印SCB-VTOR确认是不是 APP 的向量表地址。如果不是检查 SystemInit 里的VECT_TAB_OFFSET宏。6. 几个容易被忽略的启动细节6.1__main和main的区别前面提过Reset_Handler 调用的是__main而不是main。__main是 ARM C 库的入口它做数据段初始化然后才调main。如果你用 microlib__main的行为略有不同但核心逻辑一样。有个细节__main还会初始化堆heap。如果你在main之前用了malloc能用的前提是__main已经把堆设好了。但一般不建议在启动阶段用堆因为堆大小在链接脚本里定容易溢出。6.2 中断向量表的对齐要求Cortex-M 要求向量表至少 128 字节对齐VTOR 的低 7 位保留。如果你把向量表放在 0x08008000这是 256 字节对齐没问题。但如果放在 0x08008080就违反了 128 字节对齐硬件行为未定义。做 bootloader 时APP 起始地址要选 128 字节对齐的比如 0x08008000、0x08010000。6.3 启动阶段的看门狗处理如果开了独立看门狗IWDG上电后它就开始计数。如果启动流程太长比如 SystemInit 里等 HSE 起振超时看门狗可能先复位。处理办法在 Reset_Handler 最前面就喂一次狗或者用窗口看门狗WWDG并合理设置窗口。我遇到过一个问题bootloader 里开了 IWDG跳转 APP 前没关APP 启动慢看门狗复位结果一直卡在 bootloader 和 APP 之间循环。解决办法是跳转前关掉 IWDGAPP 里重新初始化。6.4 启动时间的测量想知道从上电到main花了多久可以用 GPIO 翻转加示波器测。在 Reset_Handler 第一行拉高一个 IO在main第一行拉低示波器上看脉宽就是启动时间。F103 在 72MHz 下这段通常几十微秒到几百微秒取决于时钟配置和数据段大小。如果启动时间太长优化方向减少.data段大小少用初始化全局变量、加快 HSE 起振换晶振或调负载电容、关掉不必要的 SystemInit 步骤。7. 从启动流程延伸出去的几个实战场景7.1 bootloader 与 APP 的向量表协作做 bootloader 时APP 的向量表重定位是必须的。但还有个细节APP 里的SystemInit会重新配时钟如果 bootloader 已经配好了APP 再配一遍可能出问题。稳妥做法是 APP 的 SystemInit 里判断时钟是否已经配好配好就跳过。另外APP 的链接脚本要把起始地址改成 0x08008000否则编译出来的向量表还在 0x08000000和 bootloader 冲突。7.2 OTA 升级中的启动跳转OTA 升级时新固件下载到备份区校验通过后跳转到备份区运行。这时候启动流程变成bootloader 判断升级标志如果有效重定位向量表到备份区跳转。跳转前要确保备份区的向量表第一项MSP和 第二项Reset_Handler是有效的否则跳过去直接挂。校验方法读备份区前 8 字节检查 MSP 是否在 RAM 范围内Reset_Handler 是否在 Flash 范围内。这两个检查能过滤掉大部分下载不完整的情况。7.3 多任务系统里的栈规划跑 uC/OS-II 时每个任务要有独立栈。栈大小怎么定经验值简单任务 128 字节复杂任务 512 字节到 1KB。但这是估算实际要用OSTaskStkChk()检查栈使用率留 30% 余量。MSP 的栈中断栈也要规划。如果中断嵌套深MSP 栈要大。F103 的 20KB RAM通常 MSP 给 1KB剩下给任务栈和全局变量。有个坑uC/OS-II 的OSTaskCreate里栈是从上往下增长的传入的栈顶地址要是栈的高地址端。如果传反了任务一跑就踩到别的内存。8. 我个人的几条实操心得调启动流程这些年踩过的坑比写过的代码还多。几条心得分享出来能帮你少走弯路。第一永远在 Reset_Handler 第一行设断点。不管什么问题先确认启动流程走到哪一步了。如果连 Reset_Handler 都没进那是硬件问题供电、晶振、复位电路如果进了但没到main那是 SystemInit 或__main的问题如果到了main但跑飞那是业务代码或 RTOS 配置的问题。这个三分法能快速定位问题域。第二向量表重定位后一定要验证。在 APP 的main里打印SCB-VTOR确认值对。我见过有人改了VECT_TAB_OFFSET但忘了在 SystemInit 里用结果 VTOR 还是默认值中断全跳错。第三PendSV 优先级设成最低。这是 RTOS 移植的铁律。如果 PendSV 优先级比 SysTick 高任务切换会打断 SysTick导致系统节拍不准。uC/OS-II 的OS_CPU_SysTickInit里会设优先级确认一下。第四第一次任务切换单独测。移植 RTOS 时先创建一个任务里面只翻转 IO确认能跑起来。再加第二个任务确认能切换。最后才加业务逻辑。这样出问题容易定位。第五启动时间要心里有数。如果产品对启动时间敏感比如需要快速响应的设备启动流程的每一步都要优化。我做过一个项目启动时间从 200ms 优化到 50ms主要靠减少.data段和加快时钟配置。最后说个小事很多人问“为什么我的 STM32 上电后 LED 闪一下就灭”。这通常是启动阶段看门狗复位或者电源不稳导致反复复位。用示波器看复位引脚如果有周期性脉冲就是复位电路问题如果复位引脚稳定但程序跑飞就是启动流程问题。分清楚这两类排查方向完全不同。
1. 上电那一刻芯片到底在干什么很多人调 STM32 调了几年写业务逻辑、配外设、跑 RTOS 都不在话下但一旦遇到“程序跑不起来”“HardFault 一上电就挂”“跳转 bootloader 后卡死”这类问题就开始抓瞎。根子往往不在业务代码而在从上电到main()之间那段“黑盒”——也就是复位向量到第一个任务的完整启动链路。这篇东西就是把这根链路从头到尾拆开讲清楚包括裸机启动和带 uC/OS-II 的启动两条线顺带把 PendSV、MSP/PSP 切换、向量表重定位这些容易踩坑的点讲透。先把结论摆前面STM32 上电后CPU 干的第一件事不是执行你的main而是从地址 0x00000000 处取两个 32 位值——第一个是初始 MSP主堆栈指针第二个是复位向量Reset_Handler 的地址。取完这两个值硬件自动把 MSP 设好然后跳到 Reset_Handler。这中间没有任何“操作系统”参与全是硬件行为。理解这一点后面所有启动细节都能串起来。这篇文章适合谁看如果你写过 STM32 的裸机工程、用过标准库或 HAL 库、跑过 FreeRTOS 或 uC/OS-II但从来没认真看过startup_stm32fxxx.s和system_stm32fxxx.c那这篇就是给你补课的。如果你正在做 bootloader、OTA 升级、或者多任务系统里遇到栈溢出、任务切换异常那这篇更值得逐字读。我会尽量用“人话”讲不堆术语但该有的细节一个不少。2. 启动链路整体设计从硬件取向量到 C 世界2.1 为什么启动代码要用汇编写STM32 的启动文件startup_stm32f103xb.s这类是汇编写的很多人第一次看到就头大。为什么不用 C因为上电瞬间 C 运行环境还不存在——栈指针没设、.data段没从 Flash 搬到 RAM、.bss段没清零。这些事必须用汇编手动做做完才能跳进 C 的main。用 C 写启动代码编译器生成的函数序言prologue会默认栈已经可用但那时候 MSP 还没初始化直接崩。启动文件干的事按顺序大致是这几件定义向量表Vector Table放在 Flash 起始地址第一项是初始 MSP第二项是 Reset_Handler。定义Reset_Handler里面调用SystemInit()配置时钟、向量表重定位等然后调用__main注意不是main。__main是 C 库函数ARM 的 microlib 或标准库提供它负责把.data段从 Flash 拷贝到 RAM、把.bss段清零最后才调用用户的main()。这里有个经典误区很多人以为 Reset_Handler 直接跳main。实际上中间隔了一个__main它是 C 库的入口做数据段初始化的。你如果在main之前想用全局变量能用的前提就是__main已经把.data搬好了。2.2 向量表长什么样为什么第一项是栈指针向量表本质是一个 32 位数组放在 Flash 最前面默认 0x08000000。前几项固定偏移内容说明0x00初始 MSP 值上电后硬件自动加载到 MSP0x04Reset_Handler 地址上电/复位后跳转目标0x08NMI_Handler不可屏蔽中断0x0CHardFault_Handler硬件错误......其他异常和外设中断为什么第一项是栈指针而不是代码地址这是 ARM Cortex-M 的设计约定上电时硬件需要先有一个可用的栈才能执行任何函数调用。所以向量表第一项直接放栈顶地址硬件取出来就塞进 MSP第二项才是代码入口。这个设计让启动流程不需要任何软件干预就能建立最基本的运行环境。栈顶地址怎么来的在启动文件里通常写成__initial_sp它由链接脚本.sct文件或STM32F103XB_FLASH.ld根据 RAM 大小自动算出。比如 STM32F103C8T6 有 20KB RAM起始 0x20000000栈顶一般设成 0x20005000RAM 末尾栈向下增长。2.3 SystemInit 到底做了什么SystemInit()在system_stm32f1xx.c里上电后由 Reset_Handler 调用。它主要干三件事配置时钟把 HSI内部 8MHz RC切到 HSE外部晶振再通过 PLL 倍频到 72MHzF1 系列。这一步决定了你后面所有外设的时钟基准。配置向量表偏移通过SCB-VTOR寄存器设置向量表基地址。默认是 0x08000000但如果你做 bootloaderAPP 的向量表可能被重定位到 0x08008000这里就要改。使能 Flash 预取F1 系列需要开FLASH-ACR的预取位否则 72MHz 下取指会变慢。很多人调时钟调不通问题就出在 SystemInit 里 HSE 起振失败代码卡在等待 HSERDY 标志的死循环里。这时候要么换晶振要么在 SystemInit 里加超时退出回退到 HSI。3. 核心细节拆解MSP、PSP 与 PendSV 的三角关系3.1 MSP 和 PSP 到底怎么分工Cortex-M 有两个栈指针**MSP主栈指针**和PSP进程栈指针。上电默认用 MSP所有中断和异常处理都用 MSP。那 PSP 什么时候用答案是跑 RTOS 的时候任务用 PSP中断用 MSP。为什么要分开因为任务栈和中断栈混在一起会出大问题。假设任务栈只有 512 字节中断来了往同一个栈压寄存器很容易溢出。分开之后中断永远用 MSP通常栈空间大任务用 PSP每个任务独立栈互不干扰。切换动作发生在CONTROL寄存器的 bit1。写 1 表示线程模式用 PSP写 0 表示用 MSP。注意中断处理模式下永远用 MSPCONTROL 的 bit1 在 handler 模式下被忽略。这是硬件强制的防止你在中断里误切栈。3.2 PendSV 为什么是 RTOS 切换任务的最佳选择uC/OS-II 和 FreeRTOS 都用PendSV做任务切换而不是用 SysTick 直接切。原因很讲究SysTick 是周期性中断如果直接在 SysTick handler 里做上下文切换会打断其他中断的响应导致中断延迟不可控。PendSV 是一个可挂起的异常优先级可以设成最低。这样所有其他中断都能先处理完最后才轮到 PendSV 做任务切换保证中断响应实时性。具体做法是SysTick handler 里只做一件事——触发 PendSV写ICSR寄存器的PENDSVSET位。PendSV handler 里才真正做上下文保存和恢复。这样任务切换被“推迟”到所有高优先级中断处理完之后系统实时性最好。PendSV handler 的汇编大概长这样简化版PendSV_Handler: MRS R0, PSP ; 取当前任务的 PSP CBZ R0, PendSV_NoSave ; 如果是第一次跳过保存 STMDB R0!, {R4-R11} ; 保存 R4-R11 到任务栈 LDR R1, OSTCBCurPtr ; 取当前 TCB 指针 LDR R1, [R1] STR R0, [R1] ; 更新 TCB 的栈指针 PendSV_NoSave: PUSH {LR} BL OSIntExit ; 调用 OS 调度器 POP {LR} LDR R0, OSTCBHighRdyPtr LDR R0, [R0] LDR R0, [R0] ; 取最高优先级任务的栈指针 LDMIA R0!, {R4-R11} ; 恢复 R4-R11 MSR PSP, R0 ; 更新 PSP ORR LR, LR, #0x04 ; 确保返回后使用 PSP BX LR这段代码的关键点R4-R11 是手动保存的R0-R3、R12、LR、PC、xPSR 是硬件自动压栈的。这是 ARM 的约定硬件压栈发生在异常入口软件只需要保存剩下的寄存器。3.3 第一次任务切换的特殊处理系统启动后第一个任务怎么跑起来这里有个“第一次”的特殊情况。在OSStart()里会先找到最高优先级任务然后手动设置 PSP 指向该任务的栈再触发 PendSV。但第一次进 PendSV 时当前没有“正在运行的任务”所以PSP可能是 0 或者无效值代码里用CBZ R0, PendSV_NoSave跳过保存步骤。这个细节如果处理不好第一次任务切换就会 HardFault。我见过有人在移植 uC/OS-II 时忘了处理这个分支结果一上电就挂查了半天以为是栈大小问题其实是第一次切换时访问了非法 PSP。4. 实操过程从复位到第一个任务的完整复现4.1 裸机启动的完整流程先看不带 RTOS 的情况。假设你用 Keil 建了一个 STM32F103 标准库工程上电后发生的事按时间顺序是硬件取向量从 0x08000000 取 MSP从 0x08000004 取 Reset_Handler 地址跳过去。执行 Reset_Handler调用SystemInit()配置 72MHz 时钟和向量表。调用__mainC 库函数拷贝.data段、清零.bss段。调用main()进入你的业务代码。这个过程可以用调试器验证。在 Keil 里把断点设在main第一行然后复位看 Call Stack 窗口你会看到main上面是__main再上面是Reset_Handler。这就是完整的调用链。如果你想更细地看可以在 Reset_Handler 第一行设断点单步走。你会看到 MSP 的值在第一步就被硬件设好了值是链接脚本里定义的__initial_sp。4.2 带 uC/OS-II 的启动流程带 RTOS 的情况多了一层main()里不再直接跑业务而是初始化 OS、创建任务、调用OSStart()。完整链路是硬件取向量跳 Reset_Handler。SystemInit 配时钟。__main初始化数据段。main()执行OSInit()初始化 OS 内核创建空闲任务。创建至少一个用户任务OSTaskCreate。OSStart()启动调度器。OSStart()内部找到最高优先级任务。设置 PSP 指向该任务栈。触发 PendSV。PendSV handler 执行第一次任务切换跳到任务入口函数。这里的关键是OSStart()里的 PSP 设置。uC/OS-II 的OSStartHighRdy()是汇编写的它会从最高优先级任务的 TCB 里取出栈指针减去硬件压栈的 8 个寄存器R0-R3、R12、LR、PC、xPSR占用的 32 字节然后设给 PSP。这样 PendSV 返回时硬件自动从 PSP 弹出那 8 个寄存器PC 就指向任务入口。4.3 向量表重定位的实操做 bootloader 时APP 的向量表不在 0x08000000而在比如 0x08008000。这时候需要两步第一步在 APP 的SystemInit()里改SCB-VTORSCB-VTOR 0x08008000;第二步在 bootloader 跳转前设置 MSP 并跳转到 APP 的 Reset_Handlertypedef void (*pFunction)(void); pFunction JumpToApp; uint32_t appMsp *(volatile uint32_t*)0x08008000; uint32_t appReset *(volatile uint32_t*)0x08008004; __set_MSP(appMsp); JumpToApp (pFunction)appReset; JumpToApp();注意跳转前要关掉所有中断和外设否则 APP 里重新初始化时会冲突。我踩过的坑是bootloader 里开了 SysTick跳转前没关APP 里又初始化一遍结果 SysTick 中断向量指向的还是 bootloader 的 handler一进中断就跳飞。5. 常见问题与排查技巧实录5.1 上电就 HardFault 怎么查HardFault 是启动阶段最常见的故障。排查思路先看是不是栈溢出。把 MSP 初始值打印出来看是不是落在 RAM 范围内。如果链接脚本写错MSP 可能指向非法地址。再看向量表。如果 VTOR 没设对中断来了会跳到错误地址。用调试器看SCB-VTOR的值。最后看时钟。如果 HSE 起振失败SystemInit 卡死表现像 HardFault 但其实是死循环。有个技巧在 HardFault_Handler 里加死循环然后用调试器看 LR 寄存器的值能判断是从线程模式还是 handler 模式进来的。LR 的 bit2 为 0 表示 handler 模式为 1 表示线程模式。5.2 任务切换后跑飞的原因跑 RTOS 时任务切换后跑飞常见原因现象可能原因排查方法第一个任务就不跑PSP 设置错误看 OSStartHighRdy 汇编切换几次后挂任务栈溢出加大栈或开栈检查中断里切换挂PendSV 优先级不对设成最低优先级浮点任务挂没保存 FPU 寄存器开 lazy stacking 或手动保存uC/OS-II 在 Cortex-M3 上默认不保存 FPU 寄存器M3 没有 FPU但如果你用 M4/M7任务里用了浮点就必须在 PendSV 里额外保存 S0-S15 和 FPSCR。这个坑很多人踩表现是浮点计算结果莫名其妙出错。5.3 向量表偏移忘了改的后果做 OTA 升级时APP 的向量表偏移如果忘了改中断会跳到 bootloader 的向量表。表现是APP 能跑但一进中断就执行 bootloader 的 handler通常直接 HardFault。这个问题的隐蔽性在于如果 APP 没开中断可能一直不触发直到某个外设中断来了才挂。排查方法在 APP 的main里打印SCB-VTOR确认是不是 APP 的向量表地址。如果不是检查 SystemInit 里的VECT_TAB_OFFSET宏。6. 几个容易被忽略的启动细节6.1__main和main的区别前面提过Reset_Handler 调用的是__main而不是main。__main是 ARM C 库的入口它做数据段初始化然后才调main。如果你用 microlib__main的行为略有不同但核心逻辑一样。有个细节__main还会初始化堆heap。如果你在main之前用了malloc能用的前提是__main已经把堆设好了。但一般不建议在启动阶段用堆因为堆大小在链接脚本里定容易溢出。6.2 中断向量表的对齐要求Cortex-M 要求向量表至少 128 字节对齐VTOR 的低 7 位保留。如果你把向量表放在 0x08008000这是 256 字节对齐没问题。但如果放在 0x08008080就违反了 128 字节对齐硬件行为未定义。做 bootloader 时APP 起始地址要选 128 字节对齐的比如 0x08008000、0x08010000。6.3 启动阶段的看门狗处理如果开了独立看门狗IWDG上电后它就开始计数。如果启动流程太长比如 SystemInit 里等 HSE 起振超时看门狗可能先复位。处理办法在 Reset_Handler 最前面就喂一次狗或者用窗口看门狗WWDG并合理设置窗口。我遇到过一个问题bootloader 里开了 IWDG跳转 APP 前没关APP 启动慢看门狗复位结果一直卡在 bootloader 和 APP 之间循环。解决办法是跳转前关掉 IWDGAPP 里重新初始化。6.4 启动时间的测量想知道从上电到main花了多久可以用 GPIO 翻转加示波器测。在 Reset_Handler 第一行拉高一个 IO在main第一行拉低示波器上看脉宽就是启动时间。F103 在 72MHz 下这段通常几十微秒到几百微秒取决于时钟配置和数据段大小。如果启动时间太长优化方向减少.data段大小少用初始化全局变量、加快 HSE 起振换晶振或调负载电容、关掉不必要的 SystemInit 步骤。7. 从启动流程延伸出去的几个实战场景7.1 bootloader 与 APP 的向量表协作做 bootloader 时APP 的向量表重定位是必须的。但还有个细节APP 里的SystemInit会重新配时钟如果 bootloader 已经配好了APP 再配一遍可能出问题。稳妥做法是 APP 的 SystemInit 里判断时钟是否已经配好配好就跳过。另外APP 的链接脚本要把起始地址改成 0x08008000否则编译出来的向量表还在 0x08000000和 bootloader 冲突。7.2 OTA 升级中的启动跳转OTA 升级时新固件下载到备份区校验通过后跳转到备份区运行。这时候启动流程变成bootloader 判断升级标志如果有效重定位向量表到备份区跳转。跳转前要确保备份区的向量表第一项MSP和 第二项Reset_Handler是有效的否则跳过去直接挂。校验方法读备份区前 8 字节检查 MSP 是否在 RAM 范围内Reset_Handler 是否在 Flash 范围内。这两个检查能过滤掉大部分下载不完整的情况。7.3 多任务系统里的栈规划跑 uC/OS-II 时每个任务要有独立栈。栈大小怎么定经验值简单任务 128 字节复杂任务 512 字节到 1KB。但这是估算实际要用OSTaskStkChk()检查栈使用率留 30% 余量。MSP 的栈中断栈也要规划。如果中断嵌套深MSP 栈要大。F103 的 20KB RAM通常 MSP 给 1KB剩下给任务栈和全局变量。有个坑uC/OS-II 的OSTaskCreate里栈是从上往下增长的传入的栈顶地址要是栈的高地址端。如果传反了任务一跑就踩到别的内存。8. 我个人的几条实操心得调启动流程这些年踩过的坑比写过的代码还多。几条心得分享出来能帮你少走弯路。第一永远在 Reset_Handler 第一行设断点。不管什么问题先确认启动流程走到哪一步了。如果连 Reset_Handler 都没进那是硬件问题供电、晶振、复位电路如果进了但没到main那是 SystemInit 或__main的问题如果到了main但跑飞那是业务代码或 RTOS 配置的问题。这个三分法能快速定位问题域。第二向量表重定位后一定要验证。在 APP 的main里打印SCB-VTOR确认值对。我见过有人改了VECT_TAB_OFFSET但忘了在 SystemInit 里用结果 VTOR 还是默认值中断全跳错。第三PendSV 优先级设成最低。这是 RTOS 移植的铁律。如果 PendSV 优先级比 SysTick 高任务切换会打断 SysTick导致系统节拍不准。uC/OS-II 的OS_CPU_SysTickInit里会设优先级确认一下。第四第一次任务切换单独测。移植 RTOS 时先创建一个任务里面只翻转 IO确认能跑起来。再加第二个任务确认能切换。最后才加业务逻辑。这样出问题容易定位。第五启动时间要心里有数。如果产品对启动时间敏感比如需要快速响应的设备启动流程的每一步都要优化。我做过一个项目启动时间从 200ms 优化到 50ms主要靠减少.data段和加快时钟配置。最后说个小事很多人问“为什么我的 STM32 上电后 LED 闪一下就灭”。这通常是启动阶段看门狗复位或者电源不稳导致反复复位。用示波器看复位引脚如果有周期性脉冲就是复位电路问题如果复位引脚稳定但程序跑飞就是启动流程问题。分清楚这两类排查方向完全不同。
