nordic DFU一文解决所有问题＜二＞

首先很简单, 我们要实现一个dfu的服务, 需要准备以下几个hex文件:

1. 你的应用app, 就是一个带有dfu service的若干业务的service, 废话, 完整的应用固件, 固件的flash起始位置根据sdk17.1的sd的结尾的page位置决定, 只能是0x26000, 这个我上一节已经说过了. 值得一提的是ram的起始位置是由你的蓝牙协议栈的自定义char的多少, 广播数据的多少以及乱七八糟的东西来决定的, 如果系统起不来, 多半是你的内存设置的多少的问题造成的, 正常如果你打开了log, 它启动失败后会提示你起始内存应该的位置及大小, 你做对应的修改即可.
   app 的main里面还要加入
   err_code = ble_dfu_buttonless_async_svci_init();
   APP_ERROR_CHECK(err_code);
   平时debug的时候由于要随时修改app的内容, 就不能烧录bootloader了, 需要把上面这两句注释掉.

2. bootloader的hex非常简单了, 直接在keil里面编译secure bootloader即可, 这里面可能遇到的问题就是, 一开始提示你找不到加密的工具uECC,
   …\components\libraries\crypto\backend\micro_ecc\micro_ecc_backend_ecc.h(52): error: #5: cannot open source input file “uECC.h”: No such file or directory
   在\nRF5_SDK_17.0.2_d674dde\external\micro-ecc目录, 找到一个bat脚本
   这个时候需要在windows里面安装:
   Git: git直接就官网下git windows版本就好.
   make: make就安装MinGW, 然后把C:\MinGW\bin目录放入系统的环境变量, 并且把mingw32-make改名成make即可
   
   GCC compiler toolchain for ARM, 直接下载安装即可.
   然后运行\nRF5_SDK_17.0.2_d674dde\external\micro-ecc目录下的那个bat脚本

make的时候, 如果提示找不到gcc(几乎一定的)就修改sdk里面的定义:
C:/Users/zunly/Downloads/DeviceDownload/nRF5_SDK_17.1/components/toolchain/gcc/Makefile.windows

再次编译secure_bootloader
提示
…\dfu_public_key.c(20): error: #35: #error directive: “Debug public key not valid for production. Please see https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/README.md to generate it”
找不到公钥.

3. 接下来就需要用nrfutil生成私钥之后, 再生成公钥
   首先是上一节的内容, 用pip+python3.7安装好nrfutil, 运行这个命令:

nrfutil keys generate private.pem

这个命令的意思就是生成一个随机的私钥, 文件名就是private.pem, 私钥就是你要保存好的东西, 相当于你的diku.保管好.
具体私钥的内容也不重要, 你也别想象成密码啥的, 总之就是要保管好的东西.

接着, 将私钥转成.c文件
nrfutil keys display --key pk --format code private.pem --out_file dfu_public_key.c

复制到nRF5_SDK_17.1\examples\dfu文件夹下替代原有的, 再编译bootloader就ok了.

编译的时候将hex文件改名为:
secure_bootloader_ble_s132_pca10040.hex, 这样可以区分bootloader跟app了.
现在我们有了bootloader的hex.

4. sd的hex在sdk下面, 不用动了, 只要把所有hex复制出来, 归拢包堆儿.

5. 现在, 我们有了app的hex, sd的hex, 跟bootloader的hex, 还需要一个bootloader-setting的东西, 也是使用nrfutil来生成:

nrfutil settings generate --family NRF52 --application solid_version_0515.hex --application-version-string "1.0.0" --bootloader-version 1 --bl-settings-version 2  bl-settings.hex

这个命令的参数可以自解释了, 应用的hex名,生成的bl-setting的hex名, 可以看得出, 这个bl-setting只取决于app, 它会自动打印bl-setting的内容, 或者nrfutil settings display bl-settings.hex查看:

这是人家的一张图, 解释得挺清楚的, 看得出吧, 里面有个Application Size跟CRC, 你要是这里的跟app的不符, bootloader就不会从app启动了, 当你通过dfu更新了app之后, bl-setting就会随之更新.

6. 接下来把这4个hex合在一起, 方便烧录:

mergehex --merge s132_nrf52_7.2.0_softdevice.hex secure_bootloader_ble_s132_pca10040.hex bl-settings.hex ble_app_buttonless_dfu_pca10040_s132.hex --output all_ble_buttonless_dfu_nrf52832_s132.hex

其实就是把hex做了一个缝合, 输出为all_ble_buttonless_dfu_nrf52832_s132.hex

7. 把这个4合1的hex烧录进去.
   如果没有意外, 一般是自动启动到app里面的了.

8. 问题汇总:
   a. secure_bootloader是不能打印log的, 因为bl的空间有限, 加了打log就超了.
   b. 如果你发现一直卡在DFU_TARG广播中, 说明app校验失败了.
   c. 如果没法debug, 说明bootloader启动有问题, 压根进不去app, 所以没法debug
   d. 如果你压根没有烧录bootloader, 也无法对app进行debug, 可能是sd的内存设置有问题, 大了小了都由可能起不来的.
   e. 带G结尾的52832会在烧录的时候经常自动对芯片进行了读保护, coding的时候尽量别用G结尾的型号.
   f. 开发阶段可以考虑不要烧录bootloader, 不然没法过app crc校验.
   g. 总之一句话, bootloader+dfu, 并不难, 只是比较杂, 比较乱, 而且经常是搞一次, 以后就不搞了, 所以不熟悉, 仅此而已.