前面几篇都在介绍Secure DFU,而在SDK 12之前版本的DFU,没有签名,称为Legacy DFU。

Secure DFU是由Legacy DFU发展而来,前面介绍的大多数概念都适用于Legacy DFU,本文做一些补充介绍。

(1)类型

总结一下DFU的类型:

DFU类型 SDK版本 特点
Secure DFU SDK 12.x + 带签名校验,Flash占用大,工具支持完善
Legacy DFU SDK 11.x – 不带签名,Flash占用小,得找很老的工具
Open DFU SDK 15.x + 仅适用于USB接口,不适用于BLE

如果使用SDK 11.x,Legacy DFU是一个自然的选择。如果使用较新的SDK,只能选择Secure DFU。

(2)升级包

Legacy DFU生成升级包需要使用nrfutil v0.3版本,而不能使用新版本(新版本已经到达3.x)。

下载安装Master Control Panel(PC版)可以在其安装目录下找到nrfutil v0.3,下载地址为:链接

nrfutil v0.3的命令行参数与新版本不一样,生成升级包的命令为:

nrfutil dfu genpkg --application app.hex dfu_app.zip

有了升级包就可以利用新版的nrfutil或nRF connect APP进行DFU。

(3)Bootloader Settings

Legacy DFU的Bootloader Settings结构比较简单,仅有一个Flag指示应用程序的有效性。

nrfutil v0.3不能生成bl_settings.hex,新版本的nrfutil生成的bl_settings.hex与Legacy DFU不兼容。

Bootloader Settings中的Flag地址是确定的,因此可以利用nrfjprog向该Flash地址写1,手动修改Flag,命令为:

nrfjprog --family NRF51 --memwr 0x3FC00 --val 1

其中0x3FC00是Bootloader Settings的储存地址,而Flag位于该地址的首字节。

同样,如果通过DFU方式升级固件,Bootloader会自动生成和维护Bootloader Settings。

(4)对比

与Secure DFU相比,Legacy DFU有一些特别的地方:

  • Bootloader占用Flash为12 kB,Secure DFU占24 kB
  • Bootloader中MTU Size只支持23,无法利用BLE 4.2的特性
  • SDK提供了ble_app_hrs_with_dfu作为DFU示例,没有一个专门的DFU示例
  • DFU服务不需要检测Bootloader,可以脱离Bootloader运行,当然跳转时会出错
  • 待续……

 

(完)

Nordic默认采用Dual-Bank模式执行DFU,即将新固件的数据保存在Flash的另一区域,而不是直接覆盖当前固件程序,只有新固件接收完毕校验通过,再复制到当前固件空间。这样能保证更新过程被意外中断,不会影响到原来的程序。

(1)Flash布局

一个典型的BLE应用程序其Flash布局图如下:

部件 含义或用途
Bootloader Settings 保存固件CRC、Size等信息
MBR Paramaters 保存MBR参数
Bootloader 执行DFU
Application 应用程序
Softdevice 协议栈
MBR(Master Boot Record) 引导Bootloader

逻辑上,将Application空间分为两部分:Bank 0和Bank 1。应用程序总是放在Bank 0,紧挨着Softdevice。Bank 1通常是空余空间。

做DFU时候,接收的新固件可以存放在Bank 0,也可以放在Bank 1:

  • 如果放在Bank 0,即覆盖当前程序,称为Signle Bank DFU。
  • 如果放在Bank 1,不影响当前程序,称为Dual Bank DFU。

Nordic SDK默认采用Dual Bank,绝大多数场景都喜欢Dual Bank,除了——Flash空间不够。

Bootloader在接收数据前会检查Bank 1的大小,如果空间足够,就执行Dual Bank,否则当前应用程序,腾出空间执行Single Bank。SDK自动完成这个判断动作。

(2)部件大小

MBR、Softdevice、Bootloader和BL Settings的大小都是确定的。对于nRF52832(512kB Flash)和Softdevice 6.0.x而言,各个部件的大小如下:

部件 地址范围 空间
BL Settings 0x0007 F000 – 0x0008 0000 4 kB
MBR Params 0x0007 E000 – 0x0007 F000 4 kB
Bootloader 0x0007 8000 – 0x0007 E000 24 kB
Appl. + Free area 0x0002 0000 – 0x0007 8000 352 kB
Softdevice 0x0000 1000 – 0x0002 6000 148 kB
MBR 0x0000 0000 – 0x0000 1000 4 kB

不同芯片的Flash大小不同,对于nRF52840芯片(1024 kB),Appl. + Free area = 352 + 512 = 864 kB,而对于nRF52810(192 kB),Appl. + Free area = 352 – 320 = 32 kB。

利用这些数值,可以粗略的判断出新的固件将要执行Dual Bank还是Single Bank。

(3)升级对象

一个完整的程序中,有三个固件:Softdevice、Bootloader和Application。

SDK支持多种组合的升级模式,不过由于Nordic的协议栈(Softdevice)已经非常成熟,Bootloader职责功能相对稳定,大多数情况下都是只升级Application。

下面借图说明升级过程。

Application(Dual Bank)

新固件先存放到Bank 1,然后再擦除Bank 0,并复制到Bank 0。

Application (Single Bank)

先将Bank 0擦除,然后直接将新固件写到Bank 0。

Softdevice + Bootloader

通常Application都依赖于Softdevice,升级Softdevice意味着也要升级Application,所以要分两个步骤:

  1. 先擦除Bank 0,将Softdevice + Bootloader当做一个固件写到Bank 0,再复制到各自区域。
  2. 再用新的Bootloader将Application升级到Bank 0。

具体流程请参考这个链接

 

(完)

从Application跳转到Bootloader中,可以采用按键(Button)触发,也可以直接用BLE命令,因此后者称为Buttonless。本文介绍Buttonless DFU服务的技术细节和使用方法。

(1)DFU服务

Buttonless DFU是一个自定义服务,它下面仅包含一个特征:

Attribute UUID Property
Secure DFU Service 0xFE59
Buttonless DFU Characteristic 0x8EC90003-F315-4F60-9FB8-838830DAEA50 Write, Indicate

Buttonless DFU特征主要职责是:从Application进入DFU Mode。

DFU Mode指芯片停驻在Bootloader中,准备或正在执行DFU相关动作。

执行这个过程,DFU Controller发送一个Enter DFU Mode的命令,该命令需要返回Response,然后从Application跳转进入Bootloader,进入DFU Mode。

在代码层面,Enter DFU Mode命令向GPREGRET寄存器写入一个标志位,然后重启。Bootloader启动时会检查该标志位。具体代码为:

uint32_t ble_dfu_buttonless_bootloader_start_finalize(void)
{
    err_code = sd_power_gpregret_clr(0, 0xffffffff);
    err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
    ...
    NVIC_SystemReset();
}

(2)添加DFU服务

SDK 15提供了一个Buttonless的模板工程:ble_app_buttonless_dfu。用户可以基于该模板,开发自己的应用。

为了理解Buttonless服务,这里向ble_app_hrs工程手动添加Buttonless DFU服务。

打开<sdk>\examples\ble_peripheral\ble_app_hrs工程,确保该工程能够正常运行。

添加源文件

在工程中增加一个文件夹nRF_DFU,并添加以下文件:

  • <sdk>\components\ble\ble_services\ble_dfu\ble_dfu.c
  • <sdk>\components\ble\ble_services\ble_dfu\ble_dfu_bonded.c
  • <sdk>\components\ble\ble_services\ble_dfu\ble_dfu_unbonded.c
  • <sdk>\components\libraries\bootloader\dfu\nrf_dfu_svci.c

添加Include目录

在工程配置窗口中找到User Include Directories,添加以下路径:

  • ../../../../../../components/libraries/bootloader
  • ../../../../../../components/libraries/bootloader/ble_dfu
  • ../../../../../../components/libraries/bootloader/dfu
  • ../../../../../../components/libraries/svc

如果使用SEGGER Embedded Studio,需要额外注意这些路径末尾的空格,可能导致不被正确识别。

添加宏开关

在工程配置窗口中找到Preprocessor Definitions,添加下列项:

  • NRF_DFU_SVCI_ENABLED
  • NRF_DFU_TRANSPORT_BLE=1
  • BL_SETTINGS_ACCESS_ONLY

配置sdk_config

在sdk_config.h中,做如下更改:

  • BLE_DFU_ENABLED = 1
  • NRF_SDH_BLE_VS_UUID_COUNT += 1

添加头文件

在main.c中添加以下头文件:

  • #include “nrf_dfu_ble_svci_bond_sharing.h”
  • #include “nrf_svci_async_function.h”
  • #include “nrf_svci_async_handler.h”
  • #include “ble_dfu.h”
  • #include “nrf_power.h”
  • #include “nrf_bootloader_info.h”

添加代码

打开Buttonless示例工程的main.c,将下列函数复制到当前工程的main.c里:

static bool app_shutdown_handler(nrf_pwr_mgmt_evt_t event){};
NRF_PWR_MGMT_HANDLER_REGISTER(app_shutdown_handler, 0);
static void buttonless_dfu_sdh_state_observer(nrf_sdh_state_evt_t state, void * p_context){};
NRF_SDH_STATE_OBSERVER(m_buttonless_dfu_state_obs, 0) = {};
static void ble_dfu_evt_handler(ble_dfu_buttonless_evt_type_t event){};

添加Buttonless DFU服务

在main.c/services_init函数末尾添加DFU服务:

ble_dfu_buttonless_init_t dfus_init = {0};

// Initialize the async SVCI interface to bootloader.
err_code = ble_dfu_buttonless_async_svci_init();
APP_ERROR_CHECK(err_code);

dfus_init.evt_handler = ble_dfu_evt_handler;

err_code = ble_dfu_buttonless_init(&dfus_init);
APP_ERROR_CHECK(err_code);    

调整内存地址

按照上面步骤依次走下来,已经可以通过编译。烧录Softdevice和Application,打开串口工具,应该看到日志消息提示内存地址和内存大小需要调整,如下:

<warning> nrf_sdh_ble: Insufficient RAM allocated for the SoftDevice.
<warning> nrf_sdh_ble: Change the RAM start location from 0x20002B90 to 0x20002B98.
<warning> nrf_sdh_ble: Maximum RAM size for application is 0xD468.
<error> nrf_sdh_ble: sd_ble_enable() returned NRF_ERROR_NO_MEM.

在工程配置窗口中找到Section Placement Macro,参照日志调整RAM的起始地址和Size。

重新编译和下载工程。

此时串口工具不再提示内存问题,但是仍然提示Fatal error。这是因为Buttonless DFU服务会检测芯片中的Bootloader,如果我们没有预先烧录Bootloader,就会出现这个错误。

 

至此,为ble_app_hrs工程添加Buttonless DFU服务,代码层面工作全部结束。

(3)Bootloader Settings

直接烧录softdevice、bootloader和application,会发现application并未运行,芯片一直跑在Bootloader中。

芯片启动后先进入Bootloader,检测Bootloader Settings中的数据,如果这些数据指示Flash中有一个有效的Application,则跳转进入Application。Bootloader Settings是Flash中的一段区域,它包含了Application的大小、CRC等数据,执行DFU时也会在这里存储状态信息。

正常执行DFU时,Bootloader自动生成和维护Bootloader Settings信息。而烧录过程不同,需要手动写入。可以根据application.hex生成一个bl_settings.hex,以产生这些数据,然后烧录这个hex。

生成bl_settings.hex的命令为:

nrfutil settings generate 
    --family NRF52 
    --application app.hex 
    --application-version 2 
    --bootloader-version 2 
    --bl-settings-version 1 
    bl_settings.hex

注意–bl-settings-version只能是1,不可以是其他值。从源代码上看它应该是个预留位,没有作用。

通过命令nrfutil settings display bl_settings.hex可以查看Bootloader Settings的内容:

(4)烧录

每次我们修改应用程序代码,都会导致现有的Bootloader Settings信息失效,需要重新生成并烧录bl_settings.hex。可以利用批处理来完成生成、烧录的动作。

第一次烧录程序时,需要烧录softdevice和bootloader:

@echo off

set app=<your app.hex path>

nrfutil settings generate --family NRF52 --application %app% --application-version 2 --bootloader-version 2 --bl-settings-version 1 bl_settings.hex

nrfjprog -e
nrfjprog --program softdevice.hex
nrfjprog --program bootloader.hex
nrfjprog --program bl_settings.hex
nrfjprog --program %app%
nrfjprog --reset

pause

后续再次烧录,可以省略烧录Softdevice和Bootloader的步骤:

@echo off

set app=<your app.hex path>

nrfutil settings generate --family NRF52 --application %app% --application-version 2 --bootloader-version 2 --bl-settings-version 1 bl_settings.hex

nrfjprog --program bl_settings.hex --sectorerase
nrfjprog --program %app% --sectorerase
nrfjprog --reset

pause

nrfjprog命令中使用了--sectorerase参数,以保证只擦除并填写指定区域。

(5)调试

调试时候会频繁的修改代码,如果每次都要重新生成和下载一遍bl_settings.hex,会疯掉。

我们可以在代码中禁止Bootloader检测Bootloader Settings,让它直接跳转进入Application。

打开Bootloader工程main.c,注释掉main.c中的下面两行代码:

ret_val = nrf_bootloader_init(dfu_observer);
APP_ERROR_CHECK(ret_val);

芯片上电后,Bootloader完全不理会DFU Mode,直接进入Application。这样就如同一个没有Bootloader的工程,可以在Application中自由的调试,也无需生成bl_settings.hex。

 

(完)