4、系统启动流程：从芯片上电到Bootloader再到应用程序的完整链路
好，咱们今天聊一个非常核心的话题——系统启动流程。
说白了，就是芯片从按下电源键（或者上电复位）那一刻起，到最终跑起你的应用程序，中间到底经历了什么。我见过不少工程师，写了好几年应用层代码，但一问到启动流程就含糊其辞。嗯，这其实是个坑，尤其是做OTA升级，你不把启动链路吃透，后面调试起来会非常痛苦。
4.1 芯片上电那一刻发生了什么？
芯片上电，不是瞬间就“活”过来的。它有一个严格的时序。
我个人习惯把上电后的第一阶段叫做“硬件自举”。这时候CPU核心还没开始跑代码，硬件电路在做三件事：
- 电源稳定：内部LDO（低压差线性稳压器）开始工作，把外部输入的电压转换成内核需要的1.2V、1.8V等。这个需要时间，大概几毫秒到几十毫秒。
- 时钟起振：芯片内部的RC振荡器或者外部晶振开始震荡。我记得有一次项目，晶振起振时间太长，导致系统启动超时，排查了好久才发现是匹配电容选错了。
- 复位释放：当电源和时钟都稳定后，硬件会释放复位信号。这时候CPU才真正开始“睁眼”。
关键点：芯片上电后，PC（程序计数器）指针会指向一个固定的地址。这个地址通常叫做“复位向量”。对于ARM Cortex-M系列，这个地址就是0x00000000（或者通过映射机制重映射后的地址）。
4.2 从复位向量到启动文件
CPU拿到复位向量后，会做两件事：
- 从0x00000000处读取栈顶指针（MSP，主堆栈指针）。
- 从0x00000004处读取复位中断服务函数地址，然后跳转过去执行。
你想想看，这不就是一张“地图”吗？芯片上电后第一件事就是看地图，找到入口。
这个入口，通常就是启动文件（startup_xxx.s）里的 Reset_Handler。启动文件是汇编写的，它负责：
- 初始化全局变量（把.data段从Flash拷贝到RAM）。
- 清零BSS段（未初始化的全局变量）。
- 初始化堆栈。
- 调用
SystemInit()函数配置系统时钟。 - 最后，跳转到
main()函数。
我的经验：很多初学者以为 main() 是程序的起点。其实不是，main() 之前已经干了一大堆活。如果你在 main() 之前就访问了全局变量，而启动文件还没完成初始化，那程序必挂。我曾经在某个项目中，因为启动文件里BSS段清零的代码被优化掉了，导致全局变量初始值全是乱的，查了整整两天。
4.3 Bootloader的介入时机
好，现在问题来了：如果没有Bootloader，启动文件直接跳转到应用程序的 main()，一切正常。但有了OTA升级，我们就需要Bootloader在中间插一脚。
Bootloader的启动时机，就在启动文件执行完毕之后、应用程序的main()执行之前。或者说，更准确一点：Bootloader本身就是一个独立的程序，它有自己的启动文件。芯片上电后，先执行Bootloader的启动文件，然后进入Bootloader的 main()。
在Bootloader的 main() 里，它会做几件事：
- 检查是否有升级请求（比如某个GPIO引脚电平、或者Flash中的标志位）。
- 如果有，进入升级模式，接收新固件，写入Flash。
- 如果没有，就跳转到应用程序的入口。
跳转的关键：Bootloader不能直接调用应用程序的 main() 函数。因为应用程序有自己的中断向量表，它期望从自己的复位向量开始。正确的做法是：
/* 伪代码：Bootloader跳转到应用程序 */
typedef void (*app_entry_t)(void);
uint32_t app_stack_top = *(uint32_t*)APP_FLASH_ADDR; // 读取应用程序的栈顶指针
app_entry_t app_entry = (app_entry_t)(*(uint32_t*)(APP_FLASH_ADDR + 4)); // 读取复位向量
/* 设置主堆栈指针 */
__set_MSP(app_stack_top);
/* 关闭全局中断（重要！） */
__disable_irq();
/* 跳转 */
app_entry();避坑指南：我曾经在跳转前忘记关闭外设中断，结果应用程序一启动，一个未处理的外设中断就触发了，而应用程序的中断向量表还没准备好，直接跑飞。所以，跳转前一定要 __disable_irq()，并且把所有外设时钟关掉，把外设寄存器恢复到复位状态。
4.4 应用程序的启动与中断向量表重映射
应用程序被Bootloader跳转后，它自己也会执行一遍启动文件。但这里有个问题：应用程序的中断向量表，默认是放在Flash的起始地址（0x08000000）的。如果Bootloader占用了前面的空间，应用程序的向量表就得往后挪。
比如，Bootloader占用了0x08000000 ~ 0x0800FFFF（64KB），应用程序从0x08010000开始。那么应用程序的启动文件里，必须把中断向量表的偏移量设置好。
在ARM Cortex-M上，这通过 SCB->VTOR 寄存器来实现：
/* 在应用程序的SystemInit()或启动文件中设置 */
#define APP_BASE_ADDR 0x08010000
SCB->VTOR = APP_BASE_ADDR;如果不设置这个偏移量，中断来了之后，CPU会去0x08000000找中断向量表，找到的是Bootloader的，而不是应用程序的。那结果就是——中断响应完全乱套。
我的建议：在写应用程序的链接脚本（.ld文件或.scf文件）时，就把Flash的起始地址和长度改掉。比如STM32的链接脚本里，FLASH (rx) : ORIGIN = 0x08010000, LENGTH = 192K。这样编译出来的应用程序，天然就知道自己的向量表在0x08010000，不需要在代码里手动改VTOR。但为了保险，我一般还是在 SystemInit() 里再写一遍VTOR赋值。
4.5 完整启动链路总结
好了，我们把整个链路串起来，画个流程图（用文字描述）：
- 上电复位：硬件稳定电源和时钟，释放复位信号。
- 读取复位向量：CPU从0x00000000（或映射地址）读取栈顶指针和复位中断函数地址。
- 执行Bootloader启动文件：初始化全局变量、配置时钟。
- 进入Bootloader的main()：检查升级标志，决定是升级还是跳转。
- 跳转到应用程序：设置MSP，关闭中断，跳转到应用程序的复位向量。
- 执行应用程序启动文件：再次初始化全局变量（注意：此时RAM中的全局变量可能已经被Bootloader修改过，需要重新初始化）。
- 设置VTOR：将中断向量表偏移到应用程序所在的Flash地址。
- 进入应用程序的main()：开始执行业务逻辑。
核心要点：整个启动链路中，最脆弱的一环就是第5步——跳转。跳转前要清理干净现场，跳转后要确保应用程序能正确接管硬件。我见过太多因为跳转时没关中断、没复位外设导致的诡异问题。
4.6 一个实际案例
我记得有一次做智能家居网关的OTA升级。Bootloader和应用程序都跑在STM32F407上。测试时发现，升级完成后，应用程序启动后Wi-Fi模块死活连不上网。
排查了很久，最后发现是Bootloader在跳转前，没有把SPI外设的DMA通道复位。应用程序启动时，DMA还在处理上一次传输的残留数据，直接把Wi-Fi模块的寄存器写乱了。
从那以后，我养成了一个习惯：在Bootloader的跳转函数里，写一个“硬件全复位”的循环，把所有用到的外设时钟都关掉，再把对应的外设寄存器手动清零。虽然代码多了几行，但心里踏实。
小技巧：如果你用的是HAL库，可以调用 HAL_RCC_DeInit() 和 HAL_DeInit() 来快速复位大部分外设。但注意，这两个函数不是万能的，有些外设的私有寄存器还得自己清。
嗯，关于系统启动流程，今天就聊这么多。说白了，就是从硬件到软件的一个接力赛。每一棒都要交接清楚，否则就会掉棒。下一节我们会深入Bootloader的跳转细节，包括如何安全地传递参数给应用程序。