3. MCU启动流程与链接脚本：启动文件分析、链接脚本编写、内存映射配置

说实话，很多做IoT开发的工程师，写了好几年代码，却从来没仔细看过MCU上电后到底干了什么。我刚开始做嵌入式那会儿也是这样——代码能跑就行，管它怎么启动的。直到有一次，我在一个低功耗项目里遇到了诡异的死机问题，折腾了两周才发现是启动文件里中断向量表没对齐。嗯，从那以后，我再也不敢跳过这部分了。

这一章，咱们就把MCU启动流程、启动文件、链接脚本和内存映射这几个硬骨头啃下来。你想想看，搞懂了这些，你才算真正掌握了MCU的“命脉”。

3.1 MCU启动流程：从复位到main()

一颗MCU上电后，到底经历了什么才跑到你的main函数？我把它拆成几个关键步骤：

  1. 上电复位：电源稳定后，复位引脚释放，PC指针指向复位向量地址（通常是Flash起始地址，比如0x08000000）。
  2. 取中断向量表：CPU从向量表起始地址读取栈顶指针（MSP），再读取复位向量（Reset_Handler的地址）。
  3. 执行Reset_Handler：这是启动文件里的核心函数。它负责三件事：
    • 初始化全局变量（把.data段从Flash拷贝到RAM）
    • 清零未初始化变量（清.bss段）
    • 调用SystemInit()配置系统时钟
  4. 跳转到main()：一切准备就绪，调用__main（C库函数）或直接跳转到main入口。

关键点：整个启动过程，说白了就是“把代码和数据搬到该去的地方，然后让CPU开始干活”。如果你用的MCU支持从RAM启动（比如调试时），流程类似，只是向量表地址不同。

下面这张图，把整个流程串起来了：

MCU启动流程（从复位到main） ① 上电复位 ② 取中断向量表 ③ 执行 Reset_Handler 拷贝 .data 段到 RAM 清零 .bss 段 SystemInit() 配置时钟 ④ 跳转到 main()

我的经验：调试启动问题时，我最常用的方法是在Reset_Handler开头加一个GPIO翻转。如果灯亮了，说明CPU跑到了启动文件；如果没亮，那问题大概率出在硬件复位或电源上。这招帮我省了不少时间。

3.2 启动文件分析：到底在干什么？

启动文件（startup_xxx.s）是汇编写的，很多开发者一看就头大。其实它结构很清晰，我带你拆开看看：

段/符号 作用 说明
Stack_Size / Heap_Size 定义栈和堆大小 通常用EQU伪指令定义，链接脚本会引用
中断向量表 存放所有中断入口地址 第一个是栈顶指针，第二个是Reset_Handler
Reset_Handler 启动主流程 调用SystemInit、拷贝段、跳转main
Default_Handler 未实现中断的默认处理 通常是个死循环，方便调试

我挑一段典型的Reset_Handler伪代码，你感受一下：

Reset_Handler PROC
    EXPORT  Reset_Handler
    ; 1. 配置系统时钟
    LDR     R0, =SystemInit
    BLX     R0

    ; 2. 拷贝 .data 段从 Flash 到 RAM
    LDR     R0, =__etext      ; Flash 中 .data 的起始地址
    LDR     R1, =__data_start ; RAM 中 .data 的目标地址
    LDR     R2, =__data_end   ; RAM 中 .data 的结束地址
    CMP     R1, R2
    BEQ     .L1
.L2:
    LDR     R3, [R0], #4
    STR     R3, [R1], #4
    CMP     R1, R2
    BNE     .L2

    ; 3. 清零 .bss 段
.L1:
    LDR     R1, =__bss_start
    LDR     R2, =__bss_end
    MOVS    R3, #0
    CMP     R1, R2
    BEQ     .L3
.L4:
    STR     R3, [R1], #4
    CMP     R1, R2
    BNE     .L4

    ; 4. 跳转到 main
.L3:
    BL      main
    B       .
    ENDP

