单片机 IAP 功能进阶开发篇之BOOT升级（一）
单片机 IAP 功能基础开发篇之APP升级（一） 知道， APP 的程序升级是在 Bootloader 中实现的，那么 Bootloader 的程序升级是在哪实现的呢？还是 Bootloader。
单片机 IAP 功能基础开发篇之APP升级（一） 的 boot 流程图，其中，升级流程一致，不同的是 BOOT 升级或 APP 升级时的校验、擦写 FLASH 地址等信息的不同。
Bootloader 自升级
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 升级的稳定性没有过度严格，每次升级都至少保证现场有开发人员，防止升级失败成“板砖”