Problem with DFU swap move netcore update on nRF5340

[thomas.rieder]

Hi!

I’m currently setting up multi-image DFU on the nRF5340 using external flash.

By following the official documentation and samples, I managed to get it working correctly for the app core. However, just before the swap starts for the net core, I hit an assert after the call to the boot_read_image_size function in the boot_swap_image function within the loader.c file of MCUboot.

After adding some logs, I noticed that MCUboot either fails to read the mcuboot_primary_1 partition or the partition is completely empty.

I’ve read in some samples that multi-image updates do not support image swapping yet, but is that still the case with version 3.0.0?

Because it seems strange that with the hook boot_read_image_header_hook(...) in nrf53_hooks.c, it would actually be possible to read the mcuboot_primary_1 partition from within MCUboot.

For reference, I’m using the following sysbuild configuration:

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_PARTITION_MANAGER=y

SB_CONFIG_BOOT_SIGNATURE_TYPE_ED25519=y
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="..."

SB_CONFIG_NETCORE_IPC_RADIO=y
SB_CONFIG_NETCORE_IPC_RADIO_BT_HCI_IPC=y

SB_CONFIG_SECURE_BOOT_NETCORE=y
SB_CONFIG_MCUBOOT_MODE_SWAP_WITHOUT_SCRATCH=y
SB_CONFIG_NETCORE_APP_UPDATE=y
SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=2
SB_CONFIG_MCUBOOT_APP_SYNC_UPDATEABLE_IMAGES=y
SB_CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y

Thanks in advance for any answers to my questions!

[Vidar Berg]

Hello,

The mcuboot_primary_1 is an emulated flash partition in RAM and is only accessible from the bootloader (MCUBoot) and not the main application. The app may report an error when it tries to iterate through the mcuboot slots and hits mcuboot_primary_1, but it's safe to ignore. I recommend having a look at our devacademy course at https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/ if you have not already. 

Best regards,

Vidar

[thomas.rieder]

Thank you for your response, that’s exactly what I had understood.

But if I understand correctly, the DFU from the main application writes the new image to the external flash, and then after a reset, MCUBoot checks the flags in the image located in the external flash and, if necessary, performs the swap. It’s during this last step that my error occurs—more precisely, when MCUBoot tries to read information from the mcuboot_primary_1 partition (in the simulated flash in RAM).

Here are the logs after reboot (before the swap performed by MCUBoot)

It happens after the call to the boot_read_image_size(...) function in loader.c, inside boot_swap_image(...).

and the pm_static.

mcuboot:
  address: 0x0
  region: flash_primary
  size: 0x32000    # 200kB

mcuboot_pad:
  address: 0x32000 
  region: flash_primary
  size: 0x200 # 512B

app:
  address: 0x32200
  region: flash_primary
  size: 0xBDE00    # Adjusted for new mcuboot size

mcuboot_primary:
  address: 0x32000 
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xBE000    # Adjusted for new mcuboot size
  span: *id001
  
mcuboot_primary_app:
  address: 0x32200
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xBDE00    # Adjusted for new mcuboot size
  span: *id002

mcuboot_primary_1:
  address: 0x0
  size: 0x40000
  device: flash_ctrl
  region: ram_flash

mcuboot_secondary:
  address: 0x00000
  size: 0xBE000    # Adjusted to match mcuboot_primary
  device: DT_CHOSEN(nordic_pm_ext_flash)
  region: external_flash
  
mcuboot_secondary_1:
  address: 0xBE000
  size: 0x40000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  region: external_flash
  
pcd_sram:
  address: 0x20000000
  size: 0x2000
  region: sram_primary

Do you have any idea why, when MCUBoot tries to read primary_1, it only reads 0xFF values, which correspond to erase values if I understood correctly?

[Hieu]

Hi thomas.rieder,

Vidar is out of office, and I will support you in his stead.

I suspect something is wrong with the partitioning somehow. What will happen if you build without a pm_static.yml?

I notice that at least the device value of mcuboot_primary_1 is incorrect. It should be nordic_ram_flash_controller.

If the build without pm_static.yml can work correctly, I recommend copying the partitions.yml file under the build directory out and use that as the base for your new pm_static.yml.

Also, could you share more info about the samples that say this? I would like to check the full context.

I’ve read in some samples that multi-image updates do not support image swapping yet, but is that still the case with version 3.0.0?

Hieu

[thomas.rieder]

Hieu said:

Also, could you share more info about the samples that say this? I would like to check the full context.

I found a comment in this file and in the others "matter" sample 

Hieu said:

I notice that at least the device value of mcuboot_primary_1 is incorrect. It should be nordic_ram_flash_controller.

Ok Thank you I will try with this device !

[Hieu]

thomas.rieder said:

Hieu said:

Also, could you share more info about the samples that say this? I would like to check the full context.

I found a comment in this file and in the others "matter" sample 

I checked with the comment's author. Indeed, multi-image swapping is still not supported in NCS v3.0.x.

The swapping mechanism is still in use to put the new image into their proper locations. However, that process cannot be reverted.

thomas.rieder said:

Hieu said:

I notice that at least the device value of mcuboot_primary_1 is incorrect. It should be nordic_ram_flash_controller.

Ok Thank you I will try with this device !

Hope it works!