Writing data to Correct bootloader slot during DFU

[StijnGerbrandaKadex]

I have implemented a program that sends an image's .HEX file through our custom software. The data is received and parsed by an application running on an NRF5340. The relevant portion is extracted and written to the correct partition using flash_img_buffered_write.

For the application update, I use PM_MCUBOOT_SECONDARY_ID to select the partition where the data is written. This process works well—after writing the received data, the device marks the image as pending using boot_request_upgrade(BOOT_UPGRADE_PERMANENT), then resets. Upon reboot, the image is moved from the secondary partition to the primary partition, and the new firmware starts successfully.

However, when attempting to update the bootloader or network core, it’s unclear which partition ID should be used. Which partition should I write to in order to update these components? Additionally, are there any extra steps or function calls required to properly update either the bootloader or the network core? Lastly, can all three or at least two of them be updated simultaneously using this method?

I have attached the partition file to show the available partitions:
partitions.yml:

EMPTY_0:
  address: 0xfe000
  end_address: 0x100000
  placement:
    after:
    - settings_storage
  region: flash_primary
  size: 0x2000
app:
  address: 0x20200
  end_address: 0xfc000
  region: flash_primary
  size: 0xdbe00
app_image:
  address: 0x20200
  end_address: 0xfc000
  orig_span: &id001
  - app
  region: flash_primary
  size: 0xdbe00
  span: *id001
b0:
  address: 0x0
  end_address: 0x8000
  placement:
    after:
    - start
  region: flash_primary
  size: 0x8000
b0_container:
  address: 0x0
  end_address: 0x8000
  orig_span: &id002
  - b0
  region: flash_primary
  size: 0x8000
  span: *id002
external_flash:
  address: 0x11c000
  end_address: 0x800000
  region: external_flash
  size: 0x6e4000
mcuboot:
  address: 0x8200
  end_address: 0x14000
  placement:
    align:
      end: 0x1000
    before:
    - mcuboot_primary
  region: flash_primary
  sharers: 0x1
  size: 0xbe00
mcuboot_pad:
  address: 0x20000
  end_address: 0x20200
  placement:
    align:
      start: 0x4000
    before:
    - mcuboot_primary_app
  region: flash_primary
  sharers: 0x2
  size: 0x200
mcuboot_primary:
  address: 0x20000
  end_address: 0xfc000
  orig_span: &id003
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0xdc000
  span: *id003
mcuboot_primary_1:
  address: 0x0
  device: nordic_ram_flash_controller
  end_address: 0x40000
  region: ram_flash
  size: 0x40000
mcuboot_primary_app:
  address: 0x20200
  end_address: 0xfc000
  orig_span: &id004
  - app
  region: flash_primary
  size: 0xdbe00
  span: *id004
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xdc000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xdc000
mcuboot_secondary_1:
  address: 0xdc000
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0x11c000
  region: external_flash
  size: 0x40000
otp:
  address: 0xff8380
  end_address: 0xff83fc
  region: otp
  size: 0x7c
pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  placement:
    after:
    - start
  region: sram_primary
  size: 0x2000
provision:
  address: 0xff8100
  end_address: 0xff8380
  region: otp
  size: 0x280
ram_flash:
  address: 0x40000
  end_address: 0x40000
  region: ram_flash
  size: 0x0
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
s0:
  address: 0x8000
  end_address: 0x14000
  orig_span: &id005
  - mcuboot
  - s0_pad
  region: flash_primary
  size: 0xc000
  span: *id005
s0_image:
  address: 0x8200
  end_address: 0x14000
  orig_span: &id006
  - mcuboot
  region: flash_primary
  size: 0xbe00
  span: *id006
s0_pad:
  address: 0x8000
  end_address: 0x8200
  placement:
    after:
    - b0_container
    align:
      start: 0x4000
  region: flash_primary
  share_size:
  - mcuboot_pad
  size: 0x200
s1:
  address: 0x14000
  end_address: 0x20000
  orig_span: &id007
  - s1_pad
  - s1_image
  region: flash_primary
  size: 0xc000
  span: *id007
s1_image:
  address: 0x14200
  end_address: 0x20000
  placement:
    after:
    - s1_pad
    - s0
  region: flash_primary
  share_size:
  - mcuboot
  size: 0xbe00
s1_pad:
  address: 0x14000
  end_address: 0x14200
  placement:
    after:
    - s0
    align:
      start: 0x4000
  region: flash_primary
  share_size:
  - mcuboot_pad
  size: 0x200
