2. Bootloader启动流程：初始化、硬件检测与启动模式选择

Bootloader 的启动流程，说白了就是芯片上电后干的第一件正事。我见过不少工程师把精力全放在应用层，觉得 Bootloader 能跑就行。结果呢？OTA 升级失败时连日志都看不懂，因为根本不知道 Bootloader 走到哪一步就挂了。

今天咱们就把 Bootloader 启动的三板斧拆开看：初始化、硬件检测、模式选择。这三步走对了，后面的升级流程才有戏。

2.1 初始化：让芯片“活过来”

芯片上电后，第一件事不是跑你的业务代码，而是把最基本的运行环境搭起来。我个人习惯把初始化分成三个阶段：

1. CPU 级初始化：设置堆栈指针、中断向量表、时钟源。这一步通常由芯片自带的启动代码完成，你基本动不了。
2. 板级初始化：配置 GPIO、UART、Flash 控制器等外设。这里最容易出问题——比如某个引脚没拉高，导致后续通信失败。
3. Bootloader 自身初始化：加载配置参数、校验 CRC、准备日志缓冲区。

我在项目中遇到过一件事：某款 MCU 的 Bootloader 初始化时，把 UART 的波特率配成了 115200，但实际硬件用的是 9600。结果日志全是一堆乱码，折腾了两天才发现是初始化顺序搞错了。

2.2 硬件检测：别让坏硬件骗了你

初始化完成后，Bootloader 会做一轮硬件自检。这一步不是为了跑分，而是确认关键部件能正常工作。你想想看，如果 Flash 已经坏了，你还去读升级包，那不是白费劲吗？

常见的硬件检测项包括：

检测项	检测内容	失败后果
Flash 完整性	读取 Flash ID，校验保护状态	无法写入升级包，设备变砖
RAM 可用性	读写测试关键地址	解压或校验时崩溃
通信接口	回环测试 UART/SPI/I2C	无法接收升级数据
电源电压	ADC 采样关键电源轨	升级中途掉电，数据损坏

嗯，这里要注意：硬件检测不是越全越好。检测太多会拖慢启动速度，用户等得不耐烦。我建议只检测那些“不检测就会死”的部件。

2.3 启动模式选择：走哪条路，看这里

硬件没问题了，Bootloader 就要决定：是直接跳转到应用，还是进入升级模式？这个决策逻辑，通常写在启动模式选择函数里。

常见的启动模式有：

• 正常启动：校验应用区 CRC，通过就直接跳转。
• 强制升级：检测到外部引脚拉低，或者应用区 CRC 校验失败，进入升级模式。
• 回滚模式：升级失败后，自动加载备份区固件。
• 诊断模式：进入命令行或调试接口，方便产线测试。

我见过最典型的日志是这样的：

[BOOT] Mode Select: Check GPIO PB5... LOW
[BOOT] Force Update Mode Entered
[BOOT] Waiting for firmware package...

看到“LOW”了吗？说明外部引脚被拉低了，Bootloader 判断用户想强制升级。如果这里日志显示“HIGH”，但设备死活不进升级模式，那就要查硬件电路了。

2.4 整体流程：一张图看懂

说了这么多，咱们用一张流程图把整个启动流程串起来。这张图我画了很多次，每次给新人讲 Bootloader 都会拿出来用。

这张图里，红色节点是硬件检测，绿色是成功路径，紫色是模式选择。你分析日志时，只要看日志打印到哪个节点，就能快速定位问题。

2.5 日志分析实战：从日志反推流程

最后，咱们看一段真实的启动日志。这是我之前一个项目里截取的：

[BOOT] Version: 2.1.0
[BOOT] Init: CPU OK
[BOOT] Init: UART OK
[BOOT] Init: Flash OK
[BOOT] HW Check: Flash ID 0xEF4018 - PASS
[BOOT] HW Check: RAM Test - PASS
[BOOT] HW Check: Voltage 3.32V - PASS
[BOOT] Mode Select: GPIO PB5 HIGH
[BOOT] Mode Select: App CRC 0xA5B6C7D8 - PASS
[BOOT] Jump to App at 0x08010000

看到没？每一步都有日志。初始化阶段打印了 CPU、UART、Flash 的状态；硬件检测打印了具体数值；模式选择打印了引脚电平和 CRC 结果。如果哪一步没打印，你就知道问题出在哪了。