Unerstanding of DFU OTA on legacy bootloder

RE: Unerstanding of DFU OTA on legacy bootloder

Hung Bui — Thu, 18 Dec 2025 13:29:21 GMT

Hi Ankit,

I believe you can have minimum size MCUboot that can fit to the bootloader. Have you looked at the example provided by Vidar ?

[quote user="Ankit_chauhan"]Also, the softdevice region is from 0x100 to 0x26000, which means the Zephyr application that is going to be updated over the Softdevice region is limited to that size.[/quote]

As far as I know it's ok for a new softdevice to increase in size. You have to provide the softdevice size (and info) at a special location inside the softdevice hex file for that.

Of course you can continue to do what you plan. But it would be easier if you follow what discussed in the embeddedrelated link. Instead of overwriting the softdevice , you simply replace the bootloader and remove the protection in the bootloader, after that run in RAM and overwrite softdevice to write your application there.

RE: Unerstanding of DFU OTA on legacy bootloder

Ankit_chauhan — Wed, 17 Dec 2025 10:48:31 GMT

Thank you for sharing the links for reference. Actually, I have been working on this for a couple of weeks and I almost gone through all possible approaches defined in the links that you shared.

Basically, the concept they suggest is to create a DFU package that can update the softdevice and bootloader with the Zephyr application and MCUBOOT. And they made it work as well. However, the sector defined in the nRF5 application for the bootloader is now 24KB, and the size of MCUboot is approximately 45-50KB. So it will not fit into that region.

I tried the suggested approach, and during DFU through the nRF Connect app, I am getting a pop-up of insufficient space, and it stops file transfer. I believe that is due to the insufficient flash sector of MCUboot, as I mentioned above.

Also, the softdevice region is from 0x100 to 0x26000, which means the Zephyr application that is going to be updated over the Softdevice region is limited to that size.

RE: Unerstanding of DFU OTA on legacy bootloder

Hung Bui — Tue, 16 Dec 2025 12:48:50 GMT

Hi Ankit,
Thanks for the info.
There actually some discussion regarding what you want to achieve.
I would suggest to take a look here: Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application

https://devzone.nordicsemi.com/f/nordic-q-a/76529/nrf5-sdk-possible-to-ota-update-to-nrf-connect-sdk?pifragment-684=2

And another solution here which is closer to what you are doing: https://www.embeddedrelated.com/showarticle/1573.php

There are a few things:

- You image must replace the softdevice. Inside the softdevice there is a MBR that doesn't get replaced , so you need to customize your application to start after the MBR.

- You need to trick the bootloader to think that your application is a valid softdevice image.

- The plan to run an application from RAM to do the copying expose a risk that if there is a reset for example power reset, when the process is on going , you may brick the device.

RE: Unerstanding of DFU OTA on legacy bootloder

Ankit_chauhan — Tue, 16 Dec 2025 12:17:42 GMT

Hello,

Thank you for the response.

My goal is to switch the nrf bootloader to MCUboot. I have multiple devices running on a legacy nRF application + bootloader. I ported this application to Zephyr + MCUBoot, and now I want to update the Zephyr application over the legacy nRF application. Due to hardware limitations, I am not able to access the SWD pins, so I cannot flash the Zephyr application straight away.

So, I have created an intermediate firmware that has two byte arrays. One array contains the raw bytes of the mcuboot binary zephyr.bin, and another array contains the raw bytes of the application binary zephyr_signed.bin.

Along with this, I have created a RAM function that copies these raw byte arrays to a specific flash location as mentioned above.

This approach is working as expected. I have tested this on devkits. After flashing the intermediate firmware over the legacy nRF application, it erases the required flash sectors, write new byte array data of the MCUboot and Zephyr application, and reboots the device. After this reboot, it starts with the MCUboot and zephyr application.

Now, I need to perform the same thing through DFU OTA. The legacy nRF application supports BLE OTA DFU, and I have created a DFU package of intermediate firmware that can be transferred to the nRF application. But this part is not working, and the reason I suspect is my initial comment.

I hope this will provide you with the required information that you are looking for. Let me know if you have doubts about any of the explanations.

Thank you,
Ankit.

RE: Unerstanding of DFU OTA on legacy bootloder

Hung Bui — Tue, 16 Dec 2025 11:59:55 GMT

Hi Ankit,

Could you explain what exactly you want to achieve by swapping the original application with the intermediate application ? Does the intermediate application has a softdevice ? What exactly the intermediate application does ? Is it flashed just to perform some operation before being swapped with another application ? Does it have a softdevice ?

How familiar you are with the secure bootloader in nRF5 SDK. What you asking for is quite advanced and not something our bootloader support originally.