nordic——NCS(基于NCS—zephyrRTOS）下的DFU升级(ble加uart)

一、简介

　　在NCS中有多种的DFU选择，强烈推荐使用MCUboot，请直接看第三章节。当然，如果你需要选择传统的nrf_DFU也是可以的，但是要用到官方修改的源文件。

关于mcuboot，原理性的东西在官网和官方博客中有讲，可以自行查看，后面只是简单的提一下:MCUmgr — Zephyr Project Documentation (nordicsemi.com)

　　为什么要使用mcubooot，原因是在NCS使用mcuboot，可以很快的实现DFU的加入，可以同时加入ble-dfu和uart-dfu。就是加入几个宏定义的事情，就完成了在SDK中可能要花很久才能完成的工程移植，既有ble也有uart的升级。

二、nRF bootloader升级程序制作

2.1、在nrf的库中加入nRF bootloader库文件

这里是为了便于后续工程直接调用：

第一步：在nrf\subsys目录下的CMakeLists.txt文件中加入我们需要加入的库的目录文件

打开CMakeLists.txt文件在最后加入：

add_subdirectory_ifdef(CONFIG_NRF_DFU nrf_dfu)

add_subdirectory_ifdef(CONFIG_NRF_DFU_RPC_NET nrf_dfu)

第二步：在nrf\subsys目录下的Kconfig文件中加入对即将添加到nrf库的库文件nrf_dfu的宏定义配置文件应用：

打开Kconfig：加入rsource "nrf_dfu/Kconfig"，如果不加入，当我们在工程项目的.conf文件中加如引用文件的宏时会找不的相关配置宏定义而报错：

第三步：在nrf\subsys目录下建立一个文件夹：名字和我们刚刚写到CMakeLists.txt和Kconfig文件中的名字一致，名为：nrf_dfu

 

第四步：把我们需要的.c和.h文件导入，那导入的是什么文件呢，也就是SDK中的DFU使用到的相关源文件，但是请注意，由于需要移植到zephyr中，不在是传统的SDK了，有些底层文件可能要做部分修改，当然这一部分已经不需要我们来做了，原厂已经帮我们修改好了这一部分代码，我们可以直接拿来用。

主要修改的有nrf_dfu_ble.c、nrf_dfu_types.c等文件，当然不是全部修改，但是修改起来很麻烦，你需要知道整个原理，还需要了解nordic的nrf bootloader升级流程和相关函数调用。本着已经有轮子，我们就不要去造轮子的原则，我直接拿来使用。那么如何获取官方开发人员已经修改好的文件呢？相关文件工程已经同步到了github上，连接如下：aiminhua/ncs_samples: nRF connect SDK samples (github.com)

 

Ncs_samples目录下可以下载整个项目，包含了不止DFU的实例，下载后可以进入到2所显示的目录，看到3处显示的目录，这个是NCS2.2版本已经添加好的nrf bootloader方式升级的文件，你可以选择直接把这个nrf_dfu文件加入，然后替换掉nrf\subsys目录下的CMakeLists.txt和Kconfig文件，就直接使用。

但是我这还是麻烦的一下，不直接使用，只是获取到官方修改过的.c和.h文件然后再NUS的透传例程上进行直接添加得到一个BLE的OTA例子。

（总结：虽然我们不会造轮子，但是有了轮子，我们要知道这么把轮子更好的安在车上，让车跑起来，而不是只知道把轮子粗暴安上把车开起来就行，那么可能出问题的时候就一脸蒙了）

 

在nrf_dfu文件中建立两个文件夹，一个是inc，放置nrf bootloader所有使用到的.h文件，还有一个就是放置.c文件的src文件夹。并把从github上下载下来的文件中的.c和.h文件都放到对应的文件中，注意把有几个.c文件就放置在了nrf_dfu目录下，如果你想把他们也放到src中，一定要更改CMakeLists.txt中的路径配置，每一个库都要有CMakeLists.txt和Kconfig，便于编译时编译链找到你的文件。

所以整理一下目录结构如下：

第五步：添加我们nrf_dfu库文件下的CMakeLists.txt和Kconfig文件内容。

1）、对于CMakeLists.txt有 如下定义：

可以看到在1处我们使用zephyr_include_directories加入了相关头文件存放的文件夹（就和keil中加入头文件一样），在2处使用add_subdirectory_ifdef加入了会使用到的.c文件存放的文件夹；3处即为要在src文件夹中去找slip文件（或者在src文件夹中的CMakeLists.txt中那slip.c给加入，两种方式任选一种）。

 

2）、对Kconfig配置定义了我们可以使用到的一些kconfig，主要关注的是在CMakeLists.txt中我们定义的相关红定于是否在kconfig中做了申明：

编写Kconfig的部分规则：

config xxxx /*本次配置的名称*/

xxxx /*表示改配置的类型（bool、int、hex（十六进制）、string、tristate（三太类型））*/

type “xxxxxx” /*简单描述*/

default x /*初始值*/

depends on xxxx /*依赖的选项*/

help “xxxx” /*帮助信息，一般是注释*/

menu 语法以 menu 开始，endmenu 结束。中间包含若干项config配置, 当然也可以包含其他语法。

例如：

menu "test menu"

    config TEST_MENU_A

        tristate "menu test A"

    config TEST_MENU_B

        bool "menu test B"

        default n                          

endmenu

 

第六步：制作.c文件夹里面的Kconfig文件：

把src文件夹中所有的文件都加入到Kconfig中，

这里为什么少了一个起那么第6步移动的slip.c文件的加入，因为起那么说了，两种方式任选一种加入即可，这已经在外层文件的CMakeLists.txt中要应用时，加入了改文件，所以可以不用写slip.c了。

到这就算已经加入了nrf bootloader的相关库了。

2.2、程序添加

2.2.1、配置.conf文件

打开vs code，找到peripheral_uart例子然后打开（如何打开相关操作可以看nordic的入门教程），然后我们编译一下，可以看到肯定是能编译成功的。

在NUS例程中已经有一个原始的.conf文件了，那么只要往里面计入宏定义即可,没有的话，自己添加一个和板子型号一致的名字命名的.conf文件。

这已经有了，我们打开后加入如下语句：

在截图中我们加入了两个宏定义:

CONFIG_NRF_DFU=y

CONFIG_NRF_DFU_BT=y

那他们是哪里来的，为什么是这两个宏定义？回答是他们是我们刚刚制作nrf_duf库时自己亲手设置的。在第2.1的第六步中的添加的CMakeLists.txt文件中，有如下两条语句：

#添加使用的的.c文件所在的在的目录

add_subdirectory_ifdef(CONFIG_NRF_DFU src)

 

#如果定义 CONFIG_NRF_DFU_BT ，就加入ble的DFU

zephyr_library_sources_ifdef(CONFIG_NRF_DFU_BT nrf_dfu_ble.c)

可以看到分分别使用是两个语句加入了头文件和加入了nordic的ble的DFU的.c文件，他们都是说如果定义了什么什么就加入什么。到这就相信大家可以很好理解了，那么我们可以改嘛，当然可以，但是记住，如这里改了名字请在相应的Kconfig中也改对应，否则编译器还是不能正确找到并编译链接，以上两个宏定义在Kconfig中对应的定义如下：

加入后我们直接进行编译，记住保存后，点击全编译：

编译后没有编译正确，报了一个错：

说zephyr\include\zephyr\dfu\flash_img.h:32目录下的flash_img.h文件的32行居然没有定义，那直接在.config中加入该宏定义，定义为4K。发现居然打了波浪线，怀疑肯定有其依赖项没有加入，我们先编译一下看一下是否通过，编译后依然一样的报错，且查看编译后的autoconf.h文件也确实没有（他包含了工程中所有需要用到宏定义），每次加入，要从新全部构建，具体查看路径是在我们建立的工程目录下如下路径：

 

因此我们要确定其依赖项，报错说是flash_img.h文件找不到，且编译器也告诉我们路径在哪里了，那我们直接过去看一下该路径下有没有Kconfig文件：

 

发现居然我没有，却其上一级目录也没有，那可能是在flash_img.c文件处了。而不是在flash_img.h文件处，我直接在整个文件夹中去找flash_img.c（这里一般使用工具查找，很快就可以找到）。

找到flash_img.c文件:

 

在去上一级的目录果然找到一个对应的Kconfig文件：

 

打开该文件，然后全局搜索CONFIIG_IMG_BLOCK_BUF_SIZE,注意这里要去掉config进行搜索，即使用IMG_BLOCK_BUF_SIZE进行搜索，果然我们找到了该定义：

可以看到CONFIIG_IMG_BLOCK_BUF_SIZE有一个依赖项MCUBOOT_IMG_MANAGER，所以我们还要加入MCUBOOT_IMG_MANAGER这一个依赖项，即加入CONFIG_MCUBOOT_IMG_MANAGER到.conf中，大家可以看出来了，在定义Kconfig中的定义时时要去掉前面的CONFIG。

其中depends on xxx表示需要依赖于xxx的意思，前面有对kconfig语法进行了基本接收，不知道的请翻看前面。

在加入后依然没有去掉红色波浪线，且编译依然有问题，那可能CONFIG_MCUBOOT_IMG_MANAGER依然有依赖或者这个Kcongig文件有依赖。

查找后可以看到如图的定义：

需要定义IMG_MANAGER才能启用MCUBOOT_IMG_MANAGER，那么我们把CONFIG_MCUBOOT_IMG_MANAGER加入到.cofig中去，然后再次全编译。

 

没有报错，说明到目前为止我们加入正确，那么下面可以开始main.c中加入相关的DFU代码了。

 

2.2.2、在main中加入DFU功能函数

添加头文件：

#include "nrf_dfu.h"

#include "nrf_dfu_validation.h"

#include 

// 加入重启系统的头文件

#include 

加入系统重启的原因是，如果在DFU中出现错误而终止，应该复位系统，等待再次的DFU。

代码加入：

/**@brief Function for handling DFU events.
 */
static void dfu_observer(nrf_dfu_evt_type_t evt_type)
{
    switch (evt_type)
    {
        case NRF_DFU_EVT_DFU_STARTED:
        case NRF_DFU_EVT_OBJECT_RECEIVED: 
            break;
        case NRF_DFU_EVT_DFU_COMPLETED:
        case NRF_DFU_EVT_DFU_ABORTED:
            LOG_INF("resetting...");
            // 处理一条挂起的log，打印完成后才进行系统复位
            while(log_process());
                sys_reboot(SYS_REBOOT_WARM);
            break;
        case NRF_DFU_EVT_TRANSPORT_DEACTIVATED:
            // Reset the internal state of the DFU settings to the last stored state.
            LOG_INF("NRF_DFU_EVT_TRANSPORT_DEACTIVATED");
            nrf_dfu_settings_reinit();
            break;
        default:
            break;
    }
}
int dfu_init(void)
{
    int ret_val;
    ret_val = nrf_dfu_settings_init(true);
    if (ret_val != NRF_SUCCESS)
    {
        LOG_WRN("dfu settings init err %d", ret_val);
    }
    ret_val = nrf_dfu_init(dfu_observer);
    if (ret_val != NRF_SUCCESS)
    {
        LOG_WRN("dfu init err %d", ret_val);
    }
    return ret_val;
}

可以看到，首先会使用nrf_dfu_settings_init()函数初始化校验页。

 

2.2.3、制作新的固件APP和升级

改名字后编译一个APP，在我们的build_5340\zephyr（build_5340是我给我的编译目录起的名字，你也需要在你自己的建立目录在找到）目录下找到merged.hex名字的hex文件，复制一下，然后杂工程的首目录下建议一个文件件（我建立的名字为updata）

 

然后把刚刚的merged.hex放到该文件中，使用nrfutil进行升级固件制作。

建立一个.bat的脚本，或者在该目录（updata）中直接运行命令窗口，运行如下

nrfutil pkg generate --application merged.hex --application-version 2 --hw-version 52 --sd-req 0x00 new.zip

pause

由此生成了一个压缩文件：

把这个文件给到手机，然后连接上蓝牙，点击DFU，选择ZIP格式，然后选择文件，我们就可以看到如下界面了：

 

等待更新完成即可，这里注意的是使用nrf bootloader最高速度只到18KB/s,由于还需要校验等步骤，只会更慢，在我的截图上最高只到了14kB/s,平均只有5.9KB/s。因此一般不建议使用这种升级协议。建议使用MCUboot。

三、MCUboot

简单一点来说，一个bootloader应该包括两个部分，一个是DFU时数据传输协议部分、一个是对image的管理部分。

注意一点，使用MCUboot时，传输的升级固件是app_update.bin，后续生成固件后，路径如下： 编译生成文件件\zephyr 下。后续就不再说明了。

3.1、DFU数据传输协议

DFU协议一般都是把升级的image文件分成一块一块的传给bootloader，在传输过程中，DFU会完成校验每一块的数据对不对，出现错误处理等工作。值得注意的是DFU协议不管你物理通道是什么，你可以选择ble、uart、USB等。同时在zephyr中有许多的协议，只对SMP做一下简单介绍。

3.1.1、SMP dfu协议

SMP-simple management protoco（简单管理协议），在nordic的NCS支持包中，mcumgr模块就是使用了SMP协议。

Mcumgr模块使用命令组（我的立即这就是一组函数）的方式去操作SMP协议进行数据的传输。这种方式对于mcumgr来说，只管把他需要SMP做的事高数SMP，SMP会去完成组包，解包等操作，mcumgr等着SMP返回的结果就。

在mcumgr中有两个命令组是和DFU有关的：

1）、img_mgmt：image管理命令组，包括3个三个命令集4个具体的命令（4个函数）：

 

2）、os_mgmt：OS（系统）管理命令组，包括三个命令集4个具体命令（函数）：

 

在后续的例程中我们会使用两条宏定义去启动上面的两个命令组。

3.2、image管理部分

接下来是在NCS中推荐使用的DFU方式——MCUboot，其功能强大，兼容的芯片多，不仅仅是nordic，是一个开源的第三方bootloader。MCUboot的存放地址是从0x00000000开始。MCUboot把存储区域分为了两块，分别是主存储区（Primary slot）和第二存储区（Secondary slot），对于nordic的NCS中，应用程序（app）只能在主存储区运行，第二存储区（Secondary slot）可以位于芯片内（flash），也可以位于外部的flash（external flash）。

 

 

在MCUboot中是根据其定义的一个变量swap_type，其确定了是等待升级还是跳转APP。swap_type的值由三个参数决定，官网上有这样一张图，通过它们不同的组合，导致swap_type有6种不同的值，如下图所示：

 

1）、BOOT_SWAP_TYPE_TEST：

在升级后，必须调用boot_write_img_confirmed()来把image_ok这个参数写为1。再次启动时MCUboot才会认为新的image正确，否则回滚。

 

2）、BOOT_SWAP_TYPE_ PERM：

在升级后不管image_ok的值，默认新的image是正确的，没有回滚。

 

3）、BOOT_SWAP_TYPE_ REVERT

一旦检测到，就直接进行回滚。

 

4）、BOOT_SWAP_TYPE_ NONE

不进行DFU，MCU直接跳转到app运行。

 

5）、BOOT_SWAP_TYPE_ FAIL

MCUboot在进行对primary slot进行校验时没有通过，程序将一直死在MCUboot。

 

6）、BOOT_SWAP_TYPE_ PANIC

当MCUboot启动时出现致命错误时，出现也将死在MCUboot。我们要程序能运行到APP，那么就要保证swap_type的值为BOOT_SWAP_TYPE_TEST和BOOT_SWAP_TYPE_ PERM，那么我们怎么设置这两种类型呢？需要使用函数boot_request_upgrade(bool choose)。当参数choose = flash时为BOOT_SWAP_TYPE_TEST当参数choose = true时为BOOT_SWAP_TYPE_ PERM

三个参数的取值如下：

magic：全为FF和0x96f3b83d（Good）

image_ok：全为FF(或者Any、Unset)和0x01

copy_done：全为FF(或者Any、Unset)或者0x01

(any表示可能是0x11，等非0x01的值)

如下图就为MCUboot打印的信息，我们可以通过其判断现在是那种模式：

　　对应前面的第四种模式，红色框部分为当前MCUboot标志位的值，也不用我们一个一个去对，然后查表确定当前MCUboot的状态。只需要看Swap_type，也就是黄色框部分就知道是处于第几种模式，然后就可以对应当前是属于6中状态中的那种状态了。如果状态不对，就可以根据前面的状态解释来进行修改。

 

3.3、一级不可升级的安全bootloader

为什么要加一个安全，在MCUboot官网中有这样一个解释，为什么你在出门期间你信任你的家是安全的，因为你家只有一道门，由此有这样一个逻辑：

1. 你信任一扇门，因为你信任锁
2. 你信任锁，是因为你信任唯一的钥匙
3. 你信任钥匙，是因为它正在你的口袋里

由此如果你口袋中的钥匙不见了，那么你将失去对门的信任。

在每次复位或者上电后运行安全bootloader，会通过验证bootloader中的下一个image的签名和元数据来建立一个信任根本，就像确定钥匙是不是唯一且在自己的口袋中，如果任意一次验证不通过，那么bootloader就好停止，由此保证bootloader中的下一个image在被篡改后不会启动。由此杜绝攻击者通过更改固件来入侵接管设备，以保证安全性。

总结：

1）、不可变的：bootloader是flash锁定的，如果不擦除整个设备，无法进行修改或者删除。

2）、安全的：拥有一套验证机制，保证自己和用户app的安全，不会被攻击者篡改。因此要提供自己的秘钥，让bootloader进行签名验证（下一个image是否被篡改）和元数据（Metadata）校验（检测image是否兼容）。

注意本章节添加的，不管是ble的还是uart的，在升级的时候都是后台式的，升级是你可以正常使用。

3.3.1、加入MCUboot

依然选择在peripheral_uart这个NUS例子中加入MCUboot的DFU功能。那具体要用到那些宏定义配置，如何查看：

1）、一是有参考例程：zephyr\samples\subsys\mgmt\mcumgr\smp_svr，该路径的例子中有全部的config宏定义，只要对比加入就行

2）、参考官方网站的说明进行加入：Adding a bootloader chain — nRF Connect SDK 2.3.99 documentation (nordicsemi.com)。

3.3.2、工程添加修改（ble-OTA）

这里值得注意的是，不同版本之间这些CONFIG配置是会变的，所以在自己加入时一定要去看上面提到的参考，而不是无脑的复制粘贴。不然很可能你的版本和本文的版本不一样，导致你初始的工程编译都通过不了，稍后我会列举一下NCS2.1和NCS2.3的区别。

本次在NUS（透传）程序的基础上添加MCUboot，例子路径:nrf\samples\bluetooth\peripheral_uart。使用VS code建立一个该工程的映像，并且编译通过后，开始DFU的添加。

第一步：.config中加入全局宏：

注1：该全局宏定义版本是NCS2.1

# #~~~~~~~~MCUboot加入~~~~~~~~~~~~

#确保生成与MCUboot兼容的二进制文件

CONFIG_BOOTLOADER_MCUBOOT=y
 

#启用mcumgr

CONFIG_MCUMGR=y

#~~~~~ 启用大多数的核心程序，就是前面说的对SMP的命令组的启用，用于DFU传输~~~~~~

##  用于DFU支持已添加到应用程序中，因此需要重置芯片，以将控制权交给MCUboot，MCUboot将验证新上传的图像并将其与旧映像交换。最后，BOOTLOADER_MCUBOOT将MCUboot作为子映像包含在内  ##

#启用用于imager管理的处理程序（传输/列举/校验确认imager）

CONFIG_MCUMGR_CMD_IMG_MGMT=y

#启用用于操作系统管理的处理程序（用于校验出错时的回滚，以及复位操作）

CONFIG_MCUMGR_CMD_OS_MGMT=y


# 允许传输大容量的数据包

CONFIG_BT_L2CAP_TX_MTU=252

CONFIG_BT_BUF_ACL_RX_SIZE=256


# 启用mcumgr SMP 传输，SMP是传输协议。

CONFIG_MCUMGR_SMP_BT=y


#同时确保禁用掉加密传输和连接时的身份验证（如果有绑定等功能的一定要关闭）

CONFIG_MCUMGR_SMP_BT_AUTHEN=n


# 把堆栈从原来的2048改为4096，为某些需要大堆栈的命令提供空间

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

 

#由于要加入DFU到主线程，增加一点主线程的堆栈空间

CONFIG_MAIN_STACK_SIZE=2348

# #~~~~~~~~MCUboot加入结束~~~~~~~~~~~~

 

注2：这对于NCS2.3及之后版本（本文编写时更新到NCS2.3版本）：

除了在NCS2.1中加入的全局宏，还应该多加入一条全局宏。

## NCS为 NCS3.1 以及以后需要加入，启用并注册一个SPM 进程，就不用在在main中添加代码了。

CONFIG_MCUMGR_CMD_STAT_MGMT=y

 

第二步：头文件加入：

注3:针对于NCS2.1

头文件加入：

#include 

#include "os_mgmt/os_mgmt.h"

#include "img_mgmt/img_mgmt.h"

注4:如果是NCS2.0头文件加入是：

#include 

#include "os_mgmt/os_mgmt.h"

#include "img_mgmt/img_mgmt.h"

注5：如果你的是NCS2.3版本以后，已经不需要在加入头文件了。

 

第三步：DFU程序加入：

注6:针对于NCS2.及NCS2.1

官方例程中需要加入的是函数有三个，只有加入他们到main()进行初始化，才可以在初始化时把SMP相关的代码加入，如果你不加入，会导致下面的第五步升级包选择后出现错误，由于错误无法进行数据的传输：

?

1 2 3 4 5

smp_bt_register();   os_mgmt_register_group();   img_mgmt_register_group();

注7：针对于NCS2.3及以后

由于官方对底层驱动又做了升级，单独使用一个进程对SMP进行初始化，只要使用一条宏定义开启进程，就不用添加这一步分代码了，已经通过——注2 所列出的全局宏加入了进程，如下图所示,使用MCUMGR_HANDLER_DEFINE(),添加了一个进程用于初始化，而且想对应于NCS2.1使用了static定义了

img_mgmt_register_group();函数，也无法在main()进行添加了。

第三步：编译下载

然后就可以编译了，编译成功后，直接下载，就可以使用nordic的官方APP——nrf connect搜索蓝牙广播的名字，连接后，可以看到已经有了DFU的服务。

 

第四步、固件制作与升级

在工程中修改一下蓝牙广播的名字改为Nordic_NEW，然后重新构建工程：

 

然后你可以在你的工程文件的编译子文件中找到升级的bin文件。如我在建立工程时，给编译的子工程起的名字为bulid_5340:

 

那么在我的工程目录下的zephyr中会找到一个app_updata.bin文件，这就是我们新的app。

传到手机上，在nrf connect中连接设备，然后点击右上脚的DFU图标，选择app_updata.bin文件，然后，如图进行操作：

 

等待升级完成，，断开连接，复位一下，就可以看到广播名字改变了。

 

打印信息也没有问题，先是test，进入DFU升级，升级完成后，复位板子，MCUboot模式为none，表示正常启动，升级成功。

特别注意：

如果你使用的版本和我本文的不同，且按照上述步骤不能升级，很有可能就是官方做了升级，改变了部分流程，请一定一定去参看一下路径：zephyr\samples\subsys\mgmt\mcumgr\smp_svr下的例子，我以上的更改也是根据这个来更改的。

 

3.3.3、使用自定义秘钥进行固件进行签名

如果你使用过SDK开发，那么在DFU时第一步就是生成自己的秘钥并进行替换。同样在NCS中实际项目中也请使用自己的秘钥。

在前面的升级中使用了NCS中自带的秘钥，这是不安全的，你可以在编译结果中找到如下一个警告：“MCUBOOT的秘钥使用的是默认秘钥，不能用于生产使用。”

 

秘钥一定要使用自己生成的，而不是使用NCS中自带的，而且最好保证秘钥存储的位置不在你的项目中。

还有一点就是：测试的时候你如果使用默认秘钥，那么在每一次删除项目进行重新构建默认秘钥都是可能被更改的，由此导致你不能使用新的APP对使用老版本固件的设备进行升级，因为你的秘钥已经在构建过程中改变了。所以最开始的固件也最好使用新建立的工程从新烧录。

在开始前，我先把官方文档参考连接给出（注意，如果你使用的版本和我的（NCS2.3）不一样，那么请切换到和你版本一致的问的文档）：

Firmware updates — nRF Connect SDK 2.3.99 documentation (nordicsemi.com)

版本切换如下图：

第一步：秘钥生成

值的注意的是虽然生成秘钥的加密算法有许多中，但是NCS中的只支持部分，所以我们并不能随意的选择。

NCS中支持三种方式生成秘钥，分别是：

• 使用openSSL生成秘钥
• l使用imgtool生成秘钥
• 使用python生成秘钥

如下截图是官方文档中给出的不同的bootloader支持所支持的秘钥加密算法。生成的时候一定不能使用不支持。否则DFU会失败。

1）、OpenSSL方式

要使用openssl生成秘钥，那么我们就需要有openssl这个插件，你可以在网络上直接搜索openssl安装，在你的PC端安装一个openssl。如果你电脑安装的有Git、VMware、Strawberry等，那么由于这些软件都自带openssl，因此可以直接使用。

首先可以直接运行一下win+R键运行CMD，打开命令行窗口，运行一下如下命令

openssl help

结果：

居然提示不能运行，但是我电脑确定已经装了git的，并且在git运行相同的命令是可以得到响应的。由此应该由于没有把openssl的路径加到环境变量中，导致电脑找不到openssl。因此打开git的安装目录在usr/bin文件下成功找到了openssl的exe文件：

 

注意如果你也是这种方式，那么请确定好你git安装的路径。接下来我复制该路径，打开环境变量并把该路径加入带系统变量中，流程看下列截图，按照箭头的指示一路下来：

添加并确认完毕后，再次打开cmd命令行窗口，记得一定要在添加完成后再次打开，不然原本是窗口由于没有刷新，依然不能运行openssl.exe 。 

添加完毕再次运行命令：

openssl help

成功：

 

环境没有问题了，那么就可以开始制作秘钥了。

在我的工程文件中新建立一个名字为key的文件，然后再该文件中打开cmd窗口：

 

在打开的窗口运行一下指令确定依然可以在该路径下执行openssl.exe。

 

MCUboot支持的几种加密算法都是非对称加密的算法，会生成一对秘钥对，分别为私钥和公钥，公钥直接写入到MCUboot中，在NCS中我们只用把生成的私钥加入到我们的工程中，私钥或在程序的运行下生成公钥，并写入到hex中。同时也对固件进行加密。

选择RSA-2048算法来制作秘钥对：

私钥生成命令:

openssl genrsa -out private.pem 2048

然后就可以在文件夹中看到生成的秘钥了：

 

2）、使用imgtool

imgtool是一个NCS库中已经包含了的脚本工具，具体路径为：

NCS目录/bootloader/mcuboot/scripts/imgtool.py

因此要在想生成秘钥的文件夹中加入该脚本的绝对路径，如我在前一节的工程先建立的key文件夹下建立另一个文件imgtool，然后确定绝对路径，之后开始制作秘钥

命令如下：

python ../../../../v2.3.0/bootloader/mcuboot/scripts/imgtool.py keygen -t ecdsa-p256 -k priv.pem

 

由于我电脑是python，没有python3，所以我直接使用python，需要根据自己的环境进行选择：

Python3 ../../../../v2.3.0/bootloader/mcuboot/scripts/imgtool.py keygen -t ecdsa-p256 -k priv.pem

3）、使用python

命令如下：

python ../../../../v2.3.0/nrf/scripts/bootloader/keygen.py --private -o priv.pem

或者：

Python3 ../../../../v2.3.0/nrf/scripts/bootloader/keygen.py --private -o priv.pem

主要路径是nrf/scripts/bootloader/keygen.py，你要根据你需要生成的秘钥的文本去定位该路径的绝对路径。

 

第二步：替换工程编译时的秘钥

然后可以在工程目录下创建一个文件夹（可以任意，只要找得到秘钥的即可），该文件夹名字必须定义为child_image，并且在其中定义一个mcuboot.conf文件,为什么要求这么严格，因为自动建立脚本已经把响应的子文件的名字都确定好了，所以为了可以在建立时被应用到，必须按照要求来，加入完毕目录结构如下（peripheral_uart_23为项目的根目录）：

然后再mcuboot.conf中加入如下的宏定义：

CONFIG_BOOT_SIGNATURE_KEY_FILE="D:/nordic_NCS/work/peripheral_uart_23/key/priv.pem"

其中D:\nordic_NCS\work\peripheral_uart_23\key为我放置私钥的文件位置。

建立编译后可以在编译结果中找到如下的编译信息，证明替换没有问题。

 

第三步：验证升级

先烧录刚刚的固件，然后改一改蓝牙广播名字，再次建立工程。然后依然是在建立的工程目录下build_5340\zephyr（build_5340是我自定义的编译输出文件的名字，和自己定义的进行匹配），找到app_update.bin，发送到手机上，然后打开手机连接上设备。

可以看到设备现在名字是NORDIC_TEST，点击DFU，开始选择升级固件

 

选择固件：

 

然后开始升级等待，这个过程手机最好不要退出去，保持在这个界面，不然很可能导致失败：

 

升级完成，断开连接再次扫描，会看到设备的ble名字已经变了：

 

Rtt打印信息如下：

由此测试完毕。

问题解决：在升级的过程中，有遇到有些手机会由于文件系统原因，导致发送失败，如果你有同样的现象，可以换一个文件管理系统进行测试。

3.3.4、UART-DFU工程添加修改

这里要说一下,我真正需要的仅仅是mcumgr.exe,如果说你已经有了那么直接在环境变量中添加好mcumgr.exe的路径，就可以在PC端的任意路径下cmd命令启动，并使用mcuboot的串口升级。如果你是需要其他平台上可以运行的mcumgr的可执行文件，也要自己去生成一个对应平台的可执行的文件。打个比方说，如果我想在Linux系统运行mcumgr.exe去进行升级，那么我怎么获取一个在可以在Linux上可运行的mcumgr.exe。是用linux版本的go去制作。

由于我使用的是Windows，所以我下面制作的是Windows上的mcumgr.exe。

第一步：PC端上位机环境搭建

需要使用mcumgr的功能，那么上位机端也应该支持mcumgr的传输协议SMP，否则没有办法进行传输。有由于支持mcumgr的上位机命令行工具是使用 go语言开发的，所以第一步就是应该在Windows端安装go。

1）、下载go的安装包

https://golang.google.cn/dl/ 打开go的官网进行下载，根据你的系统选择对应的安装包进行下载。

由于我的是win11的64位机，所以下载第一个，如果你的系统是macOS或者是linux，那么请根据你自己最终运行的平台去选择适合的go。

 

  

下载完成后点击msi文件进行安装，可以选择你的安装路径，然后一路next下去就行。

安装好后，确定系统环境变量中是否已经把go安装目录下的bin文件路径包含进去了：

 

然后我们win+R输入cmd后在命令行窗口输入go后回车：看到如下打印，说明go环境安装完成：

 

2) 、下载mcumgr

