BL-653(nrf52833) failed to boot the FW from secondary slot of mcuboot which is located in external flash.

[Aniket95]

I have a BL653 module and with a lot of efforts somehow I was able to successfully create a secondary slot for mcuboot in external flash connected using SPI. Every time I try to DFU over BLE the latest FW image gets loaded in external flash which is secondary slot - slot 1. But I am unable to load the latest FW image in slot-0 or to boot the latest FW from slot-1 itself. I am using nRFDeviceManager app for my experimentation and try to upload the dfu-application.zip from build folder. When  I click TEST the RTT shows  <err> mcumgr_img_grp: Faled boot_set_next with code 3, for slot 1, with active slot 0 and confirm 0. Also the app reports error Invalid image header magic(23)

Here are the snips from app

Here are the settings from mcuboot.conf file

Here is zip of my build folder

4532.build.zip

Could anyone guide me on how to boot the image from secondary slot or copy it in primary slot

[Sigurd Hellesvik]

Hi

Does it act different without the "MOVE_WITHOUT_SWAP" configuration?

Why do you use CONFIG_FLASH_LOAD_OFFSET? This configuration is normally not needed.

Regards,
Sigurd Hellesvik

[Aniket95]

Hi Sigurd,

Does it act different without the "MOVE_WITHOUT_SWAP" configuration?

- No I did not see any different behavior.

- I tried to compile with CONFIG_MCUBOOT_BOOTLOADER_MODE_DIRECT_XIP mode but it gives compilation errors partition manager complains about the mcuboot secondary image in external flash so I am trying with other options.

Why do you use CONFIG_FLASH_LOAD_OFFSET?

- I just followed this from one of the example I guess. Do you think this is the culprit?

[Aniket95]

Hi Sigurd,

I am trying to make my project setup according to the sample example that you have provided many thanks for that. I created a child_image folder and copied .overlay and .conf file in it. When I try to enable debug logs for bootloader the flash is overflowing. It seems like I need to increase the size for mcuboot I hope that could be done by pm_static.yaml, correct?

[Aniket95]

Here is my code developed for BL-653(nrf52833), if you get chance could you just check it and let me know what is going wrong 

[Sigurd Hellesvik]

Aniket95 said:

It seems like I need to increase the size for mcuboot I hope that could be done by pm_static.yaml, correct?

It could.

However, you could also set CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000 in child_image/mcuboot.conf.

I recommend not using pm_static.yml for develpement. First use pm_static.yml when you are closer to deploying your project. The main use-case for static partitioning is to make sure that the partitioning does not change in-between DFUs, as changing partitioning between DFUs is not allowed.

[Aniket95]

Hi Sigurd,

Thank you so much for your valuable inputs. I was able to perform the DFU successfully.

One final question with your suggestion I have renamed the pm_static.yml to pm.yml and am really not sure if it matters. Do you still recommend to keep the name as pm.yml or change it to pm_static.yml?

[Sigurd Hellesvik]

Aniket95 said:

One final question with your suggestion I have renamed the pm_static.yml to pm.yml and am really not sure if it matters. Do you still recommend to keep the name as pm.yml or change it to pm_static.yml?

It is not recognized as pm.yml. pm.yml is only recognized and used in child images.

The Parititon Manager will only include static partitioning in your project if you name it specifically "pm_static.yml" (or include it via build options).

[Aniket95]

Hi Sigurd,

Then I should keep the name as pm_static.yml just to make sure the memory allocated is static.

Thank you very much for the quick inputs that you have provided.