APP内嵌C数组：Bootloader升级的极简邪修法

最近有朋友问到关于如何升级 boot 的问题——注意，是升级 bootloader 本身，而不是 APP。这里分享一个直截了当的思路。

升级 bootloader 通常有几种方案：

1. 让 boot 代码在 RAM 中运行，然后自更新（即自举），实现复杂。
2. 在 APP 运行后，直接更新 boot 所在 Flash 空间，实现简单。

第二种方案的常规做法是通过 UART、USB、CAN 等外设接口配合协议（比如 ymodem）来更新。无论是写驱动还是实现传输协议，对很多场景来说都有些过重。

如果只是为了修复 boot 问题，其实可以考虑更轻量的方式：直接把 boot 代码嵌入到 APP 里面，在需要的时候由 APP 把代码数组写入 boot 的运行地址。这样完全不需要实现额外的驱动或传输协议，简单高效，不易出错。

在 Linux 下，可以用一行命令将 bin 文件转成 C 头文件数组：

xxd -i xxx.bin > xxx.h

Windows 上也有功能类似的工具可以使用。

这个办法鱼鹰在项目中也实践过，不过当时是给外部设备升级 APP，用来快速验证升级流程。这里用来更新 boot 也一样可行，只是要特别小心：升级过程中绝不能断电，否则必然变砖。如果不幸又开启了最高级别的读写保护（一次性熔断，不可恢复），那基本就没救了，所以该保护方案一定要慎用。

另外，从根本上讲，如果 OTA 本来就有概率变砖，单纯去升级一个有问题的 boot 并不能真正解决。务必找到 root cause，才算彻底根治。

相关参考

• 嵌入式系统优先级详解
• KEIL 调试经验总结
• 线程CPU使用率到底该如何计算？
• 许久以后，你会感谢自己写的异常处理代码
• 终极串口接收方式，极致效率
• 延时功能进化论(合集)
• 如何写一个健壮且高效的串口接收程序？
• 打了多年的单片机调试断点到底应该怎么设置？ | 颠覆认知

如果你对底层固件与升级策略还有更多好奇，欢迎来 云栈社区 一起讨论，打磨更稳定的嵌入式方案。