MCUBoot relocation and execution update

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.

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

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

Reply
  • 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.

Children
No Data
Related