nrfutil zip package generation with hex containing address 0x2000XXXX

[Siddhesh]

Hi,
We are testing the dfu ota example for the PCA10040. In our application we have some default values and settings are stored in the RAM. nrfutil is unable to generate the zip package for our hex file. It produces a "Memory Error". 

[Vidar Berg]

Hi,

A DFU image can only contain data mapped to flash. The *.bin file would be 500+ MB if you included data in the RAM section because of byte padding (RAM start address is 0x20000000). I would suggest to store the default data in flash, and have it loaded during startup. 

[ekrashtan]

Check your .map file to see exact segment name, included in HEX, and then generate HEX from ELF using command
objcopy  -O ihex -R <RAM_segment_name_here> your.elf your.hex

You can use more than one -R key during generation

[ivansanchez]

A DFU procedure will reset the chip after it's completed (unless you are using a very custom DFU bootloader). RAM might survive a short reset in this architecture, but you should consider all RAM as dirty after a DFU.

Furthermore, you cannot be sure that the RAM addresses used on your .hex files will not be used by the DFU code when it's performing a DFU procedure. Messing up with the RAM during a DFU is a Bad Idea™.

If you need to keep user settings, use the fstorage module. Those settings will not be overwritten when DFU'ing. Keep the defaults in your code, , and write them to flash the first time your application runs, read from flash and conflate the settings with your defaults.

Siddhesh said:

It produces a "Memory Error". 

.hex represent sparse data (the same small file can have some data e.g. at 0x00001000 and some data at 0x20000800). The DFU procedure needs a contiguous file (see https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.0%2Fbledfu_memory_banks.html ). nrfutil uses a naïve algorithm to convert the sparse .hex file into a contiguous file by adding 0xFF bytes as padding anywhere in the middle. Unfortunately nrfutil does not perform any constraint check on this, because it doesn't assume any memory address layout.

[Siddhesh]

Thanks Ivan and Vidar,
I moved the retained ram data to the flash and was able to generate the zip file from the hex. The firmware was then successfully loaded o the dev board. The application works fine but I am having an error "FDS_ERR_NO_SPACE_IN_QUEUES" .  I am sure this would be an easier fix. If I run into issues I will create a new question.
Really appreciate the quick response here.