genpkg padding for bin => zip files

[Paul]

I compile a .bin file for DFU. The bin file is 62020 bytes. I create the zip file for DFU, it is 62909 bytes.

If I extract the zip file, I get the bin file (62020 bytes), a json file (482 bytes), and a dat file (14 bytes). In other words the sum of the size of the files in the zip file is 62516 bytes which is smaller than the zip file (62909) bytes - where are the extra 393 bytes coming from?

As a rule, shouldn't the zip file be smaller than the sum of it's extracted contents?

[Hung Bui]

Hi Paul,

Well, it might not always be the case. If the compression mechanism can't do any reduction on the file size then the overhead (header) will cause the .zip file size bigger than the original files size. In this case the .bin file is pretty hard to compress.

There are some questions about that already asked.

The main reason we use a .zip file to distribute the image is to combine all in one single file, make it easier for end customer. It's not about compressing the size.

[Paul]

Hmm, would there be anything else that would inflate .bin size then for the device?

Specifically the Nordic DFU application won't let us upload a bin file that's the same size as the available application space. It must be smaller by about 889 bytes.

So our layout is:

0x0 to 0x1000 MBR

0x1000 to 0x18000 Softdevice

0x18000 to 0x37000 Application

0x37000 to 0x3FC00 Bootloader

0x3FC00 to 0x40000 Bootloader settings

The 0x18000 to 0x37000 should give us 0x1F000 of available application space or 126,976 bytes. With dual banking our max should be 63,488 bytes. In practice the upload fails if our bin file is larger than 62,428 bytes. We are trying to, but can't, account for the discrepancy. Our thought was that maybe some of this was taken up by overhead by the zip file but your answer leads me to believe that isn't the case.

[Hung Bui]

Hi Paul,

You should check the actual maximum size for application by looking at nrf_dfu_find_cache() if you are using Secure DFU in SDK 12 and up. Or look for DFU_IMAGE_MAX_SIZE_BANKED if you are using SDK v11 and ealier.

What we send over the air is not the .zip file but the actual image (the binary) so it doesn't matter how big the .zip file is but how big the .bin file is.

Note that by default we will switch to single bank automatically (on Secure DFU) if file size larger than maximum for dual bank.

[Paul]

Thanks Hung Bui,

We're trapped on SDK 10 as certification process we're required to test against requires A) Dual-bank FW updating, B) Signed Firmware, C) Encrypted Firmware - we can't do these with SDKv11+ but are able to do it on SDKv10 with the S110 firmware and our own signing/encryption process.

I am printing out the value for DFU_IMAGE_MAX_SIZE_BANKED and it's saying it's 73728 which doesn't seem right at all.

[Hung Bui]

Hi Paul, DFU_IMAGE_MAX_SIZE_BANKED is calculated inside dfu_type.h, please check what cause the difference from your calculation. If you want to run the bootloader in debug mode and set a break point, you can have a look here, at question F.