Update firmware with DFU bootloader but only use a prefix for bootloader settings

[ia0]

I'd like to update a firmware which is essentially made of 2 parts, say 0x1000-0x8000 is a "read-only" part and 0x8000-0x50000 is a "read-write" part. If I flash this firmware using with DFU, the bootloader will store the full size (0x4f000) and the associated CRC to its bootloader settings (last page of the flash 0xff000). If the firmware modifies itself (between 0x8000-0x50000) the bootloader will refuse to boot it because the CRC does not match. I'd like to tell the bootloader to only check the 0x1000-0x8000 prefix.

My current workaround is to do 2 updates:

- First the full firmware from 0x1000 to 0x50000.

- Then the prefix from 0x1000-0x8000.

Is there a better solution where I only need to do the DFU once?

[Einar Thorsrud]

Hi,

The bootloader will normally validate the entier application slot. Are you modifying the application firmware itelf, or just some other data that could be outside of the application slot? Can you elaborate both on a higher level what you want to achieve and what you are doing? Also, which SDK version are you using, and which bootloader(s) etc?

[ia0]

Hi,

Indeed, in theory the 0x8000-0x50000 range is another firmware, so can be considered data from the first firmware in the 0x1000-0x8000 range. From a high-level point of view, I have a bootloader in the 0x1000-0x8000 range that boots between 0x8000-0x50000 and 0x50000-0x98000. But I cannot flash just the bootloader alone because it won't support updates, so I'm "packing" the 0x8000-0x50000 side already inside it. Maybe something that could work would be to flash 0x8000-0x50000 first then 0x1000-0x8000 but I don't know how to start writing at a different address than 0x1000.

I don't use any SDK and I don't know which bootloader version I have, but I know it starts at 0x000E0000.

[Einar Thorsrud]

I am not able to make any specific suggetions without knowing more about what you are using.Are you using  a bootloader from an SDK? If so, which SDK and which bootloader(s)? Or do you have your custom bootloaders? Please elaborate.

[ia0]

It's the bootloader that was pre-installed when I bought the nRF52840-dongle (which was a long time ago). So I'm assuming it comes from an SDK, but I don't know the version. Is the version encoded somewhere in flash? (worst case I could dump the bootloader and compare it with all SDK bootloaders if there's an easy way to download them)

EDIT: By the way, another idea would be to disable the CRC validation of the application.

[Einar Thorsrud]

Hi,

I see. The nRF52840 dongle ships with the open DFU bootloader from the nRF5 SDK. This is a variant of the nRF5 SDK secure bootloader that only requiers signed updates for the bootladoer itself, but not other components. It does however perform a CRC check at boot, and will not start the application if it has been modified.

The application region in this case is everythign between the start and end of the application .hex file that you program. So if you program an application hex file that has data in what you refer to as "read-write" part, this will be checked during boot. However, if you place your "read-write" part after the end of the application image, the application will be considered valid even if you make changes there. Note that this region is not hard coded in the bootloader, but is updated on every DFU operation, and stored a metadata in the last page of the flash (where the nRF5 SDK bootloader stores the bootloader settings). (See nRF5 SDK bootloader documentation for more details).

[ia0]

Thanks! Yes, putting the read-write part after the end of the application image is what I want to do. I currently do it by doing 2 updates (one with everything and one with only the read-only part). From the rest of your comment (the application region is updated on every DFU operation), I guess that's the best possible. Thanks for the confirmation!