Cortex-M3 内核启动流程拆解：从向量表到 main 函数的每一步

中断驯服者

338人浏览 · 2026-04-01 21:37:14

中断驯服者 · 2026-04-01 21:37:14 发布

做嵌入式久了会发现，很多人能熟练写驱动、调外设，却讲不清 “芯片上电后，第一行代码从哪跑”“main 函数之前，内核到底做了什么”。

不是不想懂，是没人愿意扒透底层 —— 毕竟库函数把启动过程封装得严严实实，IDE 一键生成启动文件，大多数人觉得 “能跑就行”。但真正的资深工程师，拼的就是这 “启动之前的几毫秒”：看懂它，你才能彻底搞懂内核运行机制、中断响应逻辑，甚至能手动定位启动阶段的 HardFault，这才是底层工程师的核心底气。

今天不聊任何应用层代码，不碰 HAL/LL 库，不搞 Demo，就扒最底层：Cortex-M3 内核上电后，从复位到进入 main 函数，每一步的寄存器操作、汇编指令、地址映射，全给你拆透。

一、先明确一个核心：启动的本质是 “内核初始化 + 硬件映射”

芯片上电后，CPU 不会直接跳去 main 函数，而是先执行一段 “引导代码”—— 也就是我们常说的启动文件（startup_stm32f10x.s 这类），但多数人只知道它是 “自动生成的”，却不知道它里面每一行汇编、每一次寄存器操作，都是在给内核 “搭架子”。

启动的核心逻辑就两件事：

初始化内核关键寄存器（SP、PC、向量表），让内核具备 “执行指令” 的能力；
映射硬件地址、初始化堆栈、配置系统时钟，为后续执行 C 代码铺路。

这一步没有任何 “应用逻辑”，全是和内核、硬件直接对话，也是嵌入式底层最基础、最核心的部分 —— 跳过它，你永远不懂 “代码为什么能跑起来”。

二、第一步：上电复位，内核优先读取向量表

Cortex-M3 内核有个固定的 “复位行为”：上电后，内核会自动读取 0x00000000 地址 的数据，作为 堆栈指针（SP）的初始值 ；再读取 0x00000004 地址 的数据，作为 程序计数器（PC）的初始值 —— 这两个地址，就是向量表的起始位置。

这里要注意一个关键细节：

0x00000000 ：存储 SP 初始值，内核读取后，直接将这个值写入 R13，完成堆栈的初始化；
0x00000004 ：存储复位中断服务函数的地址，内核读取后，将这个地址写入 R15，PC 指针指向 Reset_Handler，接下来就开始执行复位中断服务函数。

很多人调试启动失败时，第一步就是查这两个地址：如果 SP 初始化错误，内核会直接进入 HardFault；如果 PC 指向的地址无效，程序会直接跑飞 —— 这不是玄学，是内核的固定硬件逻辑。

再补充一个细节：不同芯片的向量表地址可能不同，但内核的读取逻辑不变：先读 SP，再读 PC，这是 Cortex-M3 内核的硬件设计，改不了。

三、第二步：执行复位中断服务函数（Reset_Handler）

Reset_Handler 是启动的核心，也是衔接内核初始化和 C 代码的关键，它不是 C 函数，是纯汇编编写的，全程操作寄存器，没有一句应用层代码。

我们拆解一段真实的复位中断服务函数，每一步都讲透底层逻辑：

Reset_Handler:
    LDR     R0, =_estack        ; 把堆栈结束地址加载到R0
    MOV     SP, R0              ; 初始化SP寄存器（R13），和第一步读取0x00000000地址呼应
    BL      SystemInit          ; 跳转到系统初始化函数（配置时钟、地址映射）
    BL      __main              ; 跳转到__main函数（初始化全局变量、清除BSS段）
    BX      LR                  ; 函数返回，进入main函数

这几行汇编，每一行都藏着底层逻辑，不是随便写的：

LDR R0, =_estack ：_estack 是堆栈的结束地址，这一步是将这个地址加载到通用寄存器 R0—— 内核不能直接操作 SP，必须通过通用寄存器中转；
MOV SP, R0 ：将 R0 中的堆栈结束地址，写入 SP 寄存器，完成堆栈的最终初始化 —— 堆栈是内核运行的基础，函数调用、中断响应、局部变量存储，全依赖堆栈，这一步错了，后续所有操作都会崩溃；
BL SystemInit ：BL 是 “带返回的跳转”，跳转到 SystemInit 函数 —— 这个函数也是底层核心，主要做系统时钟配置、地址映射，全程操作 RCC、FLASH 相关寄存器，不涉及任何应用层逻辑；
BL __main ：__main 不是我们写的 main 函数，是编译器提供的底层函数，主要做两件事：初始化全局变量（将.data 段的数据从 Flash 复制到 RAM）、清除 BSS 段—— 这就是为什么我们定义的全局变量，默认值是 0 或初始化值，本质是__main 函数在背后操作；
BX LR ：BX 是 “带状态切换的跳转”，LR 寄存器（R14）中存储的是__main 函数的返回地址，这一步跳转后，正式进入我们写的 main 函数，启动流程结束。

这里：很多人遇到 “全局变量初始化失败”“进入 main 函数后变量值异常”，本质就是__main 函数执行异常，或者堆栈初始化错误 —— 此时不用查应用层代码，直接查 Reset_Handler 中的汇编指令，看 SP 初始化是否正确、__main 函数是否正常跳转。

