ARM Cortex-M MCU启动流程详解：从复位向量到main函数的隐秘步骤

面试官问：main() 之前发生了什么？看完这篇，绝对加分！

一、引言：戳破“main 即开始”的幻象

相信每一位嵌入式初学者，在打开第一个单片机工程时，目光都会不由自主地落在这行代码上：

int main(void)
{
    // 你的代码从这里开始...
}

于是，一个根深蒂固的印象就此形成：程序是从 main() 函数开始执行的。

但请稍等，思考下面三个问题：

1. 全局变量 int a = 10; 是谁把 10 赋给它的？
2. 未初始化的全局变量 int b; 为什么默认是 0？
3. 堆栈指针（SP）是谁设置的？CPU 怎么知道栈在哪里？

如果这些问题让你感到困惑，那说明你或许也掉进了 main() 的认知陷阱。

真相是：main() 函数只是整个程序执行的“正片”，而在此之前，有一段至关重要的“片头曲”——启动文件（Startup File）。它默默承担着初始化硬件、搬运数据、清理内存的重任。如果不了解它，当你遇到“程序跑飞”、“HardFault”、“内存越界”等底层 Bug 时，往往会束手无策。

今天，就让我们一起揭开这段“隐秘角落”的神秘面纱。

二、上电瞬间：硬件的“条件反射”

当你按下复位键或给 MCU 上电的那一刻，芯片内部发生了什么？

答案可能出乎你的意料：CPU 内核做的第一件事并不是执行任何代码，而是执行硬件预设的“条件反射”。

两个关键动作

以 ARM Cortex-M 系列内核为例，复位后 CPU 会自动完成两件事：

图1：ARM Cortex-M内核复位后的两个关键硬件动作

这两个动作是硬件自动完成的，不需要任何软件参与。这也解释了为什么中断向量表必须放在 Flash 的起始位置——因为 CPU 的设计逻辑就是固定从 0x0000 0000 地址开始读取。

内存映射示意

图2：Flash内存起始处的中断向量表布局

生活比喻

想象一下早上起床的场景：

1. 穿鞋子（设置 SP）：起床第一件事是把脚伸进拖鞋，有了“立足之地”才能开始行动。
2. 看日程表（设置 PC）：然后看一眼床头的日程表第一行，明确今天要做什么。

MCU 复位后的逻辑与此类似：先设置好栈（知道数据该往哪里放），再跳转到复位处理函数（知道代码该从哪里执行）。

三、主角登场：汇编启动文件详解

现在，让我们打开工程目录，找到那个你可能从未仔细阅读过的文件——startup_stm32xxx.s。

这个 .s 后缀的汇编文件，就是 MCU 启动的“导演脚本”。别被汇编语言吓到，其实它的核心逻辑非常清晰。

第一幕：定义堆栈空间

; 栈空间定义
Stack_Size      EQU     0x00000400      ; 1KB 栈空间

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   Stack_Size
__initial_sp                             ; 栈顶标号

; 堆空间定义
Heap_Size       EQU     0x00000200      ; 512B 堆空间

                AREA    HEAP, NOINIT, READWRITE, ALIGN=3
__heap_base
Heap_Mem        SPACE   Heap_Size
__heap_limit

解读：

• Stack_Size EQU 0x00000400 定义了 1KB 的栈空间。这是给 CPU 预留的“背包”，函数调用时的返回地址、局部变量都存放在这里。
• 重要警告：如果你的程序递归层数过深或局部数组太大，栈空间就会溢出（Stack Overflow），这将直接触发 HardFault 硬件错误，导致程序崩溃。

第二幕：中断向量表

                AREA    RESET, DATA, READONLY
                EXPORT  __Vectors

__Vectors       DCD     __initial_sp            ; 栈顶地址
                DCD     Reset_Handler           ; 复位中断
                DCD     NMI_Handler             ; 不可屏蔽中断
                DCD     HardFault_Handler       ; 硬件错误
                DCD     MemManage_Handler       ; 内存管理错误
                DCD     BusFault_Handler        ; 总线错误
                DCD     UsageFault_Handler      ; 用法错误
                ; ... 更多中断向量 ...
                DCD     SysTick_Handler         ; 系统滴答定时器
                ; ... 外设中断 ...

