.bin file in dfu .zip package is unreasonably big / large - can't perform FWU

[Varouzan]

Hello,

I am currently working with nrf51840 on the 15.3 SDK. I am trying to generate some .zip dfu packages. Which I have been able to do before running nrfutil.exe.

For example I have used what i call "version 15" for which after I build I get a .hex file of size 344 KB. I can use nrfutil.exe and get a .bin of 122 KB. No problems with version 15.

For my version 16, I get a .hex file of size of 348 KB. However after I run nrfutil.exe I get a .bin file of size 869 KB. I can't figure out the dramatic change in size at the moment.

Of course with a .bin file that big I can't perform nor dual bank nor single bank firmware updates.

I think 344 KB is  close to the dual bank fw update size "limit" for my setup so I was expecting to have to perform single bank updates at some point, but not this.

Does anybody have any insight into this?

Thank you

[Einar Thorsrud]

Hi,

The typical reason for getting a very large bin file compared to hex file is if you have some data in flash that is very high up, giving a lot of empty space in between. With a hex file that will not increase the size, as it does not include data that is not written (All 0xff's). A bin file on the other hand is continuous, and will also include everything you do not need in between the first address you write to and the last address you write to. You can check if this is the case by for instance opening the .hex file in nRF Connect Programmer to see a graphical representation of it. Is it so?

[Varouzan]

Hey Einar

I get these 1048576 byte sectors "blank sectors" in places In wouldn't expect to see anything. But I don't know if that is some weird GUI bug or not. Because it also shows up in my software versions for which I can generate goof FWU files.

[Einar Thorsrud]

Hi,

Did you only load the application hex on the right side here? That is what we are interested in. To me it looks like you lorded also SoftDevice, bootloader etc. What I am interested in here is only the application hex, assuming that is what you try to convert to a binary file? If you try to convert a merged hex file to bin, which consists of also bootloader, SoftDevice etc. it will span the entire flash and include all the blank space as well.

I wonder if the root problem here is that you are generating the .zip file from a merged hex file? Please note that that cannot be done. You can include both SoftDevice, bootloader and application in a .zip file for DFU, but they must be separate hex files (and you refer to them by specific options in nrfutil (see nrfutil pkg generate --help).

[Varouzan]

So, I am generating the .zip file from the application .hex file. I do not include the boot loader or the soft decvie hex file.

S, I have picked up this project and there has been this recent change which I think is the culprit...

..\sw-bootloader\nrfutil\nrfutil.exe settings generate  --family NRF52840 --application Build\exe\NVT.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 Build\exe\nvt_bootloader_setting.hex

mergehex -m Build\exe\NVT.hex Build\exe\nvt_bootloader_setting.hex -o Build\exe\NVT.hex

So the boot loader setting are being merged into what I though was purely the app .hex file.Based on your response the boot loader settings .hex file should not be fed into nrfutil but purely the application.hex?

[Einar Thorsrud]

Hi,

Varouzan said:

So the boot loader setting are being merged into what I though was purely the app .hex file.Based on your response the boot loader settings .hex file should not be fed into nrfutil but purely the application.hex

This explains why you see this, then. The bin file will include all the empty space between the application and the bootloader settings page in this case (and also overlap the bootloader). The bootloader settings page should only be programmed to the device during initial programming. It is never part of the DFU zip package.