单片机 IAP 功能进阶开发篇之BOOT升级（一）

引言

目的

主要介绍单片机 IAP 开发的设计思路，如何不使用下载烧录器的方式对单片机的程序进行升级，升级区域包括 bootloader 和用户程序的升级，升级方式有 UASRT 通信、CAN 通信和 OTA 升级。
本文目前介绍的是 bootloader 对 Bootloader 程序区升级的开发设计思路。

术语及缩写

BOOT：Bootloader 程序
APP：用户程序

参考资料

---

详细设计

前言

单片机程序都是在 FLASH（ROM）中，通过 单片机 IAP 功能基础开发篇之APP升级（一） 知道， APP 的程序升级是在 Bootloader 中实现的，那么 Bootloader 的程序升级是在哪实现的呢？还是 Bootloader。

实现方式

通过 Bootloader 升级 Bootloader，方法目前我了解的有两种。

Bootloader 互相升级

通过一个 Bootloader 升级另一个 Bootloader，即该程序中存在两个 Bootloader，严格来说的有三个，只不过其中一个和其他两个 Bootloader 的功能不一样，可以称其 Bootloader 的引导程序。

内存分配图如下：

MCU 分区	内容描述	备注
引导程序区	中断向量表
	引导可执行程序	决定执行哪一个 Bootloader
Bootloader 1 程序区	重定向的中断向量表	需要软件配置
	BOOT 可执行程序
Bootloader 2 程序区	重定向的中断向量表	需要软件配置
	BOOT 可执行程序
用户程序区（APP）	重定向的中断向量表	需要软件配置
	APP 可执行程序
数据储存区	系统需要下电保存的数据	可选择划分该区域

执行流程

通过引导程序，检测 Bootloader 1 和 Bootloader 2 的最新状态，校验通过后执行最新的 Bootloader ，然后再进行跳转 APP。其中 Bootloader 1 和Bootloader 2 的功能一致，不同只在于升级 Bootloader 时擦写FLASH的地址不同；
该设计方式较为复杂，需要四个独立的工程，若可实现 Bootloader 的配置，则只需要三个独立的工程即可（Bootloader 的功能相同，其他地址信息不同）

引导程序流程图

Boot程序流程图

仅介绍升级 boot 程序的流程图，APP可看 单片机 IAP 功能基础开发篇之APP升级（一） 的 boot 流程图，其中，升级流程一致，不同的是 BOOT 升级或 APP 升级时的校验、擦写 FLASH 地址等信息的不同。

Bootloader 自升级

通过 Bootloader 升级 Bootloader，即该程序中只存在一个 Bootloader。
内存分配图如下：

MCU 分区	内容描述	备注
Bootloader 程序区	中断向量表
	BOOT 可执行程序
用户程序区（APP）	重定向的中断向量表	需要软件配置
	APP 可执行程序
数据储存区	系统需要下电保存的数据	可选择划分该区域

执行流程

由于单片机的程序是在 Flash 中运行的，如果按照普通的做法，通过 Bootloader 自升级，则会出现在收到升级指令后，会将 Bootloader Flash 的程序全部擦除，这样就会导致程序跑飞，最后成了“板砖”。
要实现 Bootloader 自升级，而且需要保证不会因为擦除了FLASH导致程序无法运行，就需要将程序运行在 RAM 中，在 RAM 中擦除 FLASH 的程序，并不影响 RAM 中的程序执行，即在程序启动后，需要将 Bootloader 的程序拷贝至 RAM 中执行。

当然并不是在程序中简单的通过拷贝函数将 FLASH 的程序拷贝到 RAM 中就可以了，而是需要通过修改链接文件，甚至还需要修改启动文件等才能实现该功能

Boot程序流程图

实现方式对比

Bootloader 互相升级

优点：

• 系统升级功能稳定，基本不会出现升级失败后成为“板砖”
• 不用担心 RAM 的大小

缺点：

• 实现复杂，至少三个独立工程（如果 boot 不能配置，则四个）
• FLASH 需要较大的内存

使用场景：

• BOOT 升级需求度高，BOOT 的更新迭代相对多一点
• 对 BOOT 升级的稳定性比较严格，OTA 升级等

Bootloader 自升级

优点：

• 适用于 FLASH 不够大的MCU
• 功能实现相对简单，两个独立工程

缺点：

• 系统升级功能不稳定，升级失败后若断电，则会成为“板砖”（只要不断电，就可以反复升级直到成功）
• RAM 太小不适合（bootloader的程序大小小于 RAM 大小，且相关变量也占用了 RAM 空间）

使用场景：

• BOOT 升级需求度低，BOOT 的更新迭代基本不需要
• 对 BOOT 升级的稳定性没有过度严格，每次升级都至少保证现场有开发人员，防止升级失败成“板砖”