单片机 IAP 功能基础开发篇之APP升级（一）

引言

目的

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

术语及缩写

• BOOT：Bootloader 程序
• APP：用户程序

参考资料

---

简介

简单地说，bootloader就是在操作系统内核运行前运行地一段小程序。通过这段小程序，可以对硬件设备，如CPU、SDRAM、Flash、串口等进行初始化，也可以下载文件到系统板、对Flash进行擦除和编程，真正起到引导和加载内核镜像的作用，但是随着嵌入式系统的发展，bootloader已经逐渐在基本功能的基础上，进行了扩展，bootloader可以更多地增加对具体系统的板级支持，即增加一些硬件模块功能上的使用支持，以方便开发人员进行开发和调试。从这个层面上看，功能扩展后bootloader可以虚拟地看成是一个微小的系统级的代码包。
在嵌入式操作系统中，BootLoader是在操作系统内核运行之前运行。可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。
通常，BootLoader是严重地依赖于硬件而实现的。所以在这种情况下，基本都是不同的处理器架构都有不同的Bootloader。

BOOT 和 APP

BOOT 程序和 APP 程序是两个独立的工程，互不干扰，但是都是依赖于同一硬件平台进行开发的。

工作原理

单片机内部至少划分有两块存储区，一般一块被称为 BOOT 程序区，另外一块被称为 APP 程序区（有些自带EEPROM功能的可再划分为数据储存区）。单片机上电运行在BOOT区，如果有外部改写程序的条件满足，则可以对 BOOT 程序区 APP 程序区（还有数据储存区）的程序进行改写操作。如果外部改写程序的条件不满足，程序指针跳到 APP 程序区，开始执行放在 APP 程序区的程序，这样便实现了 IAP 功能。

应用场景

在使用 IAP 技术之前，需要先了解一下什么情况下需要开发 BootLoader，以免在完全没必要的情况下增加开发工作量；

产品开发完成后，后期有升级售后需求的，更新程序有两种方式，重新烧写程序升级和通过BootLoader升级；重新烧写程序仅通过开发者进行实现，不能由售后人员或客户自行升级，若设备产品安装复杂，甚至需要通过拆解才能烧写程序升级，过程繁琐，且客户通常不允许这么做；此时，为了解决这些弊端，BootLoader 功能就必须实现。

---

IAP开发设计

根据 IAP 功能特性，BOOT 程序是在 MCU 上电时执行的，APP 是由 BOOT 跳转后执行的，因此对于 BOOT 和 APP 的分区和流程如下。

内存分配

开发 BootLoader 前，首先需要规划 MCU 的 ROM 分区，给 BOOT 和 APP 预留足够 ROM 空间，使两个程序可以互相独立运行，就必须先进行 ROM 内存分配，为BootLoader 预留足够的空间，避免BootLoader程序编译后的固件大小超出所属空间，从而影响用户程序（APP）区，常用的内存分配图如下：

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

流程图

内存分配完成后，需要一套完整的程序流程图以实现产品的 IAP 功能。

BOOT 流程图

Created with Raphaël 2.3.0 开始 系统初始化 升级请求 升级中 升级完成 APP 程序存在 BOOT 退出处理 跳转至APP运行 结束 计数超时 yes no yes no yes no yes no

APP 流程图

Created with Raphaël 2.3.0 开始 系统初始化（中断向量表重定向） 用户程序功能 升级请求 APP 退出处理 跳转至 BOOT运行 结束 yes no

升级方式

在不具备 IAP 功能的 MCU 基本都是通过下载器的方式进行固件烧录的，那么具备 IAP 功能的 MCU 是通过什么方式进行固件烧录的呢？可以根据一下情况选择合适的升级方式：

• CAN 通信

CAN 总线多用于工控和汽车领域，因此如果产品的定位是属于该领域的，那么 CAN 总线是最合适的升级方式之一，且可自定义协议也可以使用标准的 UDS 通用协议

• 串口通信

串口通信应用及其广泛，和 CAN 通信相比，UASRT 通信机制简单，所以在稳定性和安全性方面稍微较差，但是可以一次发送的数据更多，因此在一定程度上对 MCU 升级的速度更快，比较适用于非工控和非汽车领域的其他领域

• OTA

空中下载技术，通俗理解为远程网络升级，和上面两种相比，OTA 升级不需要在现场通过相关工具连接 MCU 进行升级；可以在任何地方对该 MCU 的程序进行升级，前提是有网络，因此，OTA 升级需要 MCU 产品具备网络功能，实现较为复杂

• 其他

当然，除了上述升级方式外，还有其他的升级方式，上述讲到的，基本属于常用的升级方式

升级过程

由上述流程图可知，收到升级请求后，就需要将接收的固件数据烧录在 MCU 的 ROM 中，实现 BOOT 或 APP 的升级，由于升级是在 BOOT 中实现的，因此该流程图只适用于 BOOT；

Created with Raphaël 2.3.0 开始 ROM 擦除 接收固件数据至 RAM 将 RAM 数据编程至 ROM 中 结束

但对于单片机来说，RAM 的大小远远小于 ROM 的大小，无法满足一次性接收完整的固件数据到 RAM 中再编程。
既然不能一次性读取，那么可以使用分包读取写入的形式，根据 ROM 的特性决定 RAM 分包的大小，避免编程失败，通常都是 2^n 的大小，且受 ROM 擦除的方式影响，通常升级过程的流程图如下：

Created with Raphaël 2.3.0 开始 ROM 擦除 接收一包固件数据至 RAM 将 RAM 包数据编程至 ROM 中 数据接收完成 结束 yes no

程序跳转

在 MCU 升级完成或者是在一定时间内未收到升级请求，那么就需要从 BOOT 跳转至 APP，执行用户程序功能，但在执行 APP 程序前，首先需要验证 APP 程序是否有效（比如擦除后烧写失败则APP程序不完整，在 APP 执行中会出错），才能进行跳转。

验证原因：

• BOOT 和 APP 属于单独工程，若一新的 MCU 先烧录 BOOT 程序，则上电后无 APP 程序，则会引起 MCU 异常中断
• APP 程序擦除后烧写失败则导致 APP 程序不完整，跳转后也会引起 MCU 异常中断
• APP 程序存在但代码数据因为不可抗因素出现错乱，跳转后也会引起 MCU 异常中断或者用户程序功能异常等
• 其他异常情况

如何验证？

• 验证 APP 程序是否存在且完整，通常做法是在指定的 APP 程序区设置一标志位，表示 APP 程序存在（擦除时该标志也会一并擦除）
• 对 APP 程序进行校验，防止 APP 程序存在但因为不可抗因素出现代码错乱的问题

验证结束

• 在验证结束后，若验证成功，则准备跳转 APP 程序，在跳转之前需要 BOOT 关闭相关功能防止跳转时或者跳转后出错
• 跳转至 APP 后，需要进行重定向中断向量表，否则无法正常进入 APP 程序区的中断执行函数，具体原因可先了解中断向量表的含义及作用

下篇见：单片机 IAP 功能基础开发篇之APP升级（二）