引言
目的
主要介绍单片机 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 流程图
APP 流程图
升级方式
在不具备 IAP 功能的 MCU 基本都是通过下载器的方式进行固件烧录的,那么具备 IAP 功能的 MCU 是通过什么方式进行固件烧录的呢?可以根据一下情况选择合适的升级方式:
- CAN 通信
CAN 总线多用于工控和汽车领域,因此如果产品的定位是属于该领域的,那么 CAN 总线是最合适的升级方式之一,且可自定义协议也可以使用标准的 UDS 通用协议
- 串口通信
串口通信应用及其广泛,和 CAN 通信相比,UASRT 通信机制简单,所以在稳定性和安全性方面稍微较差,但是可以一次发送的数据更多,因此在一定程度上对 MCU 升级的速度更快,比较适用于非工控和非汽车领域的其他领域
- OTA
空中下载技术,通俗理解为远程网络升级,和上面两种相比,OTA 升级不需要在现场通过相关工具连接 MCU 进行升级;可以在任何地方对该 MCU 的程序进行升级,前提是有网络,因此,OTA 升级需要 MCU 产品具备网络功能,实现较为复杂
- 其他
当然,除了上述升级方式外,还有其他的升级方式,上述讲到的,基本属于常用的升级方式
升级过程
由上述流程图可知,收到升级请求后,就需要将接收的固件数据烧录在 MCU 的 ROM 中,实现 BOOT 或 APP 的升级,由于升级是在 BOOT 中实现的,因此该流程图只适用于 BOOT;
但对于单片机来说,RAM 的大小远远小于 ROM 的大小,无法满足一次性接收完整的固件数据到 RAM 中再编程。
既然不能一次性读取,那么可以使用分包读取写入的形式,根据 ROM 的特性决定 RAM 分包的大小,避免编程失败,通常都是 2^n 的大小,且受 ROM 擦除的方式影响,通常升级过程的流程图如下:
程序跳转
在 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 程序区的中断执行函数,具体原因可先了解中断向量表的含义及作用