四、第三步：SystemInit 函数底层拆解

SystemInit 是启动过程中最核心的 “硬件配置” 函数，全程操作寄存器，不依赖任何库封装，我们以 STM32F103 为例，拆解核心寄存器操作：

1. 时钟配置

芯片上电后，默认使用内部高速时钟（HSI），频率较低，SystemInit 的核心就是配置外部高速时钟（HSE），并将系统时钟（SYSCLK）配置到 72MHz，全程通过操作 RCC 相关寄存器实现：

void SystemInit(void)
{
    // 1. 使能HSE（外部高速时钟），操作RCC_CR寄存器
    RCC->CR |= (1 << 16);  // 将RCC_CR寄存器的第16位置1，使能HSE
    // 等待HSE稳定，操作RCC_CR寄存器的第17位（HSE就绪标志）
    while(!(RCC->CR & (1 << 17)));
    
    // 2. 配置AHB、APB1、APB2总线分频，操作RCC_CFGR寄存器
    RCC->CFGR |= (0 << 4);  // AHB总线分频系数为1（HCLK = SYSCLK）
    RCC->CFGR |= (4 << 8);  // APB1总线分频系数为2（PCLK1 = HCLK/2）
    RCC->CFGR |= (0 << 11); // APB2总线分频系数为1（PCLK2 = HCLK）
    
    // 3. 配置PLL（锁相环），将HSE倍频到72MHz，操作RCC_CFGR寄存器
    RCC->CFGR |= (1 << 16); // PLL时钟源选择HSE
    RCC->CFGR |= (0x07 << 18); // PLL倍频系数为9（HSE=8MHz，8*9=72MHz）
    
    // 4. 使能PLL，等待PLL稳定
    RCC->CR |= (1 << 24);
    while(!(RCC->CR & (1 << 25)));
    
    // 5. 将PLL输出作为系统时钟（SYSCLK）
    RCC->CFGR |= (0x02 << 0);
    while(!(RCC->CFGR & (0x02 << 2))); // 等待系统时钟切换完成
}

这里的每一行代码，都是直接操作 RCC 寄存器的特定位，没有任何库封装：

RCC->CR ：RCC 控制寄存器，第 16 位是 HSE 使能位，第 17 位是 HSE 就绪标志位；
RCC->CFGR ：RCC 配置寄存器，负责总线分频、PLL 配置、系统时钟选择；
所有的 “<<”“|=” 操作，都是直接对寄存器的某一位进行置 1 或清 0，这就是底层开发的本质 —— 直接控制硬件寄存器，没有中间层。

2. 地址映射

Cortex-M3 内核默认向量表地址是 0x00000000，但 STM32 的 Flash 地址是 0x08000000，因此 SystemInit 中会做 “向量表重映射”，将向量表地址映射到 Flash 中，操作 SCB_VTOR 寄存器：

// 向量表重映射，将向量表偏移到Flash地址（0x08000000）
SCB->VTOR = 0x08000000;

这一步的底层逻辑：内核读取向量表时，会根据 SCB_VTOR 寄存器的值，计算向量表的实际地址，这样就实现了向量表的重映射 —— 如果不做这一步，内核会去 0x00000000 地址读取向量表，而这个地址可能没有有效数据，导致启动失败。

五、调试：启动阶段 HardFault 的底层定位技巧

聊完启动流程，再补充一个资深工程师的实战干货 —— 启动阶段出现 HardFault，怎么从底层定位问题，不用依赖 IDE 的 “调试助手”，纯靠寄存器排查。

启动阶段的 HardFault，90% 都和以下 3 个问题有关，按这个顺序排查，效率最高：

SP 寄存器初始化错误：查看 SP 寄存器的值，是否等于启动文件中定义的_estack（堆栈结束地址），如果不等，说明向量表中 0x00000000 地址的数据错误，或堆栈地址配置错误；
PC 寄存器指向无效地址：查看 PC 寄存器的值，是否等于 Reset_Handler 的地址，如果不是，说明向量表中 0x00000004 地址的数据错误，或向量表重映射失败；
时钟配置错误：查看 RCC_CR、RCC_CFGR 寄存器的相关位，确认 HSE、PLL 是否正常使能，系统时钟是否配置成功 —— 时钟配置错误，会导致内核执行指令异常，触发 HardFault。

排查时，可在 Reset_Handler 的汇编指令中添加断点，逐步查看 SP、PC、RCC 相关寄存器的值，一步就能定位到问题 —— 这就是懂底层的优势：不用瞎猜，直接从内核、寄存器层面找到根源。

结尾

聊到这，可能有人会说 “搞这么细没用，库函数一键生成，能跑就行”。

但我想说，嵌入式底层的价值，就藏在这些 “没用” 的细节里。你不用每次开发都手动写启动文件、手动配置寄存器，但你必须懂它 —— 懂它，你才能在遇到启动失败、HardFault、时钟异常时，不慌不乱，直接定位问题；懂它，你才能真正理解内核的运行机制；懂它，你才能从 “会用芯片”，变成 “能掌控芯片”。

底层不是玄学，是实打实的寄存器操作、汇编指令、硬件逻辑。不用刻意追求 “高深”，先把启动流程、寄存器映射、中断响应这些基础扒透，你就已经超越了 80% 的嵌入式开发者。