Adjust firmware image by padding with FFs

RE: Adjust firmware image by padding with FFs

bscdb — Fri, 27 Sep 2019 06:55:08 GMT

Cool Thanks!

RE: Adjust firmware image by padding with FFs

Vidar Berg — Fri, 27 Sep 2019 06:53:28 GMT

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.

RE: Adjust firmware image by padding with FFs

bscdb — Fri, 27 Sep 2019 06:49:29 GMT

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?

RE: Adjust firmware image by padding with FFs

Vidar Berg — Fri, 27 Sep 2019 06:45:33 GMT

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

RE: Adjust firmware image by padding with FFs

bscdb — Thu, 26 Sep 2019 23:47:48 GMT

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?

RE: Adjust firmware image by padding with FFs

Vidar Berg — Thu, 12 Sep 2019 13:53:57 GMT

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.

devzone.nordicsemi.com/.../padding.py

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.

[quote user="bop123"] My guess is the page size is 4096 bytes. [/quote]

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

RE: Adjust firmware image by padding with FFs

bscdb — Wed, 11 Sep 2019 14:05:57 GMT

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.

RE: Adjust firmware image by padding with FFs

Vidar Berg — Wed, 11 Sep 2019 13:11:10 GMT

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.