1. 课程导论：为什么需要了解启动流程？启动流程与链接脚本的关系概述
大家好，我是你们的讲师。做嵌入式开发这么多年，我见过太多工程师在启动阶段栽跟头。说实话，很多人写了几年STM32代码，却从来没认真看过启动文件里到底发生了什么。嗯，今天我们就来聊聊这个看似基础、实则关键的话题。
1.1 一个真实的教训
先讲个我自己的故事。几年前我带一个团队做工业控制项目，用的是STM32F4系列。产品量产到第三批，突然出现一批设备上电后无法启动。排查了整整三天，最后发现是启动文件里中断向量表偏移设置出了问题。你想想看，就因为启动流程里一个小细节，差点导致整批货报废。
从那以后，我养成了一个习惯：拿到任何新芯片，第一件事就是看它的启动流程和链接脚本。这不是矫情，是血的教训换来的经验。
1.2 启动流程到底在干什么？
说白了，MCU的启动流程就是回答三个问题：
- 从哪里开始？ — 复位后CPU第一条指令在哪？
- 内存怎么安排？ — 全局变量、堆栈放在哪？
- 代码怎么跑起来？ — 如何从复位向量跳到main函数？
我习惯把启动流程比作「芯片的起床仪式」。你想想看，人起床要先睁眼、坐起来、穿衣服、洗漱，然后才能正常工作。MCU也一样：复位后先设置堆栈指针、初始化中断向量表、清零BSS段、拷贝数据段，最后才调用main函数。
核心要点：启动流程不是可有可无的「仪式感」，它直接决定了你的程序能否正确运行。尤其是涉及中断、RTOS、Bootloader时，启动流程的任何偏差都会导致灾难性后果。
1.3 链接脚本扮演什么角色？
链接脚本，很多人觉得它就是个「地址分配工具」。其实没那么简单。我个人的理解是：链接脚本是启动流程的「施工图纸」。
为什么这么说？因为启动流程里做的每一件事——设置堆栈、拷贝数据、清零BSS——都需要知道具体的内存地址。而这些地址，正是由链接脚本定义的。
举个例子：
/* 典型的STM32链接脚本片段 */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
SECTIONS
{
.text : { *(.text*) } > FLASH
.data : { *(.data*) } > RAM AT> FLASH
.bss : { *(.bss*) } > RAM
}看到没？.text段放在Flash，.data段运行时在RAM但初始值存在Flash，.bss段在RAM且需要清零。这些信息，启动文件里的汇编代码会逐条读取并执行。
我的经验：调试启动问题时，我通常先看链接脚本里的内存布局，再看启动文件里的汇编代码。两者对不上，问题就出在那。我曾经花了一下午，就为了对齐一个字节的段对齐问题。
1.4 启动流程与链接脚本的「共生关系」
它们的关系可以用一张图来概括：
这张图我想表达的核心意思是：链接脚本是「静态规划」，启动流程是「动态执行」。链接脚本在编译阶段就定好了每个段该放哪，启动流程在运行时按图索骥，把规划变成现实。
1.5 不懂启动流程，你会遇到哪些坑？
我总结了几类常见问题，都是我在项目或社区里真实见过的：
| 问题类型 | 现象 | 根因 |
|---|---|---|
| 中断不响应 | 使能了中断，但CPU就是不进中断服务函数 | 中断向量表地址配置错误，或未正确重定位 |
| 全局变量异常 | 全局变量初始值不对，或者随机值 | .data段未正确拷贝，或.bss段未清零 |
| 堆栈溢出 | 程序跑飞，进入HardFault | 堆栈指针初始值设置错误，或堆栈空间不足 |
| Bootloader跳转失败 | 从Bootloader跳转到App后死机 | 未正确修改向量表偏移，或未清理外设状态 |
避坑指南：我曾经接手过一个项目，同事把链接脚本里的RAM起始地址写错了，导致全局变量和堆栈重叠。程序在大部分情况下能跑，但偶尔会莫名其妙死机。这种「幽灵Bug」最难排查，最后花了两天用map文件逐字节比对才找到问题。
1.6 学完本章，你能得到什么？
这门课会带你从零开始，一步步拆解STM32的启动流程和链接脚本。具体来说：
- 看懂启动文件 — 不再把startup.s当「黑盒」
- 掌握链接脚本 — 能自己写.ld文件，而不是只会复制粘贴
- 学会调试启动问题 — 遇到上电不跑、中断异常，知道从哪下手
- 理解内存布局 — 知道代码、数据、堆栈到底怎么放的
说实话，这些知识平时可能用不上，但一旦遇到问题，它就是救命稻草。我个人觉得，一个嵌入式工程师从「能用」到「精通」的分水岭，就在于是否真正理解了启动流程。
好，导论就到这里。下一节我们直接看STM32的复位序列，看看CPU上电后第一条指令到底在哪。
公众号:蓝海资料掘金营，微信deep3321