MCUBoot relocation and execution update

[Ankit_chauhan]

Hello,

I am using NCS 3.0.2 on nRF52840. I have been using MCUBoot for a long time on my device, and it is working fine. Recently, I went through a requirement where I needed to match the flash structure with my other devices, which are running on the nRF52840 with the legacy nRF5 SDK. 

In the legacy nRF5 SDK, if we see the flash sectors, the nRF bootloader is placed at the end of the flash, mostly at 0xF8000. However, in Zephyr, which uses MCUBoot, it is placed at 0x00 at the start of the flash sectors. I attempted to change the MCUBoot location using pm_static.yml, but when I flashed the code, the application failed to start. Most probably, the vector table did not find the updated MCUBoot address through the pm_static.yml, and hence it starts from 0x00; there is a bootloader.

So, my question is, is it really necessary to stick the MCUBoot at the start of the flash at 0x00? Is there any way to update this structure?. 

I've gone through this ticket of devzone where it is mentioned that we can do it, and practically it's possible, but the suggested sample was on the old NCS. Did we update anything related to this in the newer NCS?
Hang with nRF5 SDK 17.1.0 Bootloader and nRF Connect SDK 2.1.0 application

Can someone explain this scenario?

Thank you 
Ankit.

[Menon]

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

[Ankit_chauhan]

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