开始使用go安装mcumgr的上位机工具(相关命令参考为zephyr官网给出的文档，连接地址如下：

MCUmgr — Zephyr Project Documentation (nordicsemi.com)):

获取MCUmgr命令(需要在有go.mod的目录运行，请看问题解决)：

go get github.com/apache/mynewt-mcumgr-cli/mcumgr

如果你无法获取，并报错，请参看后续问题解决，主要是网络原因。

下载完成后：还是无法运行mcumgr，请使用如下命令进行安装

go install github.com/apache/mynewt-mcumgr-cli/mcumgr@latest

如果mcumgr安装成功，那么在go的bin目录下会有mcumgr.exe文件

 

安装完成请确保已经把go的安装目录下的bin文件所在目录加到了环境变量中。

然后我们任意启用一个cmd命令窗口，输入mcumgr，回车，如下图，证明安装成功了。

问题解决1-缺少go.mod报错：

如果你安装的go改过默认路径或者版本原因，那么可能导致在安装文件中没有go.mod文件，在执行命令时会导致无法安装。

解决方式：在go安装路径下：

建立一个新的文件夹并命名为mod

 

然后我们进入这个文件夹，并输入一个cmd，打开命令行窗口：

然后运行指令：

go mod init mod 

 

 

然后就生成了运行时缺少的go.mod文件了：

 

