Zephyr RTOS架构下的固件升级

概述

[1 固件升级的方式](#1 固件升级的方式)

[1.1 估计升级的模式](#1.1 估计升级的模式)

[1.2 固件升级方式](#1.2 固件升级方式)

[2 双区（2 Slot）DFU和单区（1 Slot）DFU](#2 双区（2 Slot）DFU和单区（1 Slot）DFU)

[2.1 双区DFU](#2.1 双区DFU)

[2.1.1 后台式DFU设升级方式](#2.1.1 后台式DFU设升级方式)

[2.1.2 非后台式DFU的升级方式](#2.1.2 非后台式DFU的升级方式)

[2.2 单区DFU](#2.2 单区DFU)

[2.3 两种模式的比较](#2.3 两种模式的比较)

[3 nRF Connect SDK中的Bootloader](#3 nRF Connect SDK中的Bootloader)

[3.1 Bootloader的作用](#3.1 Bootloader的作用)

[3.2 nRF Connect SDK支持Boot类型](#3.2 nRF Connect SDK支持Boot类型)

[3.3 SMP DFU协议](#3.3 SMP DFU协议)

[4 nodic 平台下MCU Boot 的Flash分配](#4 nodic 平台下MCU Boot 的Flash分配)

[5 Image structure](#5 Image structure)

概述

本文简要介绍了Zephyr OS架构下固件升级的一些内容，其中包括固件升级的模式，实现原理，nordic平台下固件升级的方法，image分配的方式等内容。

1 固件升级的方式

1.1 估计升级的模式

1） DFU模式

DFU（Device Firmware Update）的中文翻译设备固件升级。DFU的升级方式有很多，除了可以通过无线方式（OTA）进行升级，也可以通过有线方式进行升级，比如通过UART，USB或者SPI通信接口来升级设备固件。

2）OTA模式

OTA（Over The Air）是实现DFU的一种方式而已，准确说，OTA的全称应该是OTA DFU，即通过空中无线方式实现设备固件升级。只不过为了方便起见，直接用OTA来指代固件空中升级（有时候也将OTA称为FOTA，即Firmware OTA，这种称呼意思更明了一些）。只要是通过无线通信方式实现DFU的，都可以叫OTA，比如4G/WiFi/蓝牙/NFC/Zigbee/NB-IoT，都支持OTA。

1.2 固件升级方式

OTA方式还是有线通信方式，DFU包括后台式（background）和非后台式两种模式。

1）后台式DFU

后台式DFU又称静默式DFU（Silent DFU），在升级的时候，新固件在后台悄悄下载，即新固件下载属于应用程序功能的一部分，在新固件下载过程中，应用可以正常使用，也就是说整个下载过程对用户来说是无感的，下载完成后，系统再跳到BootLoader程序，由BootLoader完成新老固件拷贝操作，至此整个升级过程结束。

2) 前台式DFU

前台式DFU，在升级的时候，系统需要先从应用程序跳到BootLoader程序，由BootLoader进行新固件下载工作，下载完成后BootLoader继续完成新老固件拷贝操作，至此升级结束。

2 双区（2 Slot）DFU和单区（1 Slot）DFU

双区或者单区DFU是新固件覆盖老固件的两种方式。

2.1 双区DFU

2.1.1 后台式DFU设升级方式

后台式DFU必须采用双区模式进行升级，即老系统（老固件）和新系统（新固件）各占一块Slot（存储区）。假设老固件放在Slot0中，新固件放在Slot1中，升级的时候，应用程序先把新固件下载到Slot1中，只有当新固件下载完成并校验成功后，系统才会跳入BootLoader程序，然后擦除老固件所在的Slot0区，并把新固件拷贝到Slot0中，或者把Slot0和Slot1两者的image进行交换。

2.1.2 非后台式DFU的升级方式

非后台式DFU可以采用双区也可以采用单区模式，与后台式DFU相似，双区模式下新老固件各占一块Slot（老固件为Slot0，新固件为Slot1），升级时，系统先跳入BootLoader程序，然后BootLoader程序把新固件下载到Slot1中，只有新固件下载完成并校验成功后，才会去擦除老固件所在的Slot0区，并把新固件拷贝到Slot0区。

2.2 单区DFU

单区模式的非后台式DFU只有一个Slot0，老固件和新固件分享这一个Slot0，升级的时候，进入bootloader程序DFU模式后立马擦除老固件，然后直接把新固件下载到同一个Slot中，下载完成后校验新固件的有效性，新固件有效升级完成，否则要求重来。

2.3 两种模式的比较

1）单区模式的特点

跟非后台式DFU双区模式相比，单区模式节省了一个Slot的Flash空间，在系统资源比较紧张的时候，单区模式是一个不错的选择。不管是双区模式还是单区模式，升级过程出现问题后，都可以进行二次升级，都不会出现"变砖"情况。

2）双区模式的特点

双区模式的特点是，如果升级过程中出现问题或者新固件有问题，它还可以选择之前的老固件老系统继续执行而不受其影响。而单区模式碰到这种情况就只能一直待在bootloader中，然后等待二次或者多次升级尝试，此时设备的正常功能已无法使用。双区模式牺牲了很多存储空间，但是换来了更好的升级体验。

3 nRF Connect SDK中的Bootloader

3.1 Bootloader的作用

Bootloader在其中起到的作用包括：

1）判断正常启动还是DFU升级流程，

2）启动并校验应用image，

升级的时候完成新image和老image的交换或者拷贝工作。

3.2 nRF Connect SDK支持Boot类型

nRF Connect SDK支持MCUboot，B0和nRF5 Bootloader三种Bootloader，一般推荐使用MCUboot。MCUboot位于如下目录：

cpp 复制代码

D:\ncs\v2.9.0\bootloader\mcuboot\boot\zephyr

在nRF Connect SDK中的MCUboot功能强大，兼容的芯片平台多，而且是一个久经考验的第三方开源Bootloader。MCUboot把存储区划分：Primary slot 和Secondary slot ，而且primary slot跟secondary slot两者大小是一样的，程序默认在Primary slot中执行。

需要注意的是，nRF Connect SDK对MCUboot进行了定制，在nRF Connect SDK中，程序只能在Primary slot中执行，Secondary slot只是用来存储新image，而且Secondary slot可以放在内部Flash，也可以放在外部Flash。

nRF Connect SDK中，存储器分区有如下两种典型情况：

1） MCU 内部Flash方式

2） MCU 内部Flash + Extent Flash方式

3.3 SMP DFU协议

smp 全称simple management protocol（简单管理协议），它是设备管理协议的一种，在nRF Connect SDK中，mcumgr模块实现了smp协议，或者说，smp协议按照mcumgr的要求对相应的传输数据进行编码，这样mcumgr里面注册的命令组（command group）可以直接对传输数据进行解析。

4 nodic 平台下MCU Boot 的Flash分配

笔者使用nRF52840芯片，其MCU的Flash的分配情况如下：

5 Image structure

bash 复制代码

/**
 * End-of-image slot structure.
 *
 *   0                   1                   2                   3
 *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  ~                                                               ~
 *  ~    Swap status (BOOT_MAX_IMG_SECTORS * min-write-size * 3)    ~
 *  ~                                                               ~
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                 Encryption key 0 (16 octets) [*]              |
 *  |                                                               |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                    0xff padding as needed                     |
 *  |  (BOOT_MAX_ALIGN minus 16 octets from Encryption key 0) [*]   |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                 Encryption key 1 (16 octets) [*]              |
 *  |                                                               |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                    0xff padding as needed                     |
 *  |  (BOOT_MAX_ALIGN minus 16 octets from Encryption key 1) [*]   |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                      Swap size (4 octets)                     |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                    0xff padding as needed                     |
 *  |        (BOOT_MAX_ALIGN minus 4 octets from Swap size)         |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |   Swap info   |  0xff padding (BOOT_MAX_ALIGN minus 1 octet)  |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |   Copy done   |  0xff padding (BOOT_MAX_ALIGN minus 1 octet)  |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |   Image OK    |  0xff padding (BOOT_MAX_ALIGN minus 1 octet)  |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                    0xff padding as needed                     |
 *  |         (BOOT_MAX_ALIGN minus 16 octets from MAGIC)           |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *  |                       MAGIC (16 octets)                       |
 *  |                                                               |
 *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 *
 * [*]: Only present if the encryption option is enabled
 *      (`MCUBOOT_ENC_IMAGES`).
 */