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 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

[Ankit_chauhan]

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.

[Menon]

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

[Ankit_chauhan]

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.

[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