然后继续运行mcumgr的安装命令进行安装即可。

 

问题解决2-网络原因下载失败：

解决了问题1，到这一步还可能会安装失败：

具体原因：默认go的代理网站是GOPROXY=https://proxy.golang.org,direct，是一个外网地址，国内访问不到（开VPN可能访问到，但是我测试时，开VPN也没有用，改代理网站没有问题），

1）、第一种方式时修改代理镜像

代理网站更改命令：

go env -w GOPROXY=https://goproxy.cn,direct

更改后，再去执行go set命令下载mcumgr。

go get github.com/apache/mynewt-mcumgr-cli/mcumgr

2）、第二种方式——直接拉取（前提是安装的有git环境）

先进入到go的安装目录下的src文件夹，然后再在src文件夹下打开cmd命令窗口，然后使用git

直接在github上拉取工具的源码。

拉取命令如下：

Git clone github.com/apache/mynewt-mcumgr-cli/mcumgr

拉取完成，安装即可。

 

第二步：创建一个工程

正常创建工程，只需要使用如下几个宏定义就行，就是加入到工程的.conf配置文件中配置就行了。

# #确保生成与MCUboot兼容的二进制文件
CONFIG_BOOTLOADER_MCUBOOT=y
# #启用mcumgr
CONFIG_MCUMGR=y

