2. Bootloader启动时间优化：最小化硬件初始化与跳转延迟
好，咱们直接进入正题。Bootloader 的启动时间，说白了就是「从复位到跳进应用程序」这段路要走多快。我见过太多项目，Bootloader 里塞了一堆初始化代码，结果启动时间硬生生多了几百毫秒。嗯，这在普通应用里可能无所谓，但在快速唤醒场景下，这就是灾难。
2.1 硬件初始化的「断舍离」
很多工程师有个习惯：把芯片外设全部初始化一遍再说。我个人觉得，这其实是惯性思维。Bootloader 的任务是什么？就两件事：检查是否需要更新，然后跳转。你想想看，那些 SPI、I2C、CAN 模块，如果 Bootloader 阶段根本用不到，为什么要初始化它们？
核心原则：只初始化 Bootloader 必须用的外设。其他一律跳过。
我在项目中遇到过这样一个案例：某款车规级 MCU，Bootloader 里把全部 GPIO、定时器、ADC 都初始化了，启动时间足足 180ms。后来我们砍到只剩时钟、看门狗和 CAN（用于刷写通信），启动时间直接降到 12ms。你算算，这差了 15 倍。
具体来说，Bootloader 阶段通常只需要：
- 时钟系统：必须初始化，但可以跳过 PLL 锁定的等待时间？不，这个不能省。不过你可以用内部高速振荡器先跑起来，等跳转后再切 PLL。
- 看门狗：建议尽早喂狗，但别在初始化里做复杂配置。
- 通信外设：如果 Bootloader 支持 CAN 刷写，那就只初始化 CAN。别碰 LIN、FlexRay 那些。
- 内存保护单元（MPU）：如果不需要，就别配。配了反而增加延迟。
小技巧：我习惯在 Bootloader 里用一个「最小初始化函数」，把所有非必要外设的初始化代码用宏开关包起来。调试时打开，发布时关掉。这样既灵活又安全。
2.2 跳转延迟的「隐形杀手」
硬件初始化搞定了，接下来就是跳转。很多人以为跳转就是改个 PC 指针的事。其实不然。跳转延迟里藏着几个坑，我一个个说。
2.2.1 中断向量表的重定位
跳转到应用程序前，必须把中断向量表从 Bootloader 的地址切换到应用程序的地址。这个操作本身很快，但有个细节：切换前要关全局中断。否则在切换过程中来了中断，CPU 会跑到错误的向量表里去。
// 典型的中断向量表切换代码
void jump_to_app(uint32_t app_addr) {
// 1. 关全局中断
__disable_irq();
// 2. 设置新的向量表地址
SCB->VTOR = app_addr;
// 3. 设置栈指针
__set_MSP(*(uint32_t*)app_addr);
// 4. 跳转
void (*app_entry)(void) = (void (*)(void))(*(uint32_t*)(app_addr + 4));
app_entry();
// 注意：这里不会返回
}
这段代码看起来没问题，对吧？但我曾经踩过一个坑：关中断后，如果看门狗没喂，跳转过程中看门狗复位了。结果就是 Bootloader 反复重启。后来我在关中断前先喂一次狗，问题解决。
2.2.2 外设状态的清理
跳转前，Bootloader 用过的外设必须清理干净。比如 CAN 控制器还在发送状态，跳过去后应用程序的 CAN 初始化可能会失败。我建议的做法是：
- 把用过的外设复位到默认状态
- 清空所有待处理的中断标志
- 把 DMA 通道全部禁用
警告：千万别在跳转前做全外设复位！那样会把应用程序已经配置好的外设也复位掉。只复位 Bootloader 自己用过的。
2.3 快速跳转的「三板斧」
根据我的经验，把 Bootloader 启动时间压到 10ms 以内，通常需要这三招：
| 优化手段 | 典型收益 | 风险 |
|---|---|---|
| 跳过非必要外设初始化 | 50-200ms | 低，只要确认 Bootloader 不需要这些外设 |
| 使用内部振荡器代替 PLL | 1-5ms | 中，内部振荡器精度可能不够，需评估 |
| 延迟外设初始化到跳转后 | 10-50ms | 低，但需要应用程序配合 |
第三招我特别想说说。有些外设其实可以「借」给应用程序用。比如 Bootloader 初始化了 CAN，跳转时不清除 CAN 配置，应用程序直接接管。这样能省掉 CAN 重新初始化的时间。但前提是：两个软件的 CAN 配置必须完全一致。否则会出大问题。
2.4 实战中的「避坑指南」
我曾经在一个项目里，把 Bootloader 启动时间优化到了 5ms。结果测试发现，偶尔会出现跳转后应用程序跑飞的情况。查了三天，最后发现是 编译器优化等级太高，把跳转函数里的关键操作优化掉了。
嗯，这里给大家一个建议：跳转函数一定要加 __attribute__((optimize("O0")))，强制关闭优化。别省这个功夫。
另外，还有一个容易被忽略的点：Bootloader 的代码位置。如果 Bootloader 放在内部 Flash 的起始地址，跳转时不需要额外操作。但如果放在其他位置（比如备份区），跳转前要确保应用程序的代码已经正确加载到目标地址。我见过有人忘了做 CRC 校验，结果跳到一个损坏的应用程序里，车机直接黑屏。
我的习惯：在跳转前做一次快速 CRC 校验，只校验应用程序的前 256 字节。这样既能发现明显错误，又不会增加太多时间。全量校验？那是刷写完成后的事，别放在启动路径上。
2.5 总结一下
Bootloader 启动时间优化，说白了就是「少做、快做、不做」。少做：只初始化必须的外设。快做：用内部振荡器、关优化、精简代码。不做：把非关键操作挪到应用程序里去做。
你想想看，如果每次唤醒都要等 200ms 的 Bootloader，那快速唤醒还有什么意义？所以这块值得花功夫优化。我个人觉得，10ms 以内是一个比较合理的目标。再往下压，收益就不明显了，反而可能引入稳定性风险。
下一章咱们聊聊应用程序的启动优化，那里面的坑更多，也更考验功力。