nrfutil zip package generation with hex containing address 0x2000XXXX

Question

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 · Accepted Answer

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.

ivansanchez · Answer

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&trade;. 
 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&iuml;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.

nrfutil zip package generation with hex containing address 0x2000XXXX

Top Replies