注意：不同MCU厂商的启动文件略有差异。比如STM32用SystemInit，GD32用SystemCoreClockUpdate。移植RTOS或OTA时，一定要确认启动文件里有没有调用你需要的初始化函数。我曾经因为没注意这个，导致OTA跳转后时钟配置不对，系统直接跑飞。

3.3 链接脚本：把代码“摆”到正确的位置

链接脚本（.ld或.scf文件）说白了就是一张“地图”，告诉链接器：你的代码、数据、常量分别该放到哪个地址。我习惯用GCC的.ld文件格式，因为它可读性更好。

一个典型的MCU链接脚本，核心结构是这样的：

MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .isr_vector :
    {
        . = ALIGN(4);
        KEEP(*(.isr_vector))   ; 中断向量表，必须放在最前面
        . = ALIGN(4);
    } > FLASH

    .text :
    {
        . = ALIGN(4);
        *(.text*)              ; 代码段
        *(.rodata*)            ; 只读数据
        . = ALIGN(4);
        _etext = .;            ; 标记代码段结束
    } > FLASH

    .data : AT (_etext)        ; 加载地址在Flash，运行地址在RAM
    {
        . = ALIGN(4);
        _data_start = .;
        *(.data*)
        . = ALIGN(4);
        _data_end = .;
    } > RAM

    .bss :
    {
        . = ALIGN(4);
        _bss_start = .;
        *(.bss*)
        . = ALIGN(4);
        _bss_end = .;
    } > RAM
}

重点：.data段用了AT (_etext)，意思是它的“加载地址”紧跟在代码段后面（Flash里），但“运行地址”在RAM里。启动文件里的拷贝操作，就是基于这个设计。你想想看，如果不拷贝，全局变量初始值就没了。

3.4 内存映射配置：你的MCU地址空间长什么样？

每个MCU都有固定的内存映射。以STM32F4为例：

地址范围 区域 用途
0x0000 0000 - 0x000F FFFF 别名区/系统存储 启动配置、BootROM
0x0800 0000 - 0x0807 FFFF Flash 代码、常量、初始数据
0x1FFF 0000 - 0x1FFF 77FF 系统Flash Bootloader（出厂固件）
0x2000 0000 - 0x2001 FFFF SRAM 栈、堆、全局变量
0x4000 0000 - 0x5FFF FFFF 外设总线 GPIO、USART、SPI等寄存器

做OTA升级时，内存映射尤其重要。我一般会在Flash里划分三个区域：

  • Bootloader区：0x0800 0000 ~ 0x0800 7FFF（32KB），存放升级引导程序
  • App区：0x0800 8000 ~ 0x0807 FFFF（剩余Flash），存放主应用
  • 备份区：如果Flash够大，还可以留一个备份区做回滚

避坑指南：修改链接脚本时，一定要同步修改启动文件里的向量表偏移。我见过有人改了Flash地址，却忘了在SystemInit里设置SCB->VTOR，结果中断一触发就跑飞了。这个坑，我踩过不止一次。

3.5 实战：如何验证你的配置是对的？

配置完链接脚本和启动文件，怎么确认它们工作正常？我分享几个我常用的方法：

  1. 查看map文件：编译后生成的.map文件里，会列出每个段的起始地址和大小。检查.isr_vector是否在Flash起始地址，.data的运行地址是否在RAM里。
  2. 用调试器看内存：在Reset_Handler里设断点，查看SP和PC的值。SP应该等于你定义的栈顶地址，PC应该指向Reset_Handler。
  3. 打印段地址：在main函数里打印&_data_start、&_bss_start等符号，确认它们和链接脚本里定义的一致。

嗯，这一章的内容就到这里。启动流程、启动文件、链接脚本、内存映射——这四个东西是MCU开发的基石。搞懂了它们，你后面做RTOS移植、OTA升级才会心里有底。下次遇到启动异常，你至少知道该从哪里下手查了。

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