# #启用用于操作系统管理的处理程序（用于校验出错时的回滚，以及复位操作）
CONFIG_MCUMGR_CMD_OS_MGMT=y
 
# #启用用于imager管理的处理程序（传输/列举/校验确认imager）
CONFIG_MCUMGR_CMD_IMG_MGMT=y 

# #启动uart传输的宏定义
CONFIG_MCUMGR_SMP_UART=y
CONFIG_CONSOLE=y

　　这里的正常是什么意思呢？就是说你APP中没有使用到UART去做数据通讯，NUS透传的例子（peripheral_uart），原本已经使用了UART0作为应用中的数据通讯外设，这个时候不能再用UART0来作为mcuboot的升级传输口了，至少是现在的NCS_2.3版本是不行的，如果要做，那么工作量可能也会很大，不建议自己再去改底层。

　　由于我使用的测试工程就是peripheral_uart，已经默然使用uart0作为透传历程了，我只能进行更多的修改。根据不同的需求有两种更改方式：分别是使用UART0作为mcuboot的升级串口，使用UART1或者UART2等其余串口作为mcuboot的串口，二种方式都需要芯片支持多个uart，直接在app中触发升级。还有就是直接使用一个串口，升级必须在mcuboot中。

1）、使用双bank+双UART升级（uart0做smp传输通道）

