Generate HEX file from DFU update package

[Thomas Nenning]

Hi,

For our continuous integration and deployment of firmware updates for our product, we want to test firmware upgrade paths from different versions. We are building a teststand that automatically flashes different firmware versions into a test device and checks its functionality. In order to be able to also downgrade the firmware version we flash via cable.

Unfortunately we have so far not found a way to "reverse-engineer" a DFU package, saved in our deployment cloud, back to a HEX file, so that we can flash with it with nrfjprog. The unsolved problem is how to generate the correct bootloader settings.

Can you recommend a way to get a complete HEX from a DFU package?

Best regards,

  Thomas

[AndreasF]

Hi Thomas.

I think the solution to your problem is the following:

You have to unzip the DFU package, convert the .bin file by using for example bin2hex.py, this can be installed by installing the IntelHex package (pip install intelhex), and use the --offset option.

You hve to know which SoftDevice version you use, which I will assume that you do, so that you can look up the start address in the table found in Section 3 here, and offset the Application start to that address.

For example:

If I use S132 V6.1.1 in my Application, I can read in the table that the start address should be 0x26000. The bin2hex command I would use then is:

bin2hex --offset=0x26000 <INPUT .BIN FILE> <output_file_name.hex>

Here is an example of me doing this with the ble_app_uart example:

Hope this works for you.

Best regards,

Andreas

[Thomas Nenning]

Hi Andreas,

Thanks for your quick and detailed answer. Generating an application .hex with an offset from a .bin file is unfortunately only half of the puzzle. Just flashing it without updating the CRC (and fw version) fields in the bootloader cause the bootloader to not accept the new firmware. This is where we struggle in the moment.

So far we have two, but incomplete, approaches:

1. Reading the bootloader flash page, manipulate the CRC and fw version and write it back. This is though not futureproof as the bootloader settings page layout might change with future versions
2. Display all the package information via nrfutil pkg display and generate a new bootloader settingspage. Here though we miss the information about the bootloader version and bootloader settings version which is not present in the DFU package

Do you have a third option you can recommend us and if not which of the two approaches would you recommend?

Best regards,

  Tho,as

[AndreasF]

Hi Thomas.

Could you perhaps try to combine these two approaches?

If you first use nrfutil pkg display and find the FW version of the packet, you can generate a new bootloader settings page with that FW version and use that.

Best regards,

Andreas