nrf5340 custom board non-simultaneous updates without external flash with sysbuild on ncs2.7.0+

[AlejandroM]

Hello!

I was wondering if there is any advice from trying to get Non-simultaneous firmware updates using sysbuild with the following constraints:

• Must update both App Core and Netcore
• Non-Simultaneous preferably
• Without External flash
• Custom board
• Custom Netcore (DTM/In-house Manufacturing)
• Using sysbuild (because we were advised to move to 2.8.0 and sysbuild is now a must)
• Using SMP

During our development we got this working on ncs 2.6.X, and we can do all the above without sysbuild, we wrote our own SMP transport and we can do the updates, and we've seen that there is still ongoing DFU development for sysbuild in ncs2.7.0+ and we are wondering if there are any updates on this? 
Most of the samples we've seen cover the simultaneous and with external flash, but not the non-simultaneous without external flash, we could potentially do simultaneous, but the external flash is not something we can add at this point.

To clarify we want this to be able to go from our DTM/Manufacturing image to the Customer/production image (both with different App/Net Core images) using our SMP Transport.


Moreover, we can do sysbuild updates for AppCore, but for our custom DTM/Manufacturing we can't get it to enable NetCore updates, once we enable SB_CONFIG_NETCORE_APP_UPDATE we get:

with this configuration
0020.sysbuild.conf

And this Kconfig.sysbuild (had to add txt so I was able to upload it here):

Fullscreen Kconfig.sysbuild.txt Download

menu "Network core configuration"
    depends on SUPPORT_NETCORE

config SUPPORT_NETCORE_DIRECT_TEST_MODE
    bool
    default y

choice NETCORE
    prompt "Netcore image"
    depends on SUPPORT_NETCORE && !EXTERNAL_CONFIGURED_NETCORE

config NETCORE_DIRECT_TEST_MODE
    bool "direct test mode"
    help
      Use manufacturing dtm image as the network core image.

endchoice

# if !NETCORE_NONE

config NETCORE_IMAGE_NAME
    default "direct_test_mode" if NETCORE_DIRECT_TEST_MODE

config NETCORE_IMAGE_PATH
    default "../../../" if NETCORE_DIRECT_TEST_MODE

# endif # !NETCORE_NONE

endmenu

source "${ZEPHYR_BASE}/share/sysbuild/Kconfig"

Any advise, ideas would be appreciated!

[AHaug]

AlejandroM said:

But yeah looking it more closely I do not see the `mcuboot_primary_1` nor `mcuboot_secondary_1` there, I guess I can try to remove those and see If I can still do the non-simultaneous update.

I have an ongoing discussion with the developers and the author of the academy course. I know he's currently working on updating the course as we speak (ETA February), so he'll be deep into investigating this.  Sigurd created this sample before the official DFU course on the academy pages were made, which the academy course for 5340 was based on: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340

I have also looked around and found this case that Vidar mentions w.r.t nonsimultaneous DFU (albeit with an external flash), where the customer was successfull in performing the DFU when uploading the respective .bin file for the two cores with the proper image numbering such that the bootloader were able to load the image into the proper slot. Might be a useful case to read through for you as well Update custom net core image on nrf5340 with NCS v2.7.0 using external SPI flash 

This case (also with an external flash) states that they succesfully performed non-simultaneous DFU on the 5340 in both 2.6.1 and 2.7.0 (with sysbuild): 
https://devzone.nordicsemi.com/f/nordic-q-a/113100/nrf5340-mcuboot-issue-with-multi-image-update-when-sb_config_secure_boot_appcore-is-enabled 

When testing the smp server sample in 2.9.0  I got the following partitioning out of the box with this build command  'west build -b board_target -- -DEXTRA_CONF_FILE=overlay-bt.conf -DSB_CONFIG_NETCORE_HCI_IPC=y --sysbuild'

  flash_primary (0x100000 - 1024kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x74000 - 464kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x73e00 - 463kB)-+
| 0xc200: app (0x73e00 - 463kB)                   |
+-------------------------------------------------+
| 0x80000: mcuboot_secondary (0x74000 - 464kB)    |
| 0xf4000: EMPTY_1 (0x4000 - 16kB)                |
| 0xf8000: littlefs_storage (0x6000 - 24kB)       |
| 0xfe000: EMPTY_0 (0x2000 - 8kB)                 |
+-------------------------------------------------+

  otp (0x2fc - 764B):
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

  sram_primary (0x80000 - 512kB):
+-----------------------------------------------+
| 0x20000000: sram_primary (0x70000 - 448kB)    |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

 CPUNET flash_primary (0x40000 - 256kB):
+--------------------------------------+
+---0x1000000: app (0x40000 - 256kB)---+
| 0x1000000: hci_ipc (0x40000 - 256kB) |
+--------------------------------------+

 CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

I've not verified if the sample works for non-simultaneous without external flash, but I'm fairly confident it does.

AlejandroM said:

That makes sense now, but since our application is still bigger than the ram space we have ( 300 KiB App + 230 KiB Net ), not sure we would be able to fit both for simultaneous, unless the compression feature can help with that ( SB_CONFIG_MCUBOOT_COMPRESSED_IMAGE_SUPPORT`), can it?

Image compression should give you the option to reduce the size of the secondary_application slot up to ~70% the size of slot 0, but the gain may vary depending on the sample. It could be worth a shot to evaluate the option.

AlejandroM said:

We wanted originally to have serial recovery available, but we have not tested it outside the old samples ( 2.6.x ), could we potentially have serial recovery and non-simultaneous updates with this double partitioning layout (primary and primary_1 )?

With serial recovery you can do anything given that you're feeding MCUboot the correct, and working, application and netcore image. If the application does not work, it will go back into serial recovery. In this case you don't need to do both cores simultaneous, but you need to validate that the app_core image are compatible with the net_core image, i.e to make sure that you don't break the interface between them before the update.

Let me know if you're able to perform a non-simultaneous update with the smp server sample and the steps suggested in the two cases I mentioned and I'll follow up this case throughout the coming week

Kind regards,
Andreas