settings_storage:
  address: 0xfc000
  end_address: 0xfe000
  placement:
    align:
      start: 0x4000
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20002000
  end_address: 0x20070000
  region: sram_primary
  size: 0x6e000

partitions_CPUNET.yml:

app:
  address: 0x1008800
  end_address: 0x1040000
  orig_span: &id001
  - hci_ipc
  region: flash_primary
  size: 0x37800
  span: *id001
b0n:
  address: 0x1000000
  end_address: 0x1008580
  placement:
    after:
    - start
  region: flash_primary
  size: 0x8580
b0n_container:
  address: 0x1000000
  end_address: 0x1008800
  orig_span: &id002
  - b0n
  - provision
  region: flash_primary
  size: 0x8800
  span: *id002
hci_ipc:
  address: 0x1008800
  end_address: 0x1040000
  region: flash_primary
  size: 0x37800
provision:
  address: 0x1008580
  end_address: 0x1008800
  placement:
    after:
    - b0n
  region: flash_primary
  size: 0x280
sram_primary:
  address: 0x21000000
  end_address: 0x21010000
  region: sram_primary
  size: 0x10000

[AHaug]

Hi,

I've picked up your case and will be looking into it. Could you verify which NCS version you're working with? It's quite relevant to isolate if you're working with companion components an dsysbuild or if you're working with child_images and parent images.

Let me know and I'll get back to you

Kind regards,
Andreas

[StijnGerbrandaKadex]

Hi AHaug,

I'm using SDK V2.9.0 and toolchain V2.9.0.
Building the project with Sysbuild

The build configuration:


I hope this is the information you are looking for.

[AHaug]

Hi,

Yes, this is what I was looking for

However, when attempting to update the bootloader or network core, it’s unclear which partition ID should be used. Which partition should I write to in order to update these components?

There's the sysbuild-assigned image ID's https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.html and from sysflash/ and pm_sysflash.h the area slots can be seen defined as 

/* Each pair of slots is separated by , and there is no terminating character */
#define FLASH_AREA_IMAGE_0_SLOTS    PM_MCUBOOT_PRIMARY_ID, PM_MCUBOOT_SECONDARY_ID,
#define FLASH_AREA_IMAGE_1_SLOTS    PM_MCUBOOT_PRIMARY_1_ID, PM_MCUBOOT_SECONDARY_1_ID,
#define FLASH_AREA_IMAGE_2_SLOTS    PM_MCUBOOT_PRIMARY_2_ID, PM_MCUBOOT_SECONDARY_2_ID,
#define FLASH_AREA_IMAGE_3_SLOTS    PM_MCUBOOT_PRIMARY_3_ID, PM_MCUBOOT_SECONDARY_3_ID,

#if CONFIG_MCUBOOT_MCUBOOT_IMAGE_NUMBER != -1
#ifdef CONFIG_NCS_IS_VARIANT_IMAGE
#define MCUBOOT_S0_S1_SLOTS PM_S0_ID, PM_MCUBOOT_SECONDARY_ID,
#else
#define MCUBOOT_S0_S1_SLOTS PM_S1_ID, PM_MCUBOOT_SECONDARY_ID,
#endif
#else
#define MCUBOOT_S0_S1_SLOTS
#endif

Additionally, are there any extra steps or function calls required to properly update either the bootloader or the network core?

This is a pretty wide question and the answer may depend on how familiar you are with the procedure, so here's a few general extra steps

For updating MCUBoot: If you're running MCUboot from s0, you need to upload the image built for s1 with a newer revision number than the previous revision. The Immutable bootloader b0 will then boot MCUboot from the newer revision.

For updating netcore: If you're doing non-simutaneous DFU of appcore and netcore, make sure that you're uploading a new netcore variant that is compatible with the appcore currently running there. If they are incompatible and you do nonsimultaneous, your risk breaking the interface. An example of this is updating the netcore from hci_rpmsg to hci_ipc without also updating the appcore to be compatible with the two different interfaces.

Let me know if you have any more specific questions and I'll answer those as well! 

Kind regards,
Andreas

[StijnGerbrandaKadex]

AHaug said:

There's the sysbuild-assigned image ID's https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.html 

Using this source and others, can I conclude that for both the application and the upgradable bootloader, I should write to PM_MCUBOOT_SECONDARY_ID and the corresponding address values? And for the network core, I should write to PM_MCUBOOT_SECONDARY_1_ID? (I understand more complex ways to get to these IDs are available, but for simplicity, is this conclusion correct?)

AHaug said:

For updating MCUBoot: If you're running MCUboot from s0, you need to upload the image built for s1 with a newer revision number than the previous revision