解读：

• DCD 指令意为“Define Constant Data”，用于定义一个32位常量。
• 这张表就是 CPU 的“中断通讯录”，每个中断源都有自己固定的“门牌号”。当中断发生时，CPU 会根据中断号查表，跳转到对应的处理函数。
• 切记：这张表的顺序是由 ARM 架构严格规定的，不能随意更改！

第三幕：Reset_Handler —— 真正的软件执行起点

                AREA    |.text|, CODE, READONLY

Reset_Handler   PROC
                EXPORT  Reset_Handler   [WEAK]
                IMPORT  SystemInit
                IMPORT  __main

                LDR     R0, =SystemInit
                BLX     R0              ; 调用 SystemInit
                LDR     R0, =__main
                BX      R0              ; 跳转到 __main
                ENDP

这是整个启动过程的核心！ 让我们逐行解读：

第一步：调用 SystemInit

LDR     R0, =SystemInit
BLX     R0

SystemInit 是一个 C 函数，通常在 system_stm32xxx.c 中定义。它的主要任务包括：

• 配置系统时钟（例如开启 PLL，将主频提升至最高运行频率）
• 配置 Flash 访问的等待周期
• 初始化浮点运算单元 FPU（如果芯片支持）

为什么要在 main 之前配置时钟？ 因为后续所有的软件操作，包括最重要的变量初始化，都需要 CPU 在正确的时钟频率下工作。

第二步：跳转到 __main

LDR     R0, =__main
BX      R0

注意：这里跳转的目标是 __main（带两个下划线），而不是用户编写的 main 函数！

__main 是 ARM C 运行时库（如 armcc 或 gcc 的 libc）提供的初始化入口。它会完成一系列关键工作：

1. 完成 .data 段的数据搬运（下一节详解）
2. 完成 .bss 段的清零
3. 初始化 C/C++ 运行时环境
4. 最后，才会调用用户编写的 main() 函数

四、数据搬运工：.data 与 .bss 段的“乾坤大挪移”

这是整个启动过程中最精妙也最容易让人困惑的部分，也是面试中的高频考点。

先搞清楚：Flash 与 RAM 的分工

图3：Flash与RAM存储器的不同特点及存放内容

当你写下这样的代码时：

int global_a = 100;     // 已初始化的全局变量
int global_b;           // 未初始化的全局变量
const int global_c = 200; // 常量

编译后，它们会被链接器安排到不同的存储区域：

• global_a 的初始值 100 被存放在 Flash 中，但变量本身在程序运行时位于 RAM。
• global_b 只需要在 RAM 中预留空间，其初始值应为0。
• global_c 是常量，直接“居住”在Flash中，无需搬移到RAM。

搬运过程图解

图4：启动过程中.data段从Flash复制到RAM，.bss段在RAM中清零的过程

两个关键步骤

步骤一：搬家（.data 段初始化）

启动代码会执行类似下面的操作（实际由库函数以汇编实现）：

// 伪代码，示意流程
extern uint32_t _sidata;  // Flash 中 .data 段初始值的起始地址
extern uint32_t _sdata;   // RAM 中 .data 段的起始地址
extern uint32_t _edata;   // RAM 中 .data 段的结束地址

uint32_t *src = &_sidata;
uint32_t *dst = &_sdata;
while (dst < &_edata) {
    *dst++ = *src++;  // 逐字（32位）复制
}

这就是为什么 int a = 100; 在 main 函数执行前，其值就已经是 100 了！

步骤二：打扫（.bss 段清零）

// 伪代码，示意流程
extern uint32_t _sbss;  // .bss 段在RAM中的起始地址
extern uint32_t _ebss;  // .bss 段在RAM中的结束地址

uint32_t *dst = &_sbss;
while (dst < &_ebss) {
    *dst++ = 0;  // 将整段内存清零
}

这就是为什么未初始化的全局变量 int b; 其默认值是 0！

生活比喻

想象你要搬进一套新房子：

1. 搬家：把旧房子（Flash）里的家具（有初值的变量）按照图纸，一件件搬到新房子（RAM）里对应的位置。
2. 打扫：新房子里那些预留的空房间（未初始化的变量），全部彻底打扫干净（清零），确保没有遗留任何垃圾数据。

