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

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

ia0 — Fri, 21 Mar 2025 10:12:04 GMT

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!

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

Einar Thorsrud — Fri, 21 Mar 2025 09:27:25 GMT

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).

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

ia0 — Thu, 20 Mar 2025 11:55:35 GMT

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.

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

Einar Thorsrud — Thu, 20 Mar 2025 11:16:47 GMT

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.

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

ia0 — Wed, 19 Mar 2025 15:06:28 GMT

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.

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

Einar Thorsrud — Wed, 19 Mar 2025 14:36:03 GMT

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?