3. 启动模式检测：启动引脚配置、启动设备优先级、启动模式选择逻辑
芯片上电后，第一件事是什么？不是跑操作系统，也不是初始化外设。BootROM 要做的第一件事，是搞清楚一个问题：“我从哪里启动？”
这个问题听起来简单，但背后涉及一套完整的检测逻辑。我早年做一款车规级芯片时，就遇到过启动模式检测失败导致整批板子无法开机的故障。排查了三天，最后发现是启动引脚的上下拉电阻焊错了。嗯，从那以后，我对这部分逻辑就格外上心。
3.1 启动引脚配置：硬件的第一道选择题
芯片怎么知道该从哪启动？靠的是硬件引脚的电平状态。这些引脚通常叫 BOOT 引脚，或者叫 启动模式选择引脚。
一般来说，芯片会预留 2~4 个 GPIO 引脚作为启动配置引脚。芯片复位时，BootROM 会在极短的时间内（通常是几十个时钟周期）采样这些引脚的电平，然后锁存到内部寄存器里。
关键点：采样只在复位释放后的瞬间发生。一旦锁存完成，这些引脚就可以复用作普通 GPIO 了。所以你在原理图上看到的 BOOT 引脚，往往同时标注了其他功能。
常见的引脚配置方式有两种：
- 硬件拉高/拉低：通过外部上拉或下拉电阻固定电平。优点是简单可靠，缺点是改起来麻烦，得换电阻。
- 烧写 OTP/efuse：一次性编程，出厂后不可更改。适合量产时锁定启动模式。
我个人习惯在设计阶段留一组拨码开关或者跳线帽，方便调试时切换启动模式。量产时再换成固定电阻，成本低又可靠。
3.2 启动设备优先级：谁先谁后？
芯片支持多种启动介质，比如 SPI NOR Flash、NAND Flash、SD 卡、USB、UART 等。但问题来了——如果同时接了好几个，BootROM 该听谁的？
这就涉及到 启动设备优先级 的概念。芯片厂商会在芯片设计阶段，硬编码一套优先级顺序。比如某款 ARM Cortex-M 芯片的默认优先级是：
| 优先级 | 启动设备 | 典型场景 |
|---|---|---|
| 1（最高） | SPI NOR Flash（主片） | 正常量产启动 |
| 2 | SD 卡 / eMMC | 开发调试、固件升级 |
| 3 | USB DFU | 工厂烧录、恢复模式 |
| 4 | UART 下载 | 紧急救援、无存储设备 |
BootROM 会按照优先级从高到低依次尝试。如果高优先级设备检测失败（比如 Flash 为空、校验错误），就自动降级到下一个设备。
避坑指南：我曾经遇到一个案例，客户说芯片死活不从 SD 卡启动。查了半天，发现 SPI Flash 里残留了无效数据，BootROM 认为 Flash 有内容，尝试加载但校验失败，然后卡死了——它没有继续降级。后来我们改了 BootROM 逻辑，加了“超时+降级”机制才解决。所以，优先级不是绝对的，具体行为要看芯片的 BootROM 实现。
3.3 启动模式选择逻辑：BootROM 的决策树
启动模式检测，说白了就是 BootROM 执行的一棵决策树。我画了一张流程图，帮你理清这个逻辑：
这张图展示的是典型的启动流程。你想想看，BootROM 其实就像一个尽职的保安，挨个检查每个门能不能打开。第一个门打不开，就去试第二个，直到找到能开的门为止。
3.4 启动模式选择的具体实现
不同芯片厂商的实现方式各有差异。我以常见的 ARM Cortex-A 系列芯片为例，说说具体的实现细节。
3.4.1 引脚组合编码
假设芯片有 4 个 BOOT 引脚（BOOT[3:0]），可以编码 16 种启动模式。常见的编码方式如下：
| BOOT[3:0] | 启动模式 | 说明 |
|---|---|---|
| 0000 | SPI NOR Flash（主） | 默认量产模式 |
| 0001 | SPI NAND Flash | 大容量存储 |
| 0010 | SD 卡（SD0） | 开发调试常用 |
| 0011 | eMMC | 嵌入式存储 |
| 0100 | USB DFU | 固件升级 |
| 0101 | UART 下载 | 串口烧录 |
| 0110 | JTAG 调试 | 调试模式 |
| 0111~1111 | 保留/自定义 | 厂商自定义 |
注意：有些芯片的 BOOT 引脚是内部上拉的，所以悬空时读到的值是 1。如果你把引脚悬空，可能会进入一个意想不到的启动模式。我见过有人把 BOOT 引脚直接悬空，结果芯片每次都从 UART 启动，板子死活跑不起来。排查到最后，加了个下拉电阻就解决了。
3.4.2 BootROM 中的模式选择代码
BootROM 里的启动模式检测代码，通常是用汇编写的，因为这时候 C 运行时环境还没准备好。我简化一下逻辑，大概是这样的：
; 伪代码：BootROM 启动模式检测
BOOT_PIN_REG = 0x01C00000 ; 假设引脚状态映射到该地址
start:
ldr r0, =BOOT_PIN_REG
ldr r1, [r0] ; 读取引脚电平
and r1, r1, #0x0F ; 只取低 4 位 (BOOT[3:0])
; 根据引脚值跳转到对应处理
cmp r1, #0x00
beq boot_from_spi_nor
cmp r1, #0x01
beq boot_from_spi_nand
cmp r1, #0x02
beq boot_from_sd_card
cmp r1, #0x03
beq boot_from_emmc
cmp r1, #0x04
beq boot_from_usb_dfu
cmp r1, #0x05
beq boot_from_uart
; 默认：进入错误处理
b boot_error_handler这段代码看起来简单，但实际工程中要考虑很多边界情况。比如引脚抖动、电源不稳定导致的误采样、外部干扰等。
3.5 启动模式检测的工程陷阱
做了这么多年嵌入式，我总结了几条常见的坑：
- 引脚采样时序：复位释放后，BootROM 会在几个时钟周期内完成采样。如果外部 RC 复位电路太慢，或者电源上升时间太长，可能导致采样到错误电平。我建议在复位电路设计时，确保电源稳定后再释放复位。
- 引脚复用冲突：BOOT 引脚往往和其他功能复用。如果外设在上电瞬间驱动了这些引脚，可能干扰 BootROM 的采样。我曾经遇到一个案子，I2C 的上拉电阻影响了 BOOT 引脚电平，导致启动模式错乱。
- 降级策略的边界：有些芯片的 BootROM 在尝试所有设备失败后，会进入一个死循环或者直接挂起。设计时最好留一个“最后手段”，比如 UART 下载模式，方便救砖。
我的习惯：在原理图设计阶段，我会把 BOOT 引脚单独拉出来，加上测试点。调试时用示波器抓一下复位后的电平，确认采样值对不对。这一步虽然简单，但能省下后面大量的排查时间。
3.6 小结
启动模式检测，是 BootROM 的第一个关键决策点。它通过硬件引脚配置，结合内部优先级逻辑，决定从哪个设备加载启动代码。这部分逻辑虽然看起来简单，但涉及硬件设计、时序分析、异常处理等多个方面，稍有不慎就会导致系统无法启动。
理解这部分内容，对你后续理解 BootROM 加载、校验、跳转等环节会有很大帮助。毕竟，方向选错了，后面跑得再快也没用。