2. 启动流程解剖：芯片上电到main函数的完整路径
做嵌入式开发这么多年，我见过不少工程师把启动流程当成黑盒。芯片上电后怎么跑到你的main函数？这中间发生了什么？说白了，这就像一台汽车的启动过程——钥匙拧下去，发动机怎么点火的，你可能不需要天天修，但出了问题必须懂。
我个人习惯把启动流程分成三个阶段：硬件初始化 → 汇编启动 → C环境初始化。咱们一个一个拆开看。
2.1 复位向量：芯片的第一口气
芯片上电后，CPU会去一个固定地址取第一条指令。这个地址就是复位向量（Reset Vector）。不同的架构，复位向量位置不一样：
| 架构 | 复位向量地址 | 说明 |
|---|---|---|
| ARM Cortex-M | 0x00000000（或映射地址） | 向量表首地址存放栈指针，第二个字存放复位入口 |
| ARM Cortex-A/R | 0x00000000 或 0xFFFF0000 | 可配置高/低向量表 |
| RISC-V | 0x00000000（默认） | 可配置，但多数芯片从0地址启动 |
| 8051 | 0x0000 | 复位后从0地址执行 |
嗯，这里要注意：Cortex-M的复位向量不是直接放指令，而是放栈指针和复位处理函数地址。我第一次做STM32移植时，就因为这个设计差点翻车——我以为向量表里全是函数指针，结果第一个字是栈顶地址。
核心要点：复位向量是芯片上电后CPU执行的第一个动作。它告诉CPU三件事：栈在哪、代码从哪开始、异常怎么处理。
2.2 中断向量表：异常与中断的索引目录
中断向量表（IVT）是芯片的"紧急联络簿"。每个中断源对应一个表项，存放对应的处理函数地址。当发生中断时，CPU自动从这个表里找到处理函数并跳转。
我曾经在一个量产项目中遇到过这样的问题：芯片偶尔复位后跑飞，查了三天发现是向量表地址配置错了。Bootloader把向量表重映射到了RAM，但应用程序启动时没改回来，中断一进来就跳到错误地址。
典型的Cortex-M向量表结构如下：
; 向量表起始地址（假设为0x08000000）
0x08000000: 0x20010000 ; 栈顶指针（MSP初始值）
0x08000004: 0x08000145 ; 复位向量（注意：地址的bit0必须为1，表示Thumb模式）
0x08000008: 0x08000189 ; NMI异常处理
0x0800000C: 0x080001CD ; HardFault异常处理
0x08000010: 0x08000211 ; MemManage异常处理
... ; 其他异常和中断向量避坑指南：我曾经在移植时忘记把向量表地址的bit0置1，结果CPU一直报HardFault。Cortex-M要求所有函数地址的bit0为1（表示Thumb指令集），否则会触发异常。这个坑我踩过一次，之后每次检查向量表都会先看地址的LSB。
2.3 启动模式：芯片从哪里开始"呼吸"
大多数嵌入式芯片支持多种启动模式。说白了，就是芯片上电后从哪个存储介质读取启动代码。常见的启动模式有：
- Boot from Flash：从内部Flash启动，最常用，量产产品基本都用这个
- Boot from RAM：从内部SRAM启动，常用于调试或快速原型验证
- Boot from ROM：从内部ROM启动，通常存放芯片厂商的Bootloader
- Boot from External Memory：从外部Nor Flash、NAND Flash或SD卡启动
启动模式的选择通常通过芯片的BOOT引脚或选项字节来配置。以STM32为例：
| BOOT0 | BOOT1 | 启动区域 | 典型用途 |
|---|---|---|---|
| 0 | X | 主Flash（0x08000000） | 正常启动 |
| 1 | 0 | 系统存储器（0x1FFF0000） | 出厂Bootloader（用于串口下载） |
| 1 | 1 | 内置SRAM（0x20000000） | 调试模式 |
你想想看，为什么要有这么多启动模式？我个人的理解是：灵活性。量产时从Flash启动，开发时从RAM启动可以快速验证，而ROM里的出厂Bootloader则提供了"最后一道防线"——即使Flash里的程序全坏了，还能通过串口重新烧录。
2.4 启动流程完整路径：从复位到main
下面这张图展示了从芯片上电到main函数的完整路径。我建议你把它保存下来，每次做移植时对照着看。
2.5 启动代码中的关键操作
在汇编启动代码中，有几个操作是移植时必须关注的。我以ARM Cortex-M为例，列出最关键的几步：
- 设置栈指针：从向量表第一个字加载到MSP寄存器。如果栈指针不对，任何函数调用都会崩溃。
- 配置向量表偏移：通过VTOR寄存器告诉CPU向量表在哪。Bootloader和APP切换时，这个必须重新设置。
- 初始化系统时钟：调用SystemInit()或类似函数，配置PLL、时钟源、分频系数。
- 跳转到C初始化：调用__main（ARMCC）或_start（GCC），开始C环境初始化。
个人经验：我建议你在汇编启动代码中加一个"看门狗喂狗"操作。有些芯片启动时间较长，如果看门狗在启动过程中超时，芯片会反复复位。我曾经在一个项目中因为这个原因，芯片上电后一直重启，连main函数都进不去。加一句喂狗代码就解决了。
2.6 从Flash/RAM/ROM启动的差异
不同启动介质对启动流程的影响，主要体现在地址映射和访问速度上。我整理了一个对比表：
| 启动介质 | 地址映射 | 速度 | 可写性 | 典型场景 |
|---|---|---|---|---|
| Flash | 固定映射到0x08000000（STM32） | 中等（有等待周期） | 可编程，但需擦除 | 量产产品 |
| RAM | 映射到0x20000000（SRAM地址） | 最快（零等待） | 可读写 | 调试、快速原型 |
| ROM | 映射到0x1FFF0000（系统存储器） | 慢（ROM访问） | 只读 | 出厂Bootloader |
从RAM启动时，有个细节要注意：RAM是掉电易失的。所以从RAM启动通常需要先通过某种方式（比如调试器或Bootloader）把代码加载到RAM中，然后再复位芯片。我调试时经常用这种方式——修改代码后直接下载到RAM，几秒钟就能看到效果，不用反复擦写Flash。
而从ROM启动，说白了就是芯片厂商给你留的"后门"。比如STM32的系统存储器里有一段出厂Bootloader，支持通过USART、USB、CAN等接口下载程序。即使你把Flash里的程序写死了，只要把BOOT引脚拉高，就能通过这个Bootloader救活芯片。
避坑指南：我曾经在一个量产项目中，为了省成本把BOOT引脚直接接地（强制从Flash启动）。结果有一次固件升级失败，Flash里的程序损坏了，芯片彻底变砖。从那以后，我设计的板子都会保留BOOT引脚的跳线或上拉电阻，至少留一条"救生通道"。
2.7 小结：启动流程的核心要点
启动流程看起来复杂，但核心就三件事：
- 复位向量告诉CPU从哪里开始
- 中断向量表告诉CPU异常和中断怎么处理
- 启动模式决定了从哪个存储介质读取启动代码
做Bootloader移植时，你至少需要搞清楚三件事：目标芯片的复位向量地址在哪、向量表怎么配置、启动模式怎么切换。这些信息通常在芯片的参考手册（Reference Manual）里，我建议你先把"System and Memory Architecture"和"Reset and Clock Control"这两章翻一遍。
嗯，启动流程就讲到这里。记住，每次移植新芯片，第一步不是写代码，而是先把启动流程画出来——从复位到main，每一步做什么，数据怎么流动。画清楚了，移植就成功了一半。