OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

Vidar Berg — Thu, 27 Nov 2025 05:47:22 GMT

I'm glad to hear you found the problem. Thank you for the update.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM — Thu, 27 Nov 2025 05:30:49 GMT

Looks like the failures were due to a couple of issues with our firmware design. Here is the summary:

We have a small algorithm that runs when the Central device requests our device to boot into DFU mode. This algorithm checks the current boot loader to determine if it has the correct values at specific flash memory locations (known a priori from an offline analysis of the boot loader program). One such address was invalid and the memory read generated a hardware fault. As a result, the application would reboot from the hard fault handler -- but in NORMAL BOOT mode and NOT in DFU mode.
The address trap values written to the FPB register was wrong. Consequently the 'flash patch' was never being triggered and applied when the boot loader was executing.

Addressing and fixing the above two bugs allowed me to update the boot loader with OTA DFU from a BLE Central device.

Cheers

RVM

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

Vidar Berg — Fri, 14 Nov 2025 10:49:53 GMT

[quote user="RMV"]I am trying to get an RTT viewer to connect and display messages from the boot loader and the application, but am not having much luck. I suspect, based on my own understanding of the RTT mechanism, and from snippets of wisdom I have seen around the DevZone and/or the internet in general, that the RTT control blocks are different between the boot loader and application builds and therefore the RTT viewer client gets confused (rightfully so). [/quote]

Correct, the RTT buffer is kept in RAM and is not linked to a fixed location, so it is likely being overwritten by the application's startup code. But would it be an idea to just try the original SDK bootloader (debug variant) on a development kit just to check whether the behavior is the same or not? I'm not sure I really understand what you are experiencing now with the bootloader. But I don't think I have seen other reports of this. I definitely haven't experienced it myself.

[quote user="RMV"]The only way I could get the entire program to link was if I expanded the boot loader to start at 0xF4000 (for NRF_LOG_LEVEL_3) or 0xF1000 (for NRF_LOG_LEVEL_4). This is really problematic at such a late stage in our product lifecycle since we have a history of using the page just below the default boot loader start address as a static, non-volatile, customer facing configuration region. [/quote]

But is this a problem if you are only doing a "debug" build? The release configuration can still have the default start address.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM — Wed, 12 Nov 2025 19:01:17 GMT

FYI, There is one more thing I want to point out here.

I am unable to link and create a 'debug' build of the Nordic boot loader on my NRF52840 board if I stick with the boot loader memory layout as suggested in Nordic memory map i.e. start at 0xF8000.

The only way I could get the entire program to link was if I expanded the boot loader to start at 0xF4000 (for NRF_LOG_LEVEL_3) or 0xF1000 (for NRF_LOG_LEVEL_4). This is really problematic at such a late stage in our product lifecycle since we have a history of using the page just below the default boot loader start address as a static, non-volatile, customer facing configuration region.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM — Wed, 12 Nov 2025 18:52:50 GMT

I am trying to get an RTT viewer to connect and display messages from the boot loader and the application, but am not having much luck. I suspect, based on my own understanding of the RTT mechanism, and from snippets of wisdom I have seen around the DevZone and/or the internet in general, that the RTT control blocks are different between the boot loader and application builds and therefore the RTT viewer client gets confused (rightfully so).

Can you suggest how I can work around this issue ?

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM — Wed, 12 Nov 2025 18:50:40 GMT

Our application firmware queries the boot loader for its version (i.e. static access to the location of a static FLASH ROM based symbol in the boot loader) and adjusts a bit field in the BLE advertisement it sends out periodically.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

Vidar Berg — Wed, 12 Nov 2025 14:11:05 GMT

[quote user="RMV"]The phone application successfully reboots the buttonless DFU app into boot loader but does not appear to stay connected long enough to perform any data transter (at least does not appear to be doing so). The remote device continuosly keeps disconnecting and the NRF Connect app on my android phone continuously attempts to connect to the DFU target device.[/quote]

Is there any disconnect reason given in the log from the phone or target device? Also, are you doing buttonless DFU with our without bond sharing (see https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/service_dfu.html)?

[quote user="RMV"]Ten minutes later, I fire it up and scan the BLE target device and it "SHOWS THE NEW BOOTLOADER IS ACTIVE". [/quote]

Does it remain stuck in bootloader DFU mode? It's supposed to time out (2 min by default) and boot back into the application. Also, for my understanding, how is it determined that the new bootloader is executing?

[quote user="RMV"]This is very strange -- why does the phone app keep attempting to connecting to the BLE device even though the remote has SUCCESSFULLY UPDATED THE BOOTLOADER?[/quote]

It sounds strange yes, and I'm not sure I understand what is actually happening in the background here.

Cheers,

Vidar

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM — Tue, 11 Nov 2025 22:57:10 GMT

Following up on the previous observations,

I am now attempting to download a newer boot loader (just the boot loader and NOT the SD+MBR and NOT the Application).

I connect to the buttonless DFU app via the Nordic Connect application on my Android phone.
I then launch the DFU process and set the Boot loader ZIP package file generated via the usual workflow that uses the 'nrfutil pkg generate' command.

The phone application successfully reboots the buttonless DFU app into boot loader but does not appear to stay connected long enough to perform any data transter (at least does not appear to be doing so). The remote device continuosly keeps disconnecting and the NRF Connect app on my android phone continuously attempts to connect to the DFU target device.

I got frustrated and shut down the NRF Connect application on my phone. Ten minutes later, I fire it up and scan the BLE target device and it "SHOWS THE NEW BOOTLOADER IS ACTIVE".

This is very strange -- why does the phone app keep attempting to connecting to the BLE device even though the remote has SUCCESSFULLY UPDATED THE BOOTLOADER?

Cheers

RVM

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

Vidar Berg — Mon, 20 Oct 2025 16:58:07 GMT

I'm afraid I don't have an explanation for why you are not seeing the same with the application present.

[quote userid="86158" url="~/f/nordic-q-a/125068/ota-dfu-of-identical-bootloader-zip-package-fails-to-relaunch-the-new-bootloader/551974"]Our boot loader protects itself from modification so I do not expect the new firmware to be actually written to the device.[/quote]

You bootloader should issue the SD_MBR_COMMAND_COPY_BL command MBR when it wants to update itself. This will trigger a reset before the copy routine starts and the flash protection will be disabled at the point.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM — Mon, 20 Oct 2025 15:40:30 GMT

In any case, I think this use case does not warrant too much investigation so I am okay to close this request.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM — Mon, 20 Oct 2025 15:38:37 GMT

Hi Vidar

Thanks for your responses. This problem does NOT show up if I start my experiments with the full system application (Buttonless DFU) and then download just the boot loader update.

NOTE: Our boot loader protects itself from modification so I do not expect the new firmware to be actually written to the device. I was simply testing that our devices resume operations with the prior boot loader itself. And that is where I ran into this issue when I used just the SD and our boot loader (without the Buttonless DFU application) on the device.

RE: OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

Vidar Berg — Mon, 20 Oct 2025 11:22:31 GMT

Hello,

Yes, this flow is supported and 0xA60 is the address to the HardFault_Handler() in the MBR, so the question is what triggered the fault. A good start to troubleshoot this might be to read out the flash before and after performing a DFU, then compare the two using a diff. If you are uploading the same bootloader binary as the one you programmed initially, you should expect the contents of the bootloader section to remain unchanged.

(https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/lib_bootloader.html )

Reading out flash with nrfjprog

nrfjprog --memrd 0x0 --n 0x100000 > flash_content.txt

Best regards,

Vidar