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.

[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

[Menon]

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

[Ankit_chauhan]

That is all I have. Thanks for the support.