ARM架构启动流程解析：零基础完整示例

从零开始读懂ARM启动流程：一个完整实例带你穿透底层

你有没有遇到过这样的情况？程序烧录进去，开发板一上电，灯不亮、串口没输出，调试器连上去却停在HardFault_Handler里——而你写的main()函数压根就没执行。

这时候，很多人第一反应是“代码写错了”。但真相往往是：系统还没真正启动起来。

在嵌入式开发中，尤其是基于ARM Cortex-M系列的MCU（比如STM32、GD32、NXP Kinetis等），一切问题的起点不是main()，而是上电那一刻CPU做的第一件事。这个过程，就是我们常说的“启动流程”。

今天，我们就抛开晦涩术语和碎片知识，用一个完整的实战视角，带你一步步走完ARM架构从复位到运行main()的全过程。不需要你有深厚的汇编功底，只要你愿意看懂每一行代码背后的意义。

启动的第一步：CPU上电后到底做了什么？

想象一下，芯片刚接通电源，内部寄存器全是随机值，内存空空如也。此时，CPU必须知道：

堆栈指针该设成多少？
第一条指令从哪里开始执行？

ARM Cortex-M系列的设计非常简洁高效：它规定了两个关键地址：

0x0000_0000：存放初始主堆栈指针（MSP）；
0x0000_0004：存放复位异常处理函数地址（Reset_Handler）。

这两个地址合起来，构成了系统的“生命起点”。

✅ 关键点：
这个机制意味着，哪怕你的程序只有几个字节，只要这两个地址的内容正确，CPU就能活过来。

但这还不够直观。我们来看一个真实例子。

异常向量表：系统启动的“导航地图”

ARM把各种异常（中断、复位、错误等）的入口地址集中放在一起，形成一张固定的跳转表，称为异常向量表（Exception Vector Table, EVT）。

对于Cortex-M来说，这张表通常放在Flash最开头的位置（即0x0800_0000，假设Flash映射到0x0000_0000通过重映射或默认配置生效）。

下面是一个典型的向量表示例：

extern uint32_t _estack; // 栈顶地址（由链接脚本定义） extern void Reset_Handler(void); // 复位处理函数 extern void NMI_Handler(void); extern void HardFault_Handler(void); typedef void (*func_ptr)(void); __attribute__((section(".vectors"))) const func_ptr g_pfnVectors[] = { (func_ptr)&_estack, // 0x0000_0000: 初始化MSP Reset_Handler, // 0x0000_0004: 复位入口 NMI_Handler, // 0x0000_0008: NMI HardFault_Handler, // 0x0000_000C: 硬件故障 MemManage_Handler, BusFault_Handler, UsageFault_Handler, 0, 0, 0, 0, // 保留项 SVC_Handler, DebugMon_Handler, 0, PendSV_Handler, SysTick_Handler, WWDG_IRQHandler, PVD_IRQHandler, // ... 其他外设中断 };

📌 解读要点：

数组第一个元素是_estack的地址，也就是SRAM的最高地址（栈向下生长）；
第二个元素是Reset_Handler函数指针，CPU会直接跳到这里执行；
使用__attribute__((section(".vectors")))是为了让编译器把这个数组放到名为.vectors的段中；
链接器脚本必须确保这个段被放置在Flash起始位置。

如果你发现程序一上电就跑飞，首先要检查的就是：向量表是否真的在Flash头？内容是否对齐？

启动代码：连接硬件与C世界的桥梁

有了向量表，CPU可以跳进Reset_Handler。但这时还不能直接调main()，因为：

.data段中的全局变量还没有初始化；
.bss段中的未初始化变量还没清零；
堆栈虽然设置了，但其他模式可能也需要；
系统时钟可能还没稳定；
FPU、MPU等功能还没启用。

这些工作，就得靠一段汇编代码来完成——这就是所谓的启动代码（Startup Code）。

下面是精简后的核心逻辑：

.syntax unified .cpu cortex-m4 .thumb .global Reset_Handler Reset_Handler: cpsid i /* 关闭中断 */ /* 复制.data段：从Flash拷贝到SRAM */ ldr r0, =_sidata /* Flash中.data起始地址 */ ldr r1, =_sdata /* SRAM中.data起始地址 */ ldr r2, =_edata /* .data结束地址 */ movs r3, #0 b LoopCopyDataInit CopyDataInit: ldr r4, [r0, r3] str r4, [r1, r3] adds r3, r3, #4 LoopCopyDataInit: cmp r3, r2 bcc CopyDataInit /* 清零.bss段 */ ldr r0, =_sbss ldr r1, =_ebss movs r2, #0 movs r3, #0 b LoopClearBSSInit ClearBSSInit: str r2, [r0, r3] adds r3, r3, #4 LoopClearBSSInit: cmp r3, r1 bcc ClearBSSInit /* 可选：调用SystemInit进行芯片级初始化 */ bl SystemInit /* 开启中断（可选） */ cpsie i /* 跳转到main函数 */ bl main /* main不应返回，防止意外返回后继续执行 */ LoopForever: b LoopForever