这个的好处是可以实现回滚。

a、修改app中的UART为uart1

在工程中修改或者添加一个可引用的overlay文件，添加时可以选择命名为app.overlay或者_Board_.overlay(_Board_表示板子的名字)。

打开我工程下的app.overlay,使能uart1，设置引脚，并进行引用，修改完成后如下：

/ {
    chosen {
        nordic,nus-uart = &uart1;
    };
    pinctrl: pin-controller {
       nus_uart: nus_uart {
           phandle = < 0xb >;
            group1{
                psels = < NRF_PSEL(UART_TX, 1,8 ) >;
            };
            group2{
                psels = < NRF_PSEL(UART_RX, 1,6) >;
                bias-pull-up;
            };
        };
    };
}; 

&uart1 {
    status = "okay";
    pinctrl-0 = < &nus_uart >;
};

如果你直接修改，注意 phandle = < 0xb >;要确定和最终的zephyr.dts的不重复，就是一个文件不要有两个都为0xb。

以上添加方式不理解可以看如下官方给出的设备树说明博客：详解Zephyr设备树（DeviceTree）与驱动模型 - jayant97 - 博客园 (cnblogs.com)

由以上代码我们启动了uart1，并配置的P1.08和P1.06作为uart1 的通讯引脚。

 

b、加入宏定义，改变数据通讯UART的通讯方式

