为什么复位后不能直接运行 main 函数？ 硬件初始化、栈、向量表、全局变量这些谁来准备？

难度★本文首发于我的嵌入式技术公众号「OneChan」未经授权禁止转载。先做一个小实验。打开 Keil新建一个 Cortex-M3 工程写一个最简单的main函数intmain(void){inta1;intb2;intcab;returnc;}编译下载运行。一切正常。现在把启动文件startup_xxx.s从工程里删掉再编译。编译器报错了Error: L6218E: Undefined symbol __initial_sp (referred from entry2.o). Error: L6218E: Undefined symbol Reset_Handler (referred from entry2.o).连编译都过不去。这说明一件事哪怕你写的是纯 C 代码哪怕你一个寄存器都不想碰芯片上电之后在main函数的第一行代码执行之前已经有大量工作必须由别人替你完成。这个人就是启动文件。那它到底干了什么为什么这些事情不能让main自己来一、芯片复位那一瞬间发生了什么Cortex-M3 上电或复位时硬件只自动做三件事不多不少把0x00000000地址处的 32 位值读出来塞进 MSP主堆栈指针。把0x00000004地址处的 32 位值读出来塞进 PC程序计数器。从 PC 指向的地址开始取指令执行。就这三件。没了。不初始化外设时钟不设置 Flash 等待周期不给全局变量赋初值不清零未初始化变量。这些事硬件统统不管。你可能会问那0x00000000和0x00000004这两个地址里存的是啥答案是——向量表的前两项。地址内容含义0x00000000栈顶地址高地址复位后自动装入 MSP0x00000004Reset_Handler函数地址复位后自动装入 PC所以复位流程本质上是硬件取 0x00000000 → MSP 硬件取 0x00000004 → PC CPU 开始执行 Reset_HandlerReset_Handler是你写的吗不是。它在启动文件里由汇编写成是芯片复位后执行的第一段用户代码。那Reset_Handler又干了什么才轮到main二、从Reset_Handler到main中间隔着四座大山打开启动文件找到Reset_Handler你会看到类似这样的代码以 Keil 为例Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT SystemInit IMPORT __main LDR R0, SystemInit BLX R0 LDR R0, __main BX R0 ENDP翻译成人话调用SystemInit初始化系统时钟、Flash 延迟、外设总线。跳转到__main这是 ARM C 库的入口。__main做完剩下的脏活累活后才调用你的main。SystemInit比较好理解就是配置时钟。不配的话芯片可能跑在 8MHz 内部 RC 振荡器上而不是 72MHz 外部晶振。真正让人困惑的是__main。它不是你的main。它是 ARM 标准 C 库里的一个函数藏在编译器的背后。它干了三件至关重要的事把.data段从 Flash 复制到 RAM把.bss段在 RAM 里全部清零如果用了 C调用全局对象的构造函数不干这三件事你的main连门都出不了。三、.data段为什么全局变量初始值要“搬一次家”看这个例子intg_counter100;// 带初始值的全局变量intmain(void){g_counter;while(1);}g_counter的初始值100存在哪答案Flash 里。因为 RAM 断电就丢数据所以变量的初始值必须在掉电不丢的 Flash 里存一份。但问题是——程序运行时要修改g_counter而 Flash 不能直接写。所以启动代码必须做一件事把初始值从 Flash 搬运到 RAM。这个过程就叫“.data段拷贝”。在分散加载文件.sct里这对应两个地址概念地址说明加载地址Flash如0x08001000初始值存放处只读执行地址RAM如0x20000000运行时变量所在地可读写启动代码里有一段汇编循环大致长这样CopyData: LDR R1, __data_load ; Flash 中的起始地址 LDR R2, __data_start ; RAM 中的起始地址 LDR R3, __data_end ; RAM 中的结束地址 CopyLoop: CMP R2, R3 BEQ CopyDone LDR R0, [R1], #4 ; 从 Flash 读 4 字节地址递增 STR R0, [R2], #4 ; 写到 RAM地址递增 B CopyLoop CopyDone:如果你直接运行main而没有这段拷贝代码会发生什么g_counter的初始值会是一个随机数RAM 上电后的残留值。你的程序从第一行开始就在用垃圾数据计算。这不是 bug这是灾难。四、.bss段为什么未初始化变量必须清零再看这个intg_uninit;// 没有初始值的全局变量intmain(void){if(g_uninit0){// 你以为它一定是 0}}C 标准规定未初始化的全局变量在进入main之前必须为 0。但这个 0 是谁写的硬件不会帮你清零 RAM。启动代码必须手动把.bss段所在的 RAM 区域全部填 0。代码类似这样ZeroBss: LDR R1, __bss_start LDR R2, __bss_end MOV R0, #0 ZeroLoop: CMP R1, R2 BEQ ZeroDone STR R0, [R1], #4 B ZeroLoop ZeroDone:如果不清零呢g_uninit的值是随机的。它可能在你的板子上恰好是 0测试通过。到了客户手里上电后它是 0xDEADBEEF程序崩溃。你远程升级固件客户骂娘。这种 bug你仿真一百次都复现不出来因为它依赖 RAM 的上电随机状态。五、栈main的函数调用靠谁撑腰C 语言的函数调用靠的是栈。调用函数时参数、返回地址、局部变量全往栈里压。返回时再弹出来。但栈指针是谁设的还是启动文件。回头看复位流程的第一步硬件从0x00000000读 32 位值塞进 MSP。这个值就是启动文件里定义的__initial_sp通常等于 RAM 的最高地址比如0x20010000。栈是向下增长的高地址往低地址走所以初始 SP 必须指向 RAM 顶部。如果没有这一步呢MSP 的值是随机的。main里第一个函数调用PUSH指令把数据往一个随机地址写——可能是 Flash 区可能是外设寄存器区立刻 HardFault。你连main的第一行都跑不到。六、所以启动文件到底是干什么的总结一下芯片从复位到进入main经历了这样一个过程复位 ↓ 硬件自动加载 SP来自 0x00000000 ↓ 硬件自动加载 PC来自 0x00000004 ↓ 执行 Reset_Handler ↓ 调用 SystemInit配置时钟 ↓ 跳转到 __main库函数入口 ↓ ├── 拷贝 .data 段Flash → RAM ├── 清零 .bss 段RAM 填 0 └── 调用 C 全局构造如果有 ↓ 调用 main()启动文件做的事情一句话概括在 C 语言运行环境建立之前用汇编把硬件初始化、栈、全局变量、C 库这四件事全部安排妥当。main函数之所以能写得像白纸一样干净是因为有人替它把所有脏活干完了。七、举一反三问题 1如果我写的是纯汇编程序不用 C还需要这些吗不需要全部。你可以不拷贝.data因为没有带初值的全局变量可以不调__main。但栈指针和向量表仍然必须正确设置因为硬件强制要求。问题 2为什么有些 RTOS 的启动文件和裸机的不一样因为 RTOS 需要额外的栈——每个任务有自己的任务栈而 MSP 只用于中断。启动代码里需要额外初始化 PSP进程栈指针并在第一次任务切换时切过去。这对应系列第 85 篇《为什么 RTOS 的启动文件需要额外处理 PendSV 和 SVC》。问题 3RISC-V 也需要这样吗机制不同但本质相同。RISC-V 没有向量表的概念复位后直接跳转到固定地址如0x00001000执行。但.data拷贝、.bss清零、栈初始化这些事一样都少不了。只是实现方式不同。这对应系列第 83 篇《为什么 RISC-V 的启动流程与 Cortex-M3 不同》。八、写在最后回到最初的问题为什么复位后不能直接运行main函数不是不能是硬件只给了你一个空壳 CPUC 语言需要的运行环境一样都没准备。栈没有变量初始值是垃圾时钟跑在默认频率向量表没指向正确的中断函数。启动文件是芯片和 C 语言之间的翻译官。你写的每一行 C 代码能优雅地运行都是因为它在你没看见的地方把最脏最累的活扛了下来。下次复制粘贴startup_xxx.s的时候对它客气一点。下一篇预告《为什么 Cortex-M3 需要向量表向量表为什么必须放在地址 0 附近》关注「OneChan」不错过后续 85 篇“为什么”。