🧠 重点说明：

_sidata,_sdata,_edata,_sbss,_ebss都是由链接脚本生成的符号；
.data存的是“有初始值的全局变量”，比如int x = 100;，它的初值存在Flash里，运行前要复制到SRAM；
.bss是“未初始化的全局变量”，如int y;，标准要求它们为0，所以需要手动清零；
如果你不做这两步，main()里读到的变量可能是垃圾值，导致逻辑错乱甚至崩溃。

⚠️ 常见坑点：
有些开发者以为“我只用了局部变量”，所以不用管.data/.bss。但实际上，任何全局/静态变量都会进入这两个段！忽略它们等于埋雷。

内存布局如何安排？链接脚本说了算

上面提到的所有地址——Flash在哪、SRAM起始位置、各个段怎么分布——都由一个神秘文件控制：链接脚本（Linker Script）。

以STM32F407为例，.ld文件长这样：

ENTRY(Reset_Handler) MEMORY { FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K } _estack = ORIGIN(RAM) + LENGTH(RAM); SECTIONS { .vectors : { KEEP(*(.vectors)) } > FLASH .text : { *(.text*) *(.rodata*) } > FLASH .data : { _sidata = LOADADDR(.data); _sdata = .; *(.data*) _edata = .; } > RAM AT > FLASH .bss : { _sbss = .; *(.bss*) *(COMMON) _ebss = .; } > RAM }

🔍 关键解析：

MEMORY定义物理存储区域；
ORIGIN是基地址，LENGTH是大小；
.vectors放在Flash最前面，并用KEEP防止被优化掉；
.data实际运行在RAM，但初始数据来自Flash（AT > FLASH），这正是启动代码复制的依据；
_estack被赋值为RAM末尾，作为MSP初始值。

💡 小技巧：
如果你想把关键函数放在高速ITCM内存中加速执行，只需添加新段并指定位置即可：

.itcm_func : { *(.itcm_func) } > ITCM

然后在代码中标记：

__attribute__((section(".itcm_func"))) void fast_function(void) { ... }

系统级初始化：让内核真正“苏醒”

当基本环境准备好后，下一步是激活Cortex-M内核的一些高级功能。这部分通常封装在SystemInit()函数中，由CMSIS提供支持。

典型实现如下：

#include "core_cm4.h" void SystemInit(void) { /* 设置向量表偏移（例如已将向量表搬至SRAM） */ SCB->VTOR = 0x20000000 & SCB_VTOR_TBLOFF_Msk; #ifdef ENABLE_FPU /* 使能浮点单元FPU */ SCB->CPACR |= ((3UL << 10*2) | (3UL << 11*2)); // CP10=FPEN, CP11=FPEN __DSB(); __ISB(); #endif /* 禁止深度睡眠模式干扰调试 */ SCB->SCR &= ~SCB_SCR_SLEEPDEEP_Msk; /* 可选：更新系统时钟频率（依赖厂商库） */ // SystemCoreClockUpdate(); }

🔧 核心寄存器作用一览：

寄存器	功能
`SCB->VTOR`	向量表重定位，用于Bootloader跳转App、动态中断切换
`SCB->CPACR`	协处理器访问控制，开启FPU必须修改
`SCB->AIRCR`	软件触发系统复位
`NVIC`相关寄存器	中断优先级配置、使能

🎯 应用场景举例：

你在写一个OTA升级程序，主应用和Bootloader各有自己的中断服务程序。怎么办？

→ 在跳转前设置VTOR = APP_VECTOR_TABLE_ADDR，让CPU使用新的向量表！

这就是向量表重定位的实际价值。

整体流程串讲：从上电到main()

让我们把所有环节串起来，看看整个启动链条是如何运作的：

[上电] ↓ CPU读取0x0000_0000 → 加载MSP = _estack ↓ CPU读取0x0000_0004 → 跳转至Reset_Handler ↓ 执行汇编启动代码： ├─ 关中断 ├─ 复制.data段（Flash → SRAM） └─ 清零.bss段 ↓ 调用SystemInit() ├─ 设置VTOR ├─ 使能FPU └─ 配置系统行为 ↓ 调用main() ↓ 用户程序正式运行！

每一步都不能少，任何一个环节出错，都会导致系统“假死”。