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!

[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!