灵魂拷问：为什么局部变量是随机值？

void foo() {
    int local_var;  // 未初始化，其值是随机的！
    printf(“%d”, local_var);  // 可能输出任何不可预知的值
}

因为局部变量在栈上分配，而栈空间在启动时并不会被自动清零！它的值可能是上一次函数调用结束后留下的“遗迹”。这也解释了为什么C语言教材反复强调：局部变量一定要初始化后再使用！

五、C++ 的秘密与最后的跳转

如果你的嵌入式项目使用 C++，那么在 main() 之前还会多出一个“隐藏关卡”。

C++ 的额外任务：全局对象构造

考虑下面这段代码：

class Logger {
public:
    Logger() {
        // 初始化串口、打开日志文件...
        uart_init();
    }
};

Logger g_logger;  // 全局对象

int main() {
    g_logger.log(“Hello World”);
    // ...
}

问题来了：g_logger 对象的构造函数是什么时候被调用的？

答案：在 main() 函数被调用之前！

编译器会生成一个特殊的全局对象初始化列表。启动代码在完成C环境初始化后，会遍历这个列表，逐个调用所有全局对象的构造函数。

启动流程（C++ 版）：
Reset_Handler
    ↓
SystemInit（配置时钟）
    ↓
__main
    ↓
.data 复制、.bss 清零
    ↓
★ 调用全局对象构造函数 ★  ← C++ 独有步骤
    ↓
main()

这就是为什么 C++ 项目的启动时间通常比纯 C 项目略长一点——因为它多了构造全局对象这一步。

终极一跃：进入 main()

所有前置工作准备就绪后，__main 函数的最后会执行这样一条指令：

BL      main    ; 跳转到用户的 main 函数

至此，MCU 的启动流程全部结束，程序的控制权终于交到了开发者手中。你在 main() 函数里写下的第一行代码，此刻才真正开始执行。

六、总结：从上电到 main 的完整旅程

让我们用一张完整的流程图来总结 MCU 从复位到执行 main 函数的全过程：

图5：MCU从复位到执行main函数的完整启动流程图

面试回答模板

面试官：请问 main() 函数之前发生了什么？

你：MCU 复位后，硬件首先从地址 0x0000 0000 读取初始栈顶指针（MSP）来初始化 SP 寄存器，然后从 0x0000 0004 读取复位向量地址并跳转到 Reset_Handler。接着，软件启动代码会调用 SystemInit 函数来配置系统时钟，再跳转到C运行时库的 __main 函数。__main 会完成 .data 段（已初始化全局变量）从 Flash 到 RAM 的搬运，以及 .bss 段（未初始化全局变量）在 RAM 中的清零工作。如果是 C++ 项目，在此之前还会调用所有全局对象的构造函数。最后，才会跳转到用户的 main() 函数。

动手实践建议

理解理论后，实践能加深印象。建议你立刻打开自己的嵌入式工程：

1. 找到启动文件：在工程中搜索 startup_stm32*.s 文件，打开它，对照本文的讲解仔细阅读 Reset_Handler 部分的汇编代码。
2. 查看链接脚本：找到工程的链接脚本文件（通常是 .ld 或 .sct 后缀），看看 .data、.bss 等段的具体定义和地址分配。
3. 调试验证：在调试器中，于 main() 函数的第一行设置断点，单步执行并观察全局变量是否在进入 main 前已被正确初始化。

写在最后

深入理解 MCU 的启动流程，是每一位嵌入式开发者从“会使用”到“精通”的必经之路。当你未来遇到 HardFault、栈溢出、变量值莫名被改等棘手问题时，这些关于启动和内存管理的底层知识将成为你定位和解决问题的利器。

希望本文的梳理对你有所帮助。如果你想系统性地学习更多嵌入式开发知识，欢迎前往云栈社区与广大开发者一起交流探讨。

---

往期推荐

• 嵌入式软件模块解耦进阶：构建高内聚、低耦合的系统架构
• 给你的设备做一套“砖不死”的 OTA 升级方案
• STM32中的双栈指针：MSP和PSP是如何切换的？