Flash data as hex with nrfutil

[raspet]

Hi!

We would like to be able to send two separate dfu-packages independently, one hex/pack containing our main application and one hex/pack containing data to be read by the application. Is this possible?

Naturally, loading the two hex images through nrf connect and jtag works but when we try through the secure bootloader (uart) the flash looks a bit messy. What would be the correct settings for generating the package containing the data hex-file?

This is what I do:

1. Load softdevice and bl through jtag

2. Generate and load the application package (with --key-file, --sd-req --application-version and --hw-version) (So far everything works, the application boots etc)

3. Put app in dfu mode

4. Generate and load data package (with --key-file, --sd-req --application-version and --hw-version)

Now the flash in nrfConnect looks different compared to when loading the hex-images through nrf connect, perhaps the second package has overwritten some parts of the original application. How should I generate a package with the second hex file going straight into flash? 

Thanks!

[mytzyiay]

> perhaps the second package has overwritten some parts of the original application

Not sure about your particular bootloader, but the one that ships on the nRF52840 dongle keeps metadata about the last DFU image in its own storage area and it hashes that data at boot time:

https://devzone.nordicsemi.com/f/nordic-q-a/85378/nrf52840-dongle-bootloader-doesn-t-like-it-when-app-is-programmed-via-nrfjprog

There may be assumptions baked into the bootloader code that everything needed by the application is contained in a single package file.

I guess you don't want to concatenate the two .hex files and flash a single package containing both?  It might be necessary to modify the stock bootloader to teach it how to manage the two package types.

[raspet]

Hi!

Thanks! I use the secure bootloader for uart provided with sdk 16. 

We would strongly prefer to be able to have the two hexes separate (at least as long as it is supported from nrfutil) 

[tesc]

Hi,

The bootloader and DFU modules from nRF5 SDK operate with three different types of update. Those are bootloader, SoftDevice and application. The placement of the application image is fixed for a given SoftDevice, see memory layout. A given update will be placed at the start address of the given range.

The upgrade image itself is a pure binary, without the address information from the hex file. In addition there is an init packet containing some meta information about the upgrade, including type of update and image size, but not including the target location for the image. You gan get this meta information for a packet through the command nrfutil pkg display packet.zip, where packet.zip is the name of your DFU zip packet.

You basically have two options. Either, provide an upgrade of the application, where your data is placed directly after the application and as such is part of the application image. Or, modify the bootloader to accept a fourth upgrade type for the data, with the required code, tests, tools upgrades (modifying nrfutil) etc. for ensuring a working solution, including mechanisms for placing the data in a location within the application area without overlap with the application itself.

For using the existing solution with one application image, you could operate with separate hex files for the application and the data, ensure that the two don't overlap, and use the mergehex utility to combine those hex files into one appliation upgrade before creating the upgrade zip file with nrfutil.

Regards,
Terje

[raspet]

Okay, thanks for the clarification!