在前面提到的prj.conf文件中加入如下宏定义：

CONFIG_UART_ASYNC_API=y
CONFIG_UART_1_ASYNC=y
CONFIG_UART_1_INTERRUPT_DRIVEN=n

用于启动uart1的异步API，禁止中断方式，使用异步的方式通讯，如果你不加入这个三个宏定义，还是采用原本例程默认的，那么在编译下载后，通过RTT打印，你会看到如下报错：

 

 

这是说，在设置uart 的回调时，返回-88这个错误，表示系统不支持。具体原因我没有仔细确定，所以一定要进行修改。到这一步第一种uart升级就算加入完成了，直接下载就行。

2）、使用双bank+双uart升级（uart1做smp传输）

这种方式修改的就比较多了，首先是你需要修改MCUboot，让其把默认的为UART0的传输，改变为UART1。

 

a、工程目录下.conf中宏定义的修改

首先是.conf文件的修改，依然是在启动了mcuboot的基础上设置传输方式为UART，并且启动异步API,同时禁用掉UART0的中断回调方式，启动为异步回调:

CONFIG_MCUMGR_SMP_UART=y
CONFIG_CONSOLE=y

CONFIG_UART_ASYNC_API=y
CONFIG_UART_0_ASYNC=y
CONFIG_UART_0_INTERRUPT_DRIVEN=n

b、app（应用程序）的.overlay的修改

然后是APP中的.overlay的修改，（也就是我们的主应用，把其他mcuboot程序，网络核程序叫做子image）把app中触发升级的串口改为UART1，在工程根目录下的.overlay中加入配置代码：

/ {
    chosen {
        zephyr,uart-mcumgr = &uart1;
        nordic,nus-uart = &uart0;
    };
    pinctrl: pin-controller {
        dfu_uart: dfu_uart {
            phandle = < 0xb >;
            group1{
                psels = < NRF_PSEL(UART_TX, 1,8 ) >;
            };
            group2{
                psels = < NRF_PSEL(UART_RX, 1,6) >;
                bias-pull-up;
            };
        };
    };
};

&uart1 {
    status = "okay";
    pinctrl-0 = < &dfu_uart >;
};

启动了UART1，并配置uart1为mcuboot的uart传输通道。

c、修改mcuboot——子imger的overlay

打开工程目录，建立一个名字为child_image的文件夹：

然后建立一个名字为mcuboot的文件夹：

在进入并建立一个名字为boards的文件夹：

在再此文件夹中建立一个-board-.overlay的文件，其中-board-表示的是项目需要使用的板卡文件，可以简单理解为要使用那个系列的芯片就使用对应的名字：

我使用的是5340，且app运行在应用核，所以使用nrf5340dk_nrf5340_cpuapp这个名字就行。如果你不知道你使用的芯片应该怎么命名，可以在VS code中进行查看：

完整的overlay文件存放目录如下：

项目文件\child_image\mcuboot\boards

然后在nrf5340dk_nrf5340_cpuapp.overlay目录中加入如下的代码：

/ {

    chosen {

        zephyr,uart-mcumgr = &uart1;

    };

    pinctrl: pin-controller {

        dfu_uart: dfu_uart {

            phandle = < 0xb >;

            group1{

                psels = < NRF_PSEL(UART_TX, 1,8 ) >;

            };
            group2{
                psels = < NRF_PSEL(UART_RX, 1,6) >;
                bias-pull-up;
            };
        };
    };
};
&uart1 {
    status = "okay";
    pinctrl-0 = < &dfu_uart >;
};

到这一步修改就完成了，我们全编译一下，然后需要查看最终的dts文件，看我们进行的修改是否生效，只有生效了才说明是正确的。

 

d、查看配置是否生效

在全编译完整后，在如下目录先可以找到主image（也就是app）的dts文件——zephay.dts查看：

其中build_5340是我建立工程时选择的生成文件所在目录的名字（根据你自己设置的文件名确认），可以看到在：建立目录\zephyr 路径下的zephyr.dts文件中按照我们的修改正确配置了。

 

Mcuboot子inage修改的查看：

在 创建目录\mcuboot\zephyr 路径下的zephyr中也是修改成功。

 

到此为止app就算制作完了。

第三步：使用串口下载升级包

在制作完成固件后，你可以在生成一个app——修改一下蓝牙的广播名，然后获得升级固件

命令：

nrfjprog --com
mcumgr --conntype serial --connstring "COM24,baud=115200" echo hello
mcumgr --conntype serial --connstring "COM23,baud=115200" image upload -e app_update.bin

把板子连上nrf设备后，在命令行窗口运行命令：

nrfjprog --com

获取端口的COM号，如图：

 

 

由于我使用的是nrf5340，其有三个虚拟串口，从UART打印端口确定，使用的串口号为COM23。

在开始传输前必须使用测试命令确保uart已经准备好，

命令：

 

mcumgr --conntype serial --connstring "COM12,baud=115200" echo hello

 

 

如果你是使用了第二中添加串口的方式，使用nrfjprog --com命令后可能不会把你串口列举出来，可以通过串口助手参看，确定好端口后：使用更行命令：

命令：

mcumgr --conntype serial --connstring "COM23,baud=115200" image upload -e app_update.bin

等待升级完成：

 

传输完成后使用如下命令进行激活：

mcumgr --conntype serial --connstring "COM12,baud=115200" image list

由返回可以确定，我们新上传了一个固件，放在bank2中，我们需要用到这个固件的hash值，本次测试升级固件的hash：73edc83fe5a2536bc0a5b9b3015841f6f7a88444ebd75d2dfe0248f6bb3323f4

即运行：

mcumgr --conntype serial --connstring "COM12,baud=115200" image test 73edc83fe5a2536bc0a5b9b3015841f6f7a88444ebd75d2dfe0248f6bb3323f4

然后复位测试确定一下，是否可以跳转到新固件执行：

使用命令：

mcumgr --conntype serial --connstring "COM12,baud=115200" reset

运行完成后要等待一下:

可以看到新的APP运行成功。但是这不是最终的固件修改，需要如下指令来固化：

?

1	mcumgr -c acm0 image confirm 73edc83fe5a2536bc0a5b9b3015841f6f7a88444ebd75d2dfe0248f6bb3323f4

然后使用命令复位一下

nrfjprog --reset

等待一会，等程序运行起来：

使用命令：

mcumgr -c acm0 image list

可以看到激活的固件的hash是我们升级固件的hash，升级成功。