3. Boot ROM的软件架构：汇编入口、栈指针初始化、BSS段清零
芯片上电后，第一行代码从哪里开始？
很多人觉得是 main() 函数。其实不是。在 main() 跑起来之前，Boot ROM 里有一段「看不见的代码」——它用汇编写成，负责把 CPU 从「混沌状态」拉进一个可执行 C 程序的环境。我当年第一次看启动代码时，心里就一个想法：这玩意儿居然能跑起来？
3.1 汇编入口：复位向量与第一条指令
CPU 复位后，PC（程序计数器）会被硬件强制指向一个固定地址。这个地址就是 复位向量。对于 ARM Cortex-M 系列，复位向量通常放在 0x00000004（向量表第二个字）；对于 RISC-V，则是 0x80000000 或芯片自定义的基址。
说白了，硬件只认一个死地址。你必须在那个地址放一条跳转指令，跳到真正的初始化代码。
核心原则：复位向量里放的是一条 LDR 或 B 指令，而不是 main() 的地址。因为此时栈还没准备好，C 环境根本不存在。
我见过一个项目，工程师直接把 main() 的地址填进复位向量。结果芯片一上电就跑飞了——因为 main() 里第一条指令就用了栈，而栈指针还是复位默认值（通常是 0）。
; ARM Cortex-M 典型复位向量示例
; 文件: startup.s
.section .isr_vector, "a"
.global _start
_start:
.word _estack ; 栈顶地址（由链接脚本定义）
.word reset_handler ; 复位向量
.section .text
reset_handler:
; 到这里，CPU 已经跳转进来了
; 但栈指针还没初始化，不能调用 C 函数
LDR r0, =_estack
MOV sp, r0 ; 设置栈指针
; 接下来才能调用 C 函数
BL main
B . ; 死循环嗯，这里要注意：_estack 是链接脚本里定义的栈顶地址。不同芯片的 RAM 布局不一样，这个值必须跟硬件匹配。
3.2 栈指针初始化：为什么不能交给 C 语言？
C 语言函数调用时，参数传递、局部变量、返回地址都依赖栈。如果栈指针（SP）是乱的，BL 指令一执行，返回地址就存到了未知内存里——程序必崩。
我个人习惯在复位向量之后、任何 C 代码之前，用三条汇编指令完成 SP 初始化：
- 读取栈顶地址：从链接脚本符号
_estack加载 - 写入 SP 寄存器：
MOV SP, r0 - 确认模式：有些 CPU 需要切换栈指针（MSP/PSP），这一步选主栈指针
避坑指南：我曾经在某个 RISC-V 芯片上踩过坑——它的栈是向下生长的，但链接脚本把栈顶算成了 RAM 末尾。结果栈指针指向了不存在的地址。后来我养成了一个习惯：在 SP 初始化后立刻压一个已知值，再弹出来检查，确认栈能正常工作。
为什么不用 C 语言做这件事？因为 C 语言本身就需要栈。你想想看，这是个鸡生蛋蛋生鸡的问题。汇编是唯一能在「无栈环境」下执行的语言。
3.3 BSS段清零：为什么必须做？
BSS 段存放的是未初始化的全局变量和静态变量。C 标准规定：未显式初始化的全局变量默认值为 0。但硬件上电后，RAM 里的值是随机的——可能是 0x55、0xAA，或者上次运行留下的残影。
如果不清零，你写个 int flag; 然后判断 if (flag == 0)，结果可能永远不成立。我在调试一个物联网模块时就遇到过：设备偶尔连不上网，查了两天发现是一个全局状态变量没清零，随机值恰好等于某个错误码。
BSS 段清零的典型实现：
; BSS 段清零（紧接在 SP 初始化之后）
reset_handler:
LDR r0, =_estack
MOV sp, r0
; 清零 BSS 段
LDR r0, =_sbss ; BSS 起始地址
LDR r1, =_ebss ; BSS 结束地址
MOV r2, #0
bss_loop:
CMP r0, r1
BHS bss_done
STR r2, [r0], #4 ; 每次写 4 字节，地址递增
B bss_loop
bss_done:
; 现在可以安全调用 C 函数了
BL main这里 _sbss 和 _ebss 同样是链接脚本提供的符号。清零的范围必须精确，不能多也不能少——多清了可能覆盖已初始化的数据段，少清了则留下隐患。
3.4 链接脚本的角色：让汇编知道「我在哪」
汇编代码里引用了 _estack、_sbss、_ebss 这些符号。它们不是汇编自己定义的，而是链接脚本提供的。链接脚本描述了各段在内存中的布局：
/* 简化版链接脚本示例 */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
SECTIONS
{
.isr_vector : { *(.isr_vector) } > FLASH
.text : { *(.text) } > FLASH
.data : { *(.data) } > RAM AT> FLASH
.bss : {
_sbss = .;
*(.bss)
_ebss = .;
} > RAM
_estack = ORIGIN(RAM) + LENGTH(RAM);
}你看，_sbss 和 _ebss 就是链接器在链接阶段计算出来的地址。汇编代码里引用它们，链接器会自动填入实际数值。
重要提醒：链接脚本里的 _estack 通常指向 RAM 末尾。但有些芯片的 RAM 末尾被保留用于其他用途（比如 DMA 描述符），这时必须手动调整栈顶地址，否则栈会跟其他模块冲突。
3.5 整体流程：从复位到 main() 的完整链路
把上面几个步骤串起来，Boot ROM 的启动流程就是：
- 硬件复位：PC 指向复位向量地址
- 读取向量表：取出复位向量中的跳转目标
- 跳转到 reset_handler：此时栈未初始化，只能用汇编
- 初始化栈指针：从链接脚本获取栈顶地址，写入 SP
- 清零 BSS 段：从
_sbss到_ebss逐字写 0 - 调用 main()：此时 C 环境就绪，可以放心使用全局变量和函数调用
这个流程看起来简单，但每一步都有坑。我画了一张图，把整个链路和关键寄存器变化展示出来：
3.6 常见陷阱与排查方法
| 陷阱 | 现象 | 排查方法 |
|---|---|---|
| 栈顶地址越界 | 上电后跑几步就 HardFault | 检查链接脚本中 RAM 大小和 _estack 计算 |
| BSS 段未清零 | 全局变量初始值随机，行为偶发异常 | 在 main() 入口打印几个关键全局变量 |
| 复位向量填错 | 芯片完全不跑，调试器连不上 | 用调试器查看 PC 是否停在预期地址 |
| 向量表地址不对齐 | 中断不响应或响应错乱 | 确认向量表按 256 字节对齐（Cortex-M 要求） |
个人经验：我调试启动代码时，习惯在 reset_handler 开头放一条 NOP 指令，然后在调试器里设断点。这样能确认 CPU 确实执行到了我的代码，而不是卡在硬件默认的某个循环里。
Boot ROM 的汇编入口、栈指针初始化、BSS 段清零，这三步是嵌入式系统启动的「铁三角」。任何一步出问题，后面的 C 代码都跑不起来。你想想看，一个连栈都没有的系统，怎么调用函数？一个全局变量全是随机值的系统，怎么保证逻辑正确？
嗯，把这些基础打牢，后面的安全启动链路才有立足之地。