DFU service support: fromelf generates multiple files, nrfutil fails

[Chuan-Zheng Lee]

I'm trying to add DFU service support to my application on an nRF51 development board, using the instructions here: Adding DFU Service support to an application. I'm using the example bootloader in those instructions.

Without DFU service support, I've already managed to use the fromelf and nrfutil tools to update firmware over DFU, using the nRF Master Control Panel app on my (Android) phone. Everything works fine: I can modify the program and the new program will be loaded.

However, when I try to add DFU service support to my application, I can't generate the ZIP file to upload to my device. Even if I remove all new DFU support code in my application, such that there is no source code change and the only change to the entire project is the addition of the requisite software components (which then aren't used), the following all still happens.

I've added the following software components to my project (which wouldn't be needed but for DFU service support): device_manager ble_dfu pstorage dfu_app_handler dfu_bootloader dfu_bootloader_settings dfu_bootloader_util dfu_transport app_scheduler app_trace crc16 hci_mem_pool hci_slip hci_transport.

Context. I'm on an nRF51 development board (so an nRF51422), and my target memory area settings for my application are:
IROM1: start 0x18000, size 0x24000
IRAM1: start 0x20002000, size 0x6000

Observation 1. Rather than a single bin file, fromelf generates a directory with two files:

> ls .\Objects\myproject.bin
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       14/09/2015     15:26              4 ER$$.ARM.__AT_0x10001014
-a----       14/09/2015     15:26          10656 ER_IROM1

Based on the ARM documentation from fromelf, I understand that this means there are two load regions.

Question 1. Am I correct in believing that the ER_IROM1 file is the actual program (which would go into the IROM1 region specified in Keil), and that the ER$$.ARM.__AT_0x10001014 file is to be programmed into the UICR register at address 0x10001014?

Observation 2. The contents of the ER$$.ARM.__AT_0x10001014 are 00 c0 03 00. I read the UICR register at 0x10001014 on my device and it seems to already have that value:

> nrfjprog --memrd 0x10001014
0x10001014: 0003C000                              |....|

Question 2. Does this mean I don't actually need to include the ER$$.ARM.__AT_0x10001014 file when generating the ZIP file using nrfutil?

Observation 3. Obviously you can't pass in a directory to nrfutil as if it were a bin file, so I tried using nrfutil on the ER_IROM1 file to generate the ZIP file (ignoring the ER$$.ARM.__AT_0x10001014 file). Then this happens:

> nrfutil dfu genpkg --application path/to/ER_IROM1 path/to/myproject.zip
Traceback (most recent call last):
  File "__main__.py", line 303, in <module>
  File "click\core.pyc", line 664, in __call__
  File "click\core.pyc", line 644, in main
  File "click\core.pyc", line 991, in invoke
  File "click\core.pyc", line 991, in invoke
  File "click\core.pyc", line 837, in invoke
  File "click\core.pyc", line 464, in invoke
  File "__main__.py", line 236, in genpkg
  File "nordicsemi\dfu\package.pyc", line 189, in generate_package
  File "nordicsemi\dfu\package.pyc", line 329, in normalize_firmware_to_bin
  File "nordicsemi\dfu\nrfhex.pyc", line 63, in __init__
  File "nordicsemi\dfu\intelhex\__init__.pyc", line 241, in loadfile
  File "nordicsemi\dfu\intelhex\__init__.pyc", line 204, in loadhex
  File "nordicsemi\dfu\intelhex\__init__.pyc", line 115, in _decode_record
nordicsemi.dfu.intelhex.HexRecordError: Hex file contains invalid record at line 1

Question 3. Is using the ER_IROM1 file is the right approach, or should I be doing something else?

On another note—the Nordic Infocenter calls the utility for generating the image file nrf.exe. This didn't exist on my installation (Master Control Panel 3.10.0.14) and nrfutil.exe seems to behave as expected, so I'm guessing that's what it was meant to be.

Edit. Another detail that might be relevant: My application doesn't use a SoftDevice, i.e., the only reason we are using BLE (or indeed the nRF51422) is because we want to use its OTA DFU capabilities. So there is no existing BLE support code in the application. Of course, the device has a SoftDevice programmed on it in order for the DFU bootloader to work.