第四章 启动流程分析：从复位向量到main函数，MCU的启动过程全解析

大家好，我是你们的嵌入式系统讲师。今天我们来聊聊MCU的启动流程。说实话，这个主题我讲了不下百遍，但每次都有新感悟。你想想看，一个芯片从通电到执行你的代码，中间到底发生了什么？

很多初学者觉得启动就是“上电→跑main”，太天真了。我当年第一次做STM32项目时，就因为没搞懂启动流程，debug了整整三天——程序死活不跑，最后发现是中断向量表没放对位置。嗯，从那以后，我再也不敢轻视这“短短几毫秒”的启动过程了。

4.1 复位向量：MCU的第一口“奶”

MCU上电后，CPU会先干什么？说白了，它得知道自己从哪里开始执行代码。这个“起点”就是复位向量。

以ARM Cortex-M系列为例，芯片上电后，硬件会自动做两件事：

  1. 从地址 0x00000000 读取栈顶指针（MSP）
  2. 从地址 0x00000004 读取复位中断服务函数地址

然后CPU直接跳转到这个地址执行。这就是整个启动过程的“第一口奶”。

核心要点：复位向量必须放在Flash的起始位置。如果放错了，芯片要么跑飞，要么死机。

我在项目中遇到过一种情况：用IAR编译时默认把中断向量表放在了0x8000000（STM32的Flash起始地址），但Bootloader却从0x8000000开始执行。结果一上电，Bootloader直接覆盖了向量表，导致应用程序的中断全部失效。这个问题查了我两天，最后发现是链接脚本里向量表地址没对齐。

4.2 启动文件：那些你看不见的“幕后英雄”

每个MCU项目都有一个启动文件，通常叫 startup_xxx.s 或 crt0.s。这个文件是汇编写的，很多人觉得它晦涩难懂，直接跳过。我个人习惯是：每换一个芯片平台，第一件事就是读它的启动文件。

启动文件主要干了这几件事：

  • 定义中断向量表——把每个中断的入口地址按顺序排好
  • 初始化栈指针——给C语言的函数调用准备好栈空间
  • 调用SystemInit——配置系统时钟、PLL等基础硬件
  • 搬运数据段——把Flash里的初始值复制到RAM中
  • 清零BSS段——把未初始化的全局变量清零
  • 跳转到main——终于轮到你的代码了

你可能会问：“为什么非要汇编写？C语言不行吗？”

原因很简单：在C语言环境还没建立起来之前（比如栈指针没设好、全局变量没初始化），你根本没法调用C函数。所以必须用汇编完成这些“自举”工作。

小技巧：如果你用GCC工具链，可以试试在链接脚本里加上 --print-memory-usage，看看各个段的大小。我经常用这个来检查BSS段是否被正确清零了。

4.3 从复位到main：逐行拆解启动流程

好，我们来一步步拆解。以STM32F103为例，它的启动流程大致如下：

步骤 地址/操作 说明
1 0x00000000 读取栈顶指针，赋值给MSP
2 0x00000004 读取Reset_Handler地址，跳转执行
3 Reset_Handler 调用SystemInit()配置时钟
4 __main / _start 搬运.data段，清零.bss段
5 main() 执行用户代码

你看，从复位到main，其实就5步。但每一步都藏着坑。

举个例子，SystemInit() 这个函数。很多芯片厂商的库函数里，SystemInit会默认把HSE（外部高速晶振）使能，然后切换到PLL。如果你的板子上没焊晶振，或者晶振起振慢，程序就会卡在这里。我曾经调试一块板子，上电后LED死活不闪，最后用示波器一量——晶振根本没起振。SystemInit里有个超时等待，但默认超时时间太短了。

注意：如果你自己写Bootloader，一定要在跳转到应用程序前，把中断向量表重新映射到应用程序的起始地址。否则应用程序里的中断一个都进不去。

4.4 数据段和BSS段：为什么需要“搬运”和“清零”？

这个问题我经常被问到：“为什么全局变量不能直接在Flash里用？”

原因很简单：Flash是只读的，而全局变量在运行时可能会被修改。所以编译器会把有初始值的全局变量放在Flash里（.data段），然后在启动时复制到RAM中。那些没初始化的全局变量（.bss段），则直接在RAM里清零。

看个代码示例：

// 这个变量会被放在.data段，启动时从Flash复制到RAM
int g_counter = 100;

// 这个变量会被放在.bss段，启动时在RAM中清零
int g_buffer[1024];

void main(void) {
    // 此时g_counter已经是100，g_buffer全是0
    // 你可以放心使用了
    g_counter++;
}

你想想看，如果没有启动文件帮你做这些事，你连个全局变量都不敢用。这就是为什么我说启动文件是“幕后英雄”。

4.5 常见启动问题与避坑指南

做嵌入式这么多年，我总结了几条启动相关的“血泪教训”：

  • 栈溢出——启动文件里定义的栈大小太小，递归调用一深就崩。我建议至少给2KB，RTOS环境下给4KB以上。
  • 中断向量表对齐——Cortex-M要求向量表按512字节对齐。如果你用自定义链接脚本，记得检查对齐。
  • 时钟配置失败——SystemInit里如果HSE起振失败，很多库会死循环。最好加个超时或回退到HSI。
  • Bootloader跳转——跳转前要关掉所有中断，复位外设状态，否则应用程序一启动就进中断，然后崩溃。

避坑指南：我曾经在一个量产项目里，因为启动文件里的栈大小设成了256字节，导致某个模块的printf函数一调用就死机。查了三天，最后用JTAG单步跟踪才发现是栈溢出了。从那以后，我每个项目都会在启动文件里显式注释栈大小，并留够余量。

4.6 裸机 vs RTOS：启动流程有什么不同？

裸机程序启动到main就结束了。但RTOS不一样——main函数里通常要初始化内核、创建任务、启动调度器。

RTOS的启动流程多了几步：

  1. 硬件初始化（时钟、外设）
  2. RTOS内核初始化（就绪队列、定时器、信号量等）
  3. 创建至少一个任务（通常是main任务或空闲任务）
  4. 调用 vTaskStartScheduler() 启动调度器
  5. 调度器接管CPU，开始任务切换

注意：一旦调度器启动，main函数就不再执行了。或者说，main函数所在的上下文会被挂起，CPU开始执行最高优先级的任务。

我建议你在写RTOS应用时，把硬件初始化放在main函数的最前面，然后再创建任务。这样即使调度器启动失败，你还能通过串口打印错误信息。

4.7 总结：启动流程的“灵魂三问”

最后，我给大家留三个问题，你可以用来检验自己是否真的理解了启动流程：

  1. 如果我把复位向量指向一个没有初始化的RAM地址，会发生什么？
  2. 为什么启动文件里要先设栈指针，再跳转？顺序能反过来吗？
  3. 在RTOS环境下，main函数返回了会怎样？

这三个问题，我在面试时经常问。能答上来的，基本就是真的懂了。

好了，这一章就到这里。下一章我们会深入分析中断向量表的布局，以及如何手动修改它来实现Bootloader。到时候见。

← 上一章 📖 返回目录 下一章 →