MCUBoot relocation and execution update

RE: MCUBoot relocation and execution update

Ankit_chauhan — Fri, 17 Oct 2025 04:17:35 GMT

That is all I have. Thanks for the support.

RE: MCUBoot relocation and execution update

Menon — Thu, 16 Oct 2025 11:44:19 GMT

Hello,

Good to hear that you’ve found a new approach and that it’s working for you.
I’m sorry I couldn’t provide much insight into your issue. I am not familair with older nRF5 SDK , and we don’t offer official support for OTA DFU migration from nRF5 SDK to nRF Connect SDK.

However, if you have any specific questions or points of confusion, please let me know. I may need to check with my colleagues, but I’ll do my best to find an answer for you.

Kind regards,
Abhijith

RE: MCUBoot relocation and execution update

Ankit_chauhan — Thu, 16 Oct 2025 04:19:50 GMT

Thank you for the response, Abhijith.

There are a good number of devices with me that are running with legacy nRF SDK, and due to the mechanical limitations, we cannot have access to SWD pins, and it does not have any physical interface like USB that can be used to update firmware. So, the only option is the DFU OTA.

The link that I have shared in my previous reply does the same thing: replace the MCUBootloader with the nRF5 bootloader and replace the nRF5 softdevice + app section with the Zephyr application section. Here, the MBR at 0x00 is untouched, and the UICR has the address of the new MCUbootloader. So, as per your reply, it should work because now it has MBR untouched and UICR with the updated address.

I confirmed all the data by actually reading the specific flash address using nrfjprog memrd, and it contains the expected data. But still, it did not recognize the new bootloader and wiped out the entire flash, considering it as an unknown bootloader and application.

Anyway, I followed another approach where I erased the entire flash of nRF5 code and replaced the entire Zephyr application starting from 0x00(MUCBoot) and followed by the application that works for me.

Best Regards,
Ankit

RE: MCUBoot relocation and execution update

Menon — Wed, 15 Oct 2025 19:23:14 GMT

Hello,

I was discussing your case with one of my colleagues who has experience working with both the nRF5 SDK and nRF Connect SDK (NCS), as well as MCUboot.

In the nRF5 SDK, the MBR (Master Boot Record) occupies address 0x0000, and it determines which address to jump to next. After the MBR runs, it jumps to the bootloader address specified in its configuration. Therefore, MCUboot must be placed at the address where the MBR expects to find the bootloader.

From what I understand, you’re trying to achieve an NCS-based solution that replicates the same flash layout as in the nRF5 SDK, correct?If so, could you please explain the reason for taking this approach? I’m asking because this method is not the recommended configuration in NCS.

To replicate this behavior in NCS, you would need something similar to the MBR used in the nRF5 SDK. If you plan to use the MBR itself, it works by checking its own memory for the bootloader address. If it doesn’t find it there, it looks for the address at a specific location in UICR, copies it into memory, and then jumps to the bootloader.

Therefore, to use the MBR successfully, you’ll need to update your HEX file or project so that it writes the bootloader address to that specific UICR location.

Kind regards,

Abhijith

RE: MCUBoot relocation and execution update

Ankit_chauhan — Mon, 13 Oct 2025 04:33:21 GMT

Thanks Abhijith,

With the above approach, I am still not clear how to modify the MCUBoot starting address other than 0 in Zephyr. From my investigation and research, I found that technically it is possible to relocate the MCUboot other than the 0th location of flash(as far as we are setting all the details in the pm_static.yml), but practically it's not possible, and I do not know the reason.

About my approach from switching from nRF5 SDK to NCS, I know we do not have any official support on that, and hence I followed a couple of blogs, and I made it work for me.

My only question was, is it possible to launch the MCUBoot from any location of flash, as mentioned in this ticket? I have tried this, and I was not able to see the expected output. If you could help me with any sample application that does so, it would be helpful.

Thank you,
Ankit.

RE: MCUBoot relocation and execution update

Menon — Fri, 10 Oct 2025 12:36:06 GMT

Hello Ankit,

Sorry for getting back to you a bit late. Have you made any progress in the meantime?

I am not very familiar with our older nRF5 SDK, and we do not officially support OTA updates from nRF5 SDK to nRF Connect SDK. Although there are some blogs and community guides describing how to do this, none of them are official.

If you are still facing issues, please let me know, and I will ask one of my colleagues who is more familiar with the nRF5 SDK to take a look.

Kind regards,
Abhijith

RE: MCUBoot relocation and execution update

Ankit_chauhan — Mon, 29 Sep 2025 10:48:45 GMT

Hi Menon,

I am following the approach suggested by Vidar in this thread. Here, I prepared a Zephyr application with the following partition.yml

Zephyr Flash structure with application and MCU boot
Section	Start address	End address	Size
nRF5 MBR	0x00	0x1000	4KB
MCU boot primary image	0x1000	0x7C000	492KB
MCU boot secondary image	0x7C000	0xF8000	496KB
MCU Boot	0xF8000	0xFE000	24KB
MBR parameters	0xFE000	0xFF000	4KB
Bootloader settings	0xFF000	0x100000	4KB

Then I generate the DFU.zip and perform the OTA on the nRF5 application. The DFU got successful and after the soft reset what I saw is the entire image is into the recovery mode i.e. all the flash location is filled with 0xFFFFFFFF.

Then I tried to flash the same application on my device through J-Link and the device did not start. Then I change my partition.yml and set the MCUBoot at 0x00 and everything works fine.

So, from this experiment it is suspected that the location of MCUBoot may cause this issue.

RE: MCUBoot relocation and execution update

Menon — Mon, 29 Sep 2025 10:24:58 GMT

Hello,

I think it is technically possible to place the bootloader (MCUboot) at an address other than 0x0, but this is not the standard or recommended approach with NCS. Are you getting any error messages? What code or vector table currently resides at flash address 0x00000000 after the build/flash process?

Kind Regards,

Abhijith