Adjust firmware image by padding with FFs

[bscdb]

Hi,

I am sending firmware image using my DFU master. The image needs to be divided into data objects each of 4096 bytes and then those again into 244 byte BLE packets. So for ease of computation I wanted to adjust the image by padding with zeros so that its exactly divisible by 4096. DFU master actually calculates from the app.bin file which is generated in the zip folder, so I cannot work on original .hex file. But then will the init file generated show wrong CRC value if I adjust the generated .bin file and hence will the DFU fail? Can you suggest an alternate option if any?

I'm using SDK 15.2 S132.

[Vidar Berg]

Hi,

As you said, DFU hash validation will fail if you add padding after creating you've created the init packet. However, nrfutil should work with *.bin files. So you can use the padded binary file when you generate the packet. I guess that's the easiest approach. Another option is to add padding to the hex file to ensure that the data always end at a page-aligned address.  

[bscdb]

Could you please elaborate with exact steps? My guess is the page size is 4096 bytes. I adjusted my app.hex accordingly but when creating FW.zip, it automatically discards all those FFs. Obviously padding app.bin did not work. My DFU master sends the app.bin & app.dat from FW.zip.

[Vidar Berg]

It's difficult to give exact steps since I've never done this. But did you try to use '0' instead of FFs for padding? I guess that should prevent nrfutil from discarding it. 

I've also made a quick attempt to create a python script that produces a "padding.hex" which you can merge (Merging files with mergehex) with the application hex file before generating the DFU package. It appears to be working correctly here, but please verify it on your side if you end up using it. 

Fullscreen padding.py Download

from intelhex import IntelHex
import sys

def is_page_aligned(addr):
    is_aligned = False
    if ((addr % 4096) == 0):
        is_aligned = True
    return is_aligned

if __name__ == '__main__':
    ih_original = IntelHex(sys.argv[1])
    ih_padding  = IntelHex()
    f = open("padded.hex", "w+")
    end_addr = (ih_original.maxaddr() + 1)
    print("End address before padding: " + hex(end_addr))
    while (is_page_aligned(end_addr) == False):
        ih_padding.puts(end_addr, "1")
        end_addr = end_addr + 1
    print("After padding: " + hex(end_addr))
    ih_padding.write_hex_file(f, True, 'native')

Testing the script:

1. Make sure you have the intelhex module installed in Python. Then pass the hex file as an argument to padding.py: padding.py <application>.hex

2. This should generate a new hex file named padding.hex that you can append to the application file with mergehex: merghex -m <application>.hex padding.hex -o merged.hex

3. Now to verify that this doesn't alter your program code or data. 1. load the merged hex file with nrfjprog: nrfjprog --program merged.hex --chiperase. 2. read back the data again : nrfjprog --memrd 0x0 --n <size of flash in bytes> > flash_content_w_padding.txt

4.Repeat step 3 but with the original application.hex and dump the flash content to a new text file

5. Compare the two text files with a diff tool, etc to verify that they're identical except for the padding at the end.

bscdb said:

My guess is the page size is 4096 bytes.

That is correct, they're 4096 bytes for all 52 variants. 

[bscdb]

This is working.

Because of this line - ih_padding.puts(end_addr, "1")

I'm seeing 31 (ascii hex) written on the padding.hex file. 

Can you also help me merge all the hex into one file, basically merging softdevice + bootloader + firmware?

[Vidar Berg]

Have you tried the merge tool I linked to above? You also need to merge the bootloader settings page as noted in 'appendix' 1 of this blog post: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader 

[bscdb]

Yes I've used it. I thought that merging the settings page was only to enable debugging of the app firmware, meaning I thought it was to deliberately escape checks & allow loading the app firmware. Is my understanding wrong? Is it safe to use just one hex for production?

[Vidar Berg]

It's safe to just use one hex for production. It does not bypass any security during normal boot. You can still have crc/signature boot validation of the app image.

[bscdb]

Cool Thanks!