For MCUBoot, I understand that writing the image to PM_S0_ID and PM_S1_ID is not supported, and writing to PM_MCUBOOT_SECONDARY_ID will allow MCUBoot to move it to the empty slot itself. I just need to upload the correct image. This results in two questions:

1. How do I test which slot is currently in use?

2. Can I manually set and test the revision number for MCUBoot, and how should this be achieved?

AHaug said:

For updating netcore: If you're doing non-simutaneous DFU of appcore and netcore

I am performing the update over Ethernet through the network stack. As I understand, this runs mostly, if not entirely, on the application core. Should I still be worried about breaking the interface if I don't mind the device not working between the update of the application core and the network core?

Performing simultaneous updates would be the preferred method. I am using external flash to allow for this. Can I safely write both the application and the network core to their corresponding slots and assume the update will work for both cores after calling boot_request_upgrade()? (Assuming the image is correct and the revision numbers are higher.)

And can I manually set and test the revision number for the network core, and how should this be achieved?

[AHaug]

Hi,

Apologies for the delay

StijnGerbrandaKadex said:

Using this source and others, can I conclude that for both the application and the upgradable bootloader, I should write to PM_MCUBOOT_SECONDARY_ID and the corresponding address values? And for the network core, I should write to PM_MCUBOOT_SECONDARY_1_ID?

Yes, this is correct. 

W.r.t the bootloader: It has to be first temporarily stored within mcuboot_secondary_application slot before it is moved to either s0 or s1 depending on the image you're uploading (as you describe in your next question). 

Net core secondary corresponds to _secondary_1 ID

StijnGerbrandaKadex said:

How do I test which slot is currently in use?

For TF-M based applications there is atleast this function https://github.com/nrfconnect/sdk-nrf/blob/1e2a4672d46f1c9355e60db3c724efda2dcbb97e/modules/trusted-firmware-m/tfm_boards/src/tfm_ioctl_ns_api.c#L62 

But I haven't found anything for non-tfm yet. I suspect the user must either simply know which slot is currently running and update the correct one there, or that there exists a way to read the header of the currently running MCUboot version and read the version/slot from there. In other words, the user needs to keep control of this and if the image does not fit the criteria for a successful update (wrong version, wrong slot) it will be rejected.

StijnGerbrandaKadex said:

Can I manually set and test the revision number for MCUBoot, and how should this be achieved?

You can use SB_CONFIG_SECURE_BOOT_MCUBOOT_VERSION, https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/sysbuild_image_ids.html#mcuboot_update_package_version 

StijnGerbrandaKadex said:

I am performing the update over Ethernet through the network stack. As I understand, this runs mostly, if not entirely, on the application core. Should I still be worried about breaking the interface if I don't mind the device not working between the update of the application core and the network core?

The only time this will occur is if you do a non-simultaneous update of the application core to a new version that can't talk to the network core. For instance if you run hci_rpmsg (which we don't use after 2.6.0 if I remember correct) to hci_ipc. Or if you change to a different, custom or third party radio core image. Here's an example of breaking the interface:

1. Build and flash new firmware where you use hci_rpmsg on the netcore (lets say NCS v2.4.0)
2. Migrate your firmware to ncs v2.9.0 where you use hci_ipc. Everything works in test on your DK because here you're using firmware on the appcore that can communicate with the hci_ipc image.
3. Perform non-simultaneous DFU of the application core only
4. After the update, the appcore can't talk to the netcore, because on the netcore you still run hci_rpmsg -> you can't use BLE any more. From here, serial recovery is your only option to recover the device

StijnGerbrandaKadex said:

Performing simultaneous updates would be the preferred method. I am using external flash to allow for this. Can I safely write both the application and the network core to their corresponding slots and assume the update will work for both cores after calling boot_request_upgrade()? (Assuming the image is correct and the revision numbers are higher.)

Yes, this matches my understanding of it, given that you make sure to add in the consideration above.

StijnGerbrandaKadex said:

And can I manually set and test the revision number for the network core, and how should this be achieved?

This isn't quite what you want, but in https://github.com/nrfconnect/sdk-mcuboot/blob/148712e7b4618aadbedd04e8d3ce5c3847d3be4f/boot/bootutil/src/loader.c#L1063 where pcd_version_cmp_net reads the image header of the current image state (CONFIG_MCUBOOT_NETWORK_CORE_IMAGE_NUMBER, which is 1), but nothing that talks about image versioning for application similar to https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/build/version/index.html. It does however not say that you can not have this versioning for sysbuild/hci_ipc/.

Kind regards,
Andreas