1. 从按下复位那刻说起：为什么每个嵌入式工程师都该搞懂启动流程
做 STM32 开发几年，写过驱动、调过协议栈、折腾过各种外设，但如果说哪个环节最容易被忽略却又最值得花时间彻底吃透，我第一个投票给“上电启动流程”。原因很简单：你写的每一行 C 代码，最终都要靠启动阶段把它从 Flash 里搬出来、把内存准备好、把中断向量表挂好，然后才能跑到 main 函数里。这一整套动作，就是芯片从上电复位到用户程序开始执行的完整链条。
不少朋友遇到过这类问题：程序在 Debug 模式下跑得好好的，一断电重新上电就死在莫名奇妙的地方；或者说在 Keil 里点“下载”能运行，但单独用串口 ISP 烧录后却跑不起来；甚至有些时候，一个简单的全局变量初始化值不对，查了半天发现不是编译问题，而是启动文件里的copy和zero段操作没有正确执行。这些现象，十有八九都跟复位向量、启动文件（startup_xxx.s）以及链接脚本（.ld或.sct）的配合有关。
这篇文章我打算沿着一条主线走：从芯片复位后取第一条指令开始，到启动文件完成段搬运、堆栈初始化，再到进入 C 世界、最终创建并切换到第一个 RTOS 任务。整个过程我会结合 STM32 的硬件机制、GCC 工具链下的链接脚本、启动汇编代码，以及 FreeRTOS 的任务切换细节来拆解。无论你是刚接触 STM32 的初学者，还是想深入理解内核启动机制的进阶开发者，这条链路都值得完整走一遍。搞清楚它，能帮你省下大量排查“野指针”“全局变量没赋值”“任务没跑起来”的时间。
2. 复位向量与硬件启动的底层逻辑
2.1 上电后 CPU 干的第一件事：取向量，不是执行指令
很多人第一次看 STM32 的启动文件，看到开头一大堆DCD指令，会误以为那是“代码”。其实那不是代码，那是中断向量表。在 ARM Cortex-M 内核（STM32 全系列基本都是 Cortex-M0/M3/M4/M7）中，上电复位后 CPU 并不是直接跳到一个固定地址去执行程序，而是从向量表里读取两个关键值：
初始堆栈指针（SP）和复位向量（Reset_Handler）。
具体来说，Cortex-M 内核规定：
0x00000000处存放初始堆栈指针值（栈顶地址）；0x00000004处存放复位后第一条要执行的指令地址。
CPU 复位后，硬件会自动完成两步：从地址0x00000000加载 SP，从地址0x00000004加载 PC。然后就跳到那个 PC 指向的地址，开始执行真正的启动代码。
如果你用 STM32CubeMX 生成过工程，打开startup_stm32f103xe.s，开头一定是这样一段：
__initial_sp DCD 0x20005000 ; 栈顶地址，由链接脚本决定 DCD Reset_Handler ; 复位向量地址 DCD NMI_Handler DCD HardFault_Handler ...这里的DCD表示“定义一个 32 位数据”，按顺序排列，就构成了向量表。向量表的位置不是固定的，它是通过链接脚本中的VECTOR_TABLE或__VECTOR_TABLE等符号指定的。在 STM32F1 系列里，默认从0x08000000（Flash 起始地址）开始，但如果你启用了 Boot 引脚配置，芯片也可能从系统存储器或 SRAM 启动，那时向量表的基地址会不同。这正是很多人烧录后“程序跑飞”的一个隐藏原因：向量表放的位置和芯片实际启动的地址不匹配。
2.2 为什么向量表里第一个元素是栈顶地址？
这里有一个关键设计思路：Cortex-M 内核在进入任何中断或异常之前，需要先把当前上下文压栈，而压栈操作要使用主栈指针（MSP）。如果上电后栈指针没有初始化，第一个中断到来时 CPU 就会把数据写到非法地址，直接 HardFault。
所以硬件在复位后做的第一件事是“先让栈可用”，然后才想着去取指令。这个顺序跟很多教科书上讲的“PC 指向复位向量”不太一样——严格来说，是 SP 先被加载，PC 再被加载。你在调试器里单步执行第一行汇编时，sp寄存器其实已经被设置好了。
关于栈顶地址的数值，它并不总是固定在某个 RAM 地址。在 GCC 链接脚本中，栈顶是由_estack这个符号定义的，通常在链接脚本里这样写：
_estack = 0x20005000; /* 假设 RAM 大小为 20KB */如果 RAM 是0x20000000开始、大小0x5000，那么_estack就是0x20005000，即 RAM 的最高地址。ARM Cortex-M 的栈是向下增长的，所以栈指针初始化到 RAM 的顶端是最合理的选择——这样栈空间尽可能大，且不会跟下面的全局变量区冲突（前提是堆和全局变量都没越界）。
注意：
_estack的值必须大于等于全局变量区、堆区的最高地址。如果 RAM 资源紧张，你可能会看到链接报错region 'RAM' overflowed，那通常不是你栈设小了，而是全局变量 + 堆 + 栈的总和超过了物理 RAM 大小。
2.3 启动模式与向量表偏移：屏蔽“上电不跑”的经典坑
STM32 的 BOOT0/BOOT1 引脚决定芯片上电后从哪块存储区开始执行。三种模式分别是：
| BOOT0 | BOOT1 | 启动区域 | 说明 |
|---|---|---|---|
| 0 | x | 主 Flash（0x08000000） | 正常用户程序运行模式 |
| 1 | 0 | 系统存储器（0x1FFF0000） | 用于 ISP 串口下载 |
| 1 | 1 | SRAM（0x20000000） | 调试或特殊场景 |
正常开发时，我们都是将 BOOT0 拉低，让芯片从主 Flash 启动。这时代码从0x08000000开始，而Cortex-M 默认认为向量表在0x00000000。那为什么 Flash 地址是0x08000000，程序却能正常响应中断呢？
答案在SystemInit()函数和启动文件的配合：芯片上电后，首先从0x00000000（实际上在从 Flash 启动时，芯片内部会做地址映射，把0x08000000镜像到0x00000000，或者通过 VTOR 寄存器重新设定向量表位置）来读取向量。在 STM32F1 系列，Flash 内容会被映射到0x00000000，所以即使代码链接到0x08000000，也能正常启动。而在 STM32F2/F4/F7/H7 系列，你可能需要显式设置SCB->VTOR寄存器，将向量表偏移到正确的 Flash 地址。
如果你做的是 Bootloader + App 的结构，App 的链接地址通常会放在0x08008000或更靠后的位置，这时候必须在 App 启动代码的最开头设置VTOR = 0x08008000，否则中断向量表指向错误位置，一进中断就死机。
/* 在 App 启动早期设置向量表偏移 */ SCB->VTOR = 0x08008000;这个操作往往放在SystemInit()之后、main()之前。很多网上的教程只让你改链接器的IROM1起始地址，却忘提 VTOR 设置，结果就是 App 能跑 main，但一打开中断就 HardFault。这是我见过最多的“上电不正常”问题之一。
3. 启动文件逐行拆解：从 Reset_Handler 到 C 世界的钥匙
3.1 Reset_Handler 到底做了哪些事
以 STM32F103 系列的标准外设库启动文件为例，Reset_Handler的汇编代码核心逻辑如下（GCC 风格的 startup 文件，内容大同小异）：
Reset_Handler: ldr sp, =_estack /* 重新设置栈指针（防止之前被篡改） */ ldr r0, =LoopCopyDataInit /* 将 Flash 中的 .data 段复制到 RAM */ bl CopyDataInit /* 将 .bss 段清零 */ bl ZeroFillBss /* 调用 SystemInit 配置时钟 */ bl SystemInit /* 跳到 C 库入口，最终调用 main */ bl __main /* 对于 ARMCC 工具链 */ /* 或 bl main 对于某些直接链接的方式 */这里需要注意一个细节：在 MDK-ARM（ARMCC）环境下，__main是 C 库提供的初始化入口，它会先执行__scatterload完成 RW 段复制、ZI 段清零，然后调用__rt_entry，最后才进入main。而在 GCC 环境下，启动文件里通常会直接调用_start或 libg 提供的 CRT 启动例程。所以同一个.s文件在不同工具链下，后面几行的调用目标会略有不同，但它们的目标一致：把编译产物中的“有初值”的全局变量（.data 段）搬运到 RAM，把“无初值”的全局变量（.bss 段）清零，然后准备好 C 运行时环境。
3.2 段搬运的本质：Flash 太小，RAM 太贵
为什么非要把.data从 Flash 复制到 RAM？你可以这样理解：STOP 掉电后，Flash 的内容还在，但 RAM 的内容会丢失。全局变量的初值（比如int counter = 100;）是在编译时决定的，这个初值必须存放在非易失介质（Flash）里。但运行时，CPU 读写 RAM 的速度远快于 Flash，而且变量需要被修改，必须放在 RAM 中。因此，启动时就要把 Flash 里存着的初值“抄”到 RAM 中的变量地址上。
.bss段（未初始化或零初始化的全局变量）则不需要在 Flash 里占空间，启动时候直接往 RAM 对应区域填 0 就行。
这两步操作，在一些链接脚本（GCC）中分别对应：
/* 把 VMA（运行时地址）上的 .data 段复制到 LMA（加载地址） */ for (src = __data_load_start, dst = __data_start; dst < __data_end; src++, dst++) *dst = *src; /* 清零 .bss 段 */ for (dst = __bss_start; dst < __bss_end; dst++) *dst = 0;如果是裸机工程，不依赖 C 库的话，启动文件里就必须自己实现这两段逻辑。我以前见过一个精简版启动文件，为了省事没有做.bss清零，结果每个全局变量上电后的初始值都是随机的——那个问题排查了整整两天，后来才发现是启动文件里漏了ZeroFillBss。所以这里给个忠告：
不要尝试在启动文件里“偷懒”跳过
.bss清零。哪怕你的工具链默认会做，也一定要确认启动配置里确实包含了这一步。RTOS 任务栈、队列缓冲区、信号量控制块等大多依赖零初始化环境。
3.3 SystemInit：时钟系统是让一切跑起来的“心脏”
SystemInit()是 ST 官方固件库中的一个 C 函数，通常在system_stm32f1xx.c中。它做的事包括：
- 设置 Flash 等待周期（考虑到 CPU 主频和 Flash 读取速度的匹配）；
- 配置时钟源（HSE/HSI）、PLL 倍频系数、总线分频器（AHB/APB1/APB2）；
- 使能各外设时钟。
如果没有正确执行SystemInit，芯片会一直停留在内部 8MHz HSI 低速时钟状态，而你的USART波特率配置、SysTick延时参数，全部会按预期主频去计算，结果就是串口乱码、延时偏差巨大。所以启动流程里把时钟初始化放在段搬运之后、main()之前，是 ST 官方设计好的顺序，不要轻易打乱。
如果你是自己写链接脚本和启动文件，一定要记得在Reset_Handler里显式调用SystemInit。很多精简的startup_xxx.s只做了段搬运，忘了时钟初始化，导致程序能“跑”（因为 HSI 也能跑），但所有串口波特率都错得离谱。没错，这又是个典型的“能跑但不对劲”案例。
4. 链接脚本如何决定“代码去哪、变量去哪”
4.1 链接脚本是链接器的工作地图，不是可有可无的东西
在 GCC 工具链下，链接脚本（.ld）常常是新手最陌生的文件。它的作用，一句话概括：告诉链接器编译产物里每段内容应该放在哪个地址、按什么顺序排放。STM32 的链接脚本核心结构如下：
MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K } SECTIONS { .isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) /* 启动向量表必须保留 */ . = ALIGN(4); } > FLASH .text : { . = ALIGN(4); *(.text) /* 代码段 */ *(.rodata) /* 只读数据，如字符串常量 */ . = ALIGN(4); } > FLASH .data : AT(ADDR(.text) + SIZEOF(.text)) { . = ALIGN(4); __data_start = .; *(.data) /* 有初值的全局变量 */ __data_end = .; } > RAM .bss : { . = ALIGN(4); __bss_start = .; *(.bss) /* 零初始化变量 */ *(COMMON) __bss_end = .; } > RAM }理解这个脚本的关键在于区分LMA（加载时地址，Load Memory Address）和VMA（运行时地址，Virtual Memory Address）：
.text段直接在 Flash 里执行，它的 LMA 和 VMA 都是0x08000000段内的某个地址；.data段运行时必须放在 RAM 里，VMA 在 RAM 区间，但它的初始值存放在 Flash 里，所以 LMA 是在.text之后紧跟着的 Flash 地址。启动文件里的“段搬运”其实就是把数据从 LMA 复制到 VMA。
如果链接脚本里.data的 LMA 没有正确设置，链接器的__data_load_start符号就会指向错误的位置，你就算是写了复制代码，也复制的是垃圾数据。
4.2 为什么.isr_vector必须 KEEP
链接器在优化时，可能会把“没有显式引用”的段丢弃掉。而中断向量表只有 CPU 在复位或中断时才会间接使用，链接器并不知道这个“硬件引用”，所以如果不加KEEP，链接器可能在-gc-sections优化下把整个向量表“优化掉”。
加了KEEP(*(.isr_vector))后，链接器就会强制保留这部分内容，并确保它放在 Flash 的最前面。这里的KEEP不是可选项，而是必须项。我见过把 KEEP 去掉后，编译下载都没问题，但程序一上电就跑飞，因为入口点根本没找到向量表。
4.3 堆与栈：它们在链接脚本里如何共存
除了段定义，链接脚本还经常定义_Min_Heap_Size和_Min_Stack_Size：
_estack = ORIGIN(RAM) + LENGTH(RAM); /* 栈顶 */ _Min_Heap_Size = 0x200; _Min_Stack_Size = 0x400;注意：在 GCC 默认的 C 库启动代码中，栈空间和堆空间是放在.bss之后、RAM 末尾之前的。具体如何分布，取决于你用的启动文件和系统库实现。在使用 FreeRTOS 时，任务栈是从堆里动态分配的（如果开启configSUPPORT_DYNAMIC_ALLOCATION），所以_Min_Heap_Size需要足够容纳所有任务栈的总和。
如果你发现 FreeRTOS 的pvPortMalloc返回NULL，先检查链接脚本里的 Heap 大小，十有八九是不够用。这是“第一个任务没创建成功”的经典原因之一。
5. 从 main 到第一个任务：RTOS 的启动不是一句 API 那么简单
5.1 main 函数里发生了什么：一切从初始化开始
裸机程序到main()就算“启动完成”了，但 RTOS 程序到main()只是一个开始。以 FreeRTOS 为例，常规的main写法如下：
int main(void) { /* 硬件初始化 */ HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART1_UART_Init(); /* 创建任务 */ BaseType_t status; status = xTaskCreate(Task_LED, "LED", 128, NULL, 2, &Task_LED_Handle); configASSERT(status == pdPASS); status = xTaskCreate(Task_UART, "UART", 256, NULL, 1, &Task_UART_Handle); configASSERT(status == pdPASS); /* 启动调度器 */ vTaskStartScheduler(); /* 正常情况下不会运行到这里 */ while (1) { } }这段代码看着简单，但里面有三个容易被忽略的点：
- 每个任务栈大小怎么定？128 个“字”还是 128 个“字节”？FreeRTOS 里的
usStackDepth单位是字（4 字节），所以128表示 512 字节。很多人误把单位当成字节，栈不够时就出现栈溢出，导致任务莫名其妙跑飞。 - 优先级数值越大优先级越高，跟有的 RTOS 相反。新手常把这个搞反，结果低优先级任务抢占高优先级任务，系统卡死。
vTaskStartScheduler不会返回。如果它返回了，说明堆内存不足，无法创建 Idle 任务。此时configASSERT应该在xTaskCreate时就拦住问题了，但如果你哪怕关掉了断言，也会看到while(1)空转——程序既不跑任务，也不报错，这就是“启动失败”的典型表现。
5.2 调度器启动瞬间：SVC 异常与 PendSV 的协同
离开启动流程，深入第一个任务切换的关键机制。FreeRTOS 的vTaskStartScheduler最终会触发SVC（系统服务调用）异常，并在SVC_Handler中完成第一个任务的上下文加载。然后，调度器依赖SysTick 定时器产生周期性节拍，并在PendSV_Handler中完成任务切换。
这里有个很有意思的硬件设计：PendSV 异常是可挂起的，它可以被设置成最低优先级。这样，当高优先级中断打断任务时，如果任务切换请求（pendsv）发生了，它不会立刻抢占中断处理，而是等所有中断处理完才切换。这就保证了中断响应的实时性，也避免了在中断里做上下文切换的重活。
如果你是第一次在 STM32 上移植 FreeRTOS，一定会在启动文件里找到：
DCD SVC_Handler DCD DebugMon_Handler DCD PendSV_Handler DCD SysTick_Handler对应的中断处理函数必须注册到向量表中。如果启动文件里没有给PendSV和SysTick留口子，那调度器根本跑不起来。这个也是移植时最高频的报错点：编译能过，但运行到vTaskStartScheduler后程序就飞了。
5.3 第一个任务切换的完整路径
我们把整个路径走一遍，这样以后再出问题，你就知道该往哪查：
main()调用xTaskCreate若干次，每次都会在堆中分配一个TCB（任务控制块）和一块任务栈；- 任务创建时，启动代码会初始化任务栈为“伪寄存器帧”，看起来就像这个任务刚刚被打断一样。栈里从低地址到高地址依次保存了
R4-R11、R0-R3、R12、LR、PC、xPSR等寄存器值； vTaskStartScheduler创建 Idle 任务，然后触发SVC；- 在
SVC_Handler里，通过读取栈帧，恢复第一个任务的所有寄存器，并把PC指向任务的函数入口； - 第一个任务开始执行，此时 SysTick 也已启动，每隔一个 tick 产生中断，用于时间片轮转和延时管理；
- 当 tick 到达或有更高优先级任务就绪时，当前任务被挂起，处理器设置 PendSV 挂起位，等中断退出后进入
PendSV_Handler，完成寄存器保存和恢复。
从硬件视角看，整个过程其实就是**“通过异常机制来切换寄存器现场”**。Cortex-M 内核的自动压栈机制（进入中断时自动保存一部分寄存器，退出时自动恢复）为 RTOS 的上下文切换省了大量代码。这也是为什么 Cortex-M 处理器特别适合跑 RTOS 的原因之一。
6. 实际检查流程与启动阶段排查速查表
6.1 配置出现问题时的环境检查清单
当你在本地环境调试 STM32 启动问题时，下面这套“现场勘验”步骤基本能覆盖八成以上的场景：
- 先确认芯片上电后 PC 停在哪个地址：用调试器连接后，查看
PC寄存器的值。如果PC停在0x08000000附近且执行的是Reset_Handler，说明向量表没问题；如果PC乱跳或者停在某个 SRAM 地址，大概率是向量表配置或启动模式不对。 - 确认
VTOR（向量表偏移寄存器）：在 Cortex-M3/M4/M7 上，SCB->VTOR的默认值可能因芯片而异。如果程序是从 Bootloader 跳转到 App 的，记得要在跳转前或 App 启动处重新设置 VTOR。 - 确认
.data和.bss搬运是否完成：在调试器里查看全局变量的值是否符合预期。如果某个初始化为100的变量上电后却是随机值，说明.data段没有复制成功，检查启动文件里的复制循环是否被裁剪，以及链接脚本中 LMA 的定位是否正确。 - 查看
SystemInit是否执行：读一下RCC->CR寄存器的 PLLON 位或RCC->CFGR的 SW 位，确认时钟切换到了 PLL 而不是还停在 HSI。 - 如果需要跑 FreeRTOS，全局搜索
SVC_Handler和PendSV_Handler的定义是否存在：注意，当你在stm32f1xx_it.c里定义了SVC_Handler，但启动文件里也有一个弱定义的SVC_Handler时，需要确保链接器选择的是你写的那一个。如果没写强定义，弱定义只是个死循环，程序卡住也就顺理成章了。
6.2 常见“上电不跑”问题的快速对照表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 上电后完全无反应，Debug 不能连 | BOOT 引脚配置错误；芯片供电异常；晶振不起振 | 查 BOOT0 电平；量 VDD；示波器看 OSC_OUT |
能连 Debug，但 PC 停在0x00000000附近死循环 | VTOR 设置错误；向量表被裁剪 | 检查启动文件 KEEP；检查SCB->VTOR |
| 能跑 main，但全局变量初值乱 | .data段复制缺失 | 检查启动文件CopyDataInit和链接脚本符号 |
| 串口数据乱码，延时明显不对 | 时钟配置未执行 | 查SystemInit调用；查 PLL 配置 |
| 程序跑进 FreeRTOS 调度器后卡死 | SVC_Handler未定义或PendSV_Handler优先级错误 | 查中断向量表；查NVIC_SetPriority设置 |
xTaskCreate返回失败 | 堆内存不足 | 调大configTOTAL_HEAP_SIZE或修改链接脚本堆大小 |
| 任务栈溢出，系统复位 | 任务栈大小不足；usStackDepth单位写错 | 用uxTaskGetStackHighWaterMark查看水位线 |
6.3 调试启动问题时最实用的一招：半主机与调试打印的取舍
很多人在排查上电问题时习惯用串口打日志，但问题恰恰出在时钟或堆栈未初始化时，串口根本没法工作。这个时候我建议先把调试器连上，利用硬件调试能力在汇编窗口里单步执行。尤其观察启动文件的Reset_Handler入口处，看每一句汇编是否按预期走。
另外，如果怀疑.data、.bss搬运有问题，可以在启动文件里临时打一个断点，比如在bl SystemInit这一行设置断点，然后检查_data_start、_data_end、_bss_start、_bss_end的值，再用内存窗口确认搬运前后 RAM 区域的数据变化。这样你能非常直观地看到问题出在哪一段。
还有个小技巧：开启-fno-common编译选项。如果某些工具链默认允许未定义的全局变量“弱合并”进 COMMON 段，那么.__bss_end的计算可能跟你预期不同，导致零初始化时覆盖了不该覆盖的内容。开启这个选项可以避免这种“幽灵全局变量”的迷惑行为。
7. 个人经验里的几个高频翻车点
搞启动流程这几年，最常被问到的几个问题，几乎都集中在下面这几个“细节黑洞”里，我把它们单独拉出来说说。
7.1 启动文件里的SystemInit被 “优化” 没了
用 Keil 工程时，如果使用armcc和microlib，有时会因为优化选项（-O0/-O1/-Ofast）的不同，导致启动文件里对SystemInit的引用方式不同。一般标准库不会出这种问题，但如果你是自己裁剪的启动文件，并且把SystemInit声明为 static，编译器可能会在较高优化级别下把“无外部副作用”的函数调用给内联或者删掉。解决办法是给SystemInit加__attribute__((used))或在调用处加volatile强制引用。
7.2 从 Bootloader 跳 App 时，关闭全局中断的时机
如果做 IAP 升级，Bootloader 在跳转到 App 前，必须：
- 关闭全局中断（
__disable_irq()）； - 关掉 SysTick、外设中断；
- 把中断向量表切换到 App 的起始地址；
- 设置 MSP 为 App 的栈顶；
- 然后再跳转。
很多人只做了后两步，没关中断，结果跳转过程中系统 tick 或某个外设中断一进来，CPU 仍然执行旧的向量表，直接跑飞。我见过很多次这种“App 一启动就卡死”的案例，都是中断没关干净的锅。
7.3 用调试器下载后能跑，断电重上电就不跑
这种现象十有八九跟调试器拉高了 BOOT0 以外的一些引脚无关，而是跟“调试模式下 RAM 中的值”有关。Debug 模式下，调试器会初始化部分 RAM 或外设，程序可能依赖了这些“脏值”；而实际复位上电时，RAM 是完全随机的，所以启动路径不同。
如果遇到这个现象，建议做一次“全片擦除后重新烧录”，并设置直接从复位启动（不要通过调试器保持复位状态），再观察现象。很多时候是调试器把程序加载到了 RAM，或者把向量表指针改到了乱七八糟的地址。
8. 把它串成一条线：从复位向量到第一个任务，整个流程到底意味着什么
把前面所有内容串起来，STM32 上电启动的完整链路是这样的：
- 芯片上电复位，硬件自动加载
0x00000000处的 SP 和0x00000004处的 PC； - PC 跳到
Reset_Handler，先将 SP 重新设置到栈顶； - 启动文件完成
.data段从 Flash 到 RAM 的复制，.bss段清零； - 调用
SystemInit配置时钟树； - 调用 C 库初始化（或直接
main）； main里完成外设初始化和 RTOS 对象创建；vTaskStartScheduler触发 SVC 异常，PendSV 完成第一次任务切换；- 第一个任务开始运行，SysTick 周期性驱动调度器。
这整条链路上的任何一环断裂，都会导致程序无法正常运行。但有意思的是，很多断裂并不会直接让你看到错误，而是表现为“全局变量随机值”“串口乱码”“任务不调度”“跑一会儿就死机”等间接现象。
我个人在实际操作中的体会是：调试启动问题，千万别盯着应用层代码反复猜，一定要从启动文件的指令流一步步看起。把你手上的调试器用到极致，单步汇编、看寄存器组、开内存窗口，这些动作比加一百句日志都管用。等这条链路你彻底走熟了，以后排查任何 STM32 上的疑难杂症，都会觉得心里有底得多。
最后再分享一个小技巧：平时可以把自己用到的芯片的链接脚本和启动文件各打印一份放在工位旁边，遇到启动相关的问题先翻这两份文件。时间长了，你会发现它们不是“工具链自动生成的垃圾文件”，而是整个嵌入式系统最核心的“地图”。理解它们，比背一百个外设寄存器都有用。
