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

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):

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!

Parents
  • Hi,

    Your configuration sounds to be right out of the book and will work, with one caveat and that is the risk of breaking the interface between the app and netcore when migrating from 2.6.0 to 2.8.0.

    As explained in the Non-simultaneous part of https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/, the interface may break if it changes between an update making non-simultaneous not recommended for FOTA, which uses the radio. Since you update the network core first, you may end up in a state where the application can't use the network core and thus not being able to receive the new application you want to send over FOTA. If you however are doing DFU not over the air, then you should not have to worry about this.

    Just fyi, for simultaneous DFU you need a quite small application to make this work without an external flash. As illustrated here https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-8-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/ you need to have a secondary partition for both the application slot and the network slot, meaning that what you have remaining for your primary application slot will be very small.

    Out of curiosity, how large is your application?

    Using sysbuild (because we were advised to move to 2.8.0 and sysbuild is now a must)

    This is true, here's a couple of guides you've probably seen but they're nice to know of in case you're not aware of them:

    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? 

    Not quite sure how sysbuild relates to DFU in this case, could you expand a bit on this statement so I might understand where you're coming from w.r.t this? DFU using MCUBoot is it's own thing when comparing it to sysbuild, but if you're talkign about sysbuild in general, then yes, sysbuild were a bit immature in NCS 2.7.0, and has matured more and more in 2.8.0 and 2.9.0. 

    If you're referring the DFU course on our academy pages and are referring to "DFU development" in terms of adding support for sysbuild within the DFU course it has to do with the fact that the author of the course needed more time to update the course.

    There's quite a few topics in this case, so lets start with these items and go form here.

    Kind regards,
    Andreas

  • Hi Andreas (  ),

    Thank you for the clarification on the simultaneous, non-simultaneous, to answer your question:

    Out of curiosity, how large is your application?

    Our initial manufacturing application is relatively small < 100 KB on both App and Netcore, but our user/production application is much bigger < 400KB on the Appcore ( we will be optimizing this and potentially removing a few KBs ) and 240 KB on the Netcore ( LE Audio, multi role, and multiple connections with soft-device controller in 2.6.X ), so for the transition to the user/production FW, it sounds like it won't work on Simultaneous, thus we were focusing on non-simultaneous.

    About:

    Not quite sure how sysbuild relates to DFU in this case, could you expand a bit on this statement so I might understand where you're coming from w.r.t this? DFU using MCUBoot is it's own thing when comparing it to sysbuild, but if you're talkign about sysbuild in general, then yes, sysbuild were a bit immature in NCS 2.7.0, and has matured more and more in 2.8.0 and 2.9.0. 

    Well because we tried that configuration and got this problem ( in SDK 2.7.0 ):

    [22/275] Building C object zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/CMakeFiles/subsys__mgmt__mcumgr__grp__img_mgmt.dir/src/zephyr_img_mgmt.c.obj
    FAILED: zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/CMakeFiles/subsys__mgmt__mcumgr__grp__img_mgmt.dir/src/zephyr_img_mgmt.c.obj 
    C:\ncs\toolchains\ce3b5ff664\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DKERNEL -DK_HEAP_MEM_POOL_SIZE=4096 -DNCS_APPLICATION_BOOT_BANNER_GIT_REPO -DNRF5340_XXAA_APPLICATION -DNRF_SKIP_FICR_NS_COPY_TO_RAM -DPICOLIBC_LONG_LONG_PRINTF_SCANF -DUSE_PARTITION_MANAGER=1 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR__=1 -IC:/ncs/v2.7.0/zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/include -IC:/ncs/v2.7.0/zephyr/include -IC:/Users/alejandromata/Dev/iotplatform.nordic.manufacturing/application/build_1/application/zephyr/include/generated -IC:/ncs/v2.7.0/zephyr/soc/nordic -IC:/ncs/v2.7.0/zephyr/soc/nordic/nrf53/. -IC:/ncs/v2.7.0/zephyr/soc/nordic/common/. -IC:/ncs/v2.7.0/zephyr/subsys/mgmt/mcumgr/util/include -IC:/ncs/v2.7.0/zephyr/subsys/mgmt/mcumgr/transport/include -IC:/ncs/v2.7.0/bootloader/mcuboot/boot/bootutil/include -IC:/ncs/v2.7.0/bootloader/mcuboot/boot/zephyr/include -IC:/ncs/v2.7.0/zephyr/subsys/rtio -IC:/ncs/v2.7.0/zephyr/subsys/settings/include -IC:/ncs/v2.7.0/nrf/include -IC:/ncs/v2.7.0/nrf/tests/include -IC:/ncs/v2.7.0/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/v2.7.0/zephyr/modules/cmsis/. -IC:/ncs/v2.7.0/modules/hal/nordic/nrfx -IC:/ncs/v2.7.0/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/v2.7.0/modules/hal/nordic/nrfx/mdk -IC:/ncs/v2.7.0/zephyr/modules/hal_nordic/nrfx/. -IC:/Users/alejandromata/Dev/iotplatform.nordic.manufacturing/application/build_1/application/modules/libmetal/libmetal/lib/include -IC:/ncs/v2.7.0/modules/lib/open-amp/open-amp/lib/include -IC:/ncs/v2.7.0/modules/debug/segger/SEGGER -IC:/ncs/v2.7.0/modules/debug/segger/Config -IC:/ncs/v2.7.0/modules/lib/zcbor/include -IC:/ncs/v2.7.0/bootloader/mcuboot/boot/bootutil/zephyr/.. -IC:/ncs/v2.7.0/bootloader/mcuboot/boot/bootutil/zephyr/../include -IC:/ncs/v2.7.0/bootloader/mcuboot/boot/bootutil/zephyr/../../zephyr/include -isystem C:/ncs/v2.7.0/zephyr/lib/libc/common/include -isystem C:/ncs/v2.7.0/nrfxlib/crypto/nrf_cc312_platform/include -Wshadow -fno-strict-aliasing -Os -imacros C:/Users/alejandromata/Dev/iotplatform.nordic.manufacturing/application/build_1/application/zephyr/include/generated/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/ncs/toolchains/ce3b5ff664/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/v2.7.0/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=C:/Users/alejandromata/Dev/iotplatform.nordic.manufacturing/application=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/v2.7.0/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs/v2.7.0=WEST_TOPDIR -ffunction-sections -fdata-sections --specs=picolibc.specs -std=c99 -MD -MT zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/CMakeFiles/subsys__mgmt__mcumgr__grp__img_mgmt.dir/src/zephyr_img_mgmt.c.obj -MF zephyr\subsys\mgmt\mcumgr\grp\img_mgmt\CMakeFiles\subsys__mgmt__mcumgr__grp__img_mgmt.dir\src\zephyr_img_mgmt.c.obj.d -o zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/CMakeFiles/subsys__mgmt__mcumgr__grp__img_mgmt.dir/src/zephyr_img_mgmt.c.obj -c C:/ncs/v2.7.0/zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/src/zephyr_img_mgmt.c
    In file included from C:/ncs/v2.7.0/zephyr/include/zephyr/toolchain.h:50,
                     from C:/ncs/v2.7.0/zephyr/include/zephyr/kernel_includes.h:23,
                     from C:/ncs/v2.7.0/zephyr/include/zephyr/kernel.h:17,
                     from C:/ncs/v2.7.0/zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/src/zephyr_img_mgmt.c:7:
    C:/ncs/v2.7.0/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: "Missing partitions?"
       87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
          |                                    ^~~~~~~~~~~~~~
    C:/ncs/v2.7.0/zephyr/subsys/mgmt/mcumgr/grp/img_mgmt/src/zephyr_img_mgmt.c:43:1: note: in expansion of macro 'BUILD_ASSERT'
       43 | BUILD_ASSERT(FIXED_PARTITION_EXISTS(SLOT2_PARTITION) &&
          | ^~~~~~~~~~~~

    Main error:
    "C:/ncs/v2.7.0/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: "Missing partitions?"

    Note that I probably should have stressed that we are using MCUMgr and MCUBoot (our own SMP Transport), and we are not considering FOTA updates, as the ble module is part of another system (not standalone), and we want the firmware to be handled from outside the module, and all works well for the User/produciton FW updates in 2.6.X to upgrade to further versions of production firmware, but the first upgrade ( manufacturing to production - manufacturing constraint) is what we are migrating first to sysbuild, and having problems with. (Perhaps we should move to 2.8.0 and skip 2.7.0 ? , please advise

    For this problem I think I forgot to add the mcuboot.conf, here it is:

    1050.mcuboot.conf

    As for:

    If you're referring the DFU course on our academy pages and are referring to "DFU development" in terms of adding support for sysbuild within the DFU course it has to do with the fact that the author of the course needed more time to update the course.

    Yes, we were seeing that in the courses:


    And things like this in the code:



    To summarize:

    We want to have those non-simultaneous FW updates with MCUmgr/MCUBoot in SDK 2.7.0 with sysbuild, and we are trying to transition first the manufacturing to production firmware update first update to this setup.

    Hope that makes more sense. Slight smile

  • Hi,

    AlejandroM said:
    We want to have those non-simultaneous FW updates with MCUmgr/MCUBoot in SDK 2.7.0 with sysbuild, and we are trying to transition first the manufacturing to production firmware update first update to this setup.

    Hope that makes more sense. 

    It does, thank you very much, with the exception of this sentence "and we are trying to transition first the manufacturing to production firmware update first update to this setup.", but I guess it relates to "To clarify we want this to be able to go from our DTM/Manufacturing image to the Customer/production image".  Correct me if I've misunderstood this:

    You have your firmware in 2.6 that you currently call DTM/Manufacturing (state), that you want to perform DFU to get to the customer/production (state) in 2.7.0?

    AlejandroM said:
    Our initial manufacturing application is relatively small < 100 KB on both App and Netcore, but our user/production application is much bigger < 400KB on the Appcore ( we will be optimizing this and potentially removing a few KBs ) and 240 KB on the Netcore ( LE Audio, multi role, and multiple connections with soft-device controller in 2.6.X ), so for the transition to the user/production FW, it sounds like it won't work on Simultaneous, thus we were focusing on non-simultaneous.

    I agree, then the available flash on the app core will be too small to fit simultaneous. Thank you for elaborating

    AlejandroM said:
    Note that I probably should have stressed that we are using MCUMgr and MCUBoot (our own SMP Transport), and we are not considering FOTA updates,

    Ah, I see. 

    AlejandroM said:
    Perhaps we should move to 2.8.0 and skip 2.7.0 ?

    I would say that you should get it working in 2.7.0 before going to 2.8.0 and the migration to sysbuild guide should be the same for both versions, but there might be other changes in 2.8.0 that you need to account for in your firmware that you might miss if you skip one release. But of course, if you're confident enough, you can go directly from 2.6 to 2.9 as well by following the migration guides, release notes and changes in the relevant modules in the SDK.

    How have you done your partitioning in the previous firmware? I assume it is through a pm_static.yml? Have you done any partitioning in dts? It not, then that might be the reason as both are required for sysbuild (although it only uses one of them). The error you post seems to indicate that it is a partitioning issue.

    Kind regards, 
    Andreas

  • Hi Andreas (  )

    Here are some more tidbits

    It does, thank you very much, with the exception of this sentence "and we are trying to transition first the manufacturing to production firmware update first update to this setup.", but I guess it relates to "To clarify we want this to be able to go from our DTM/Manufacturing image to the Customer/production image".  Correct me if I've misunderstood this:

    Yes, that is correct, we want this to work with "sysbuild".


    You have your firmware in 2.6 that you currently call DTM/Manufacturing (state), that you want to perform DFU to get to the customer/production (state) in 2.7.0?

    ahh not quite ( sorry for the confusion ), we have a 2.6 user/production firmware with this non-simultaneous Fw updates and we now have a manufacturing FW on 2.7.0 with sysbuild, but no FW updates. So we want the FW updates on that manufacturing FW, and later we will move the user/prod FW to 2.8.0.

    I would say that you should get it working in 2.7.0 before going to 2.8.0 and the migration to sysbuild guide should be the same for both versions, but there might be other changes in 2.8.0 that you need to account for in your firmware that you might miss if you skip one release. But of course, if you're confident enough, you can go directly from 2.6 to 2.9 as well by following the migration guides, release notes and changes in the relevant modules in the SDK.

    Yes, so we better get it on 2.7.0 before going to 2.8.0.

    How have you done your partitioning in the previous firmware? I assume it is through a pm_static.yml? Have you done any partitioning in dts? It not, then that might be the reason as both are required for sysbuild (although it only uses one of them). The error you post seems to indicate that it is a partitioning issue.

    In the user/prod Fw in 2.6.0 we did not created a static partitioning, and it was working fine, I gather that we now need to create one ( pm_static.yml ), I'll do that and come back, thanks.

    Cheers,

  • Aha, thank you for verifying.

    AlejandroM said:
    In the user/prod Fw in 2.6.0 we did not created a static partitioning, and it was working fine, I gather that we now need to create one ( pm_static.yml ), I'll do that and come back, thanks.

    Aha, yes please do that. The short reason for why you would want static partitioning is so you can migrate to newer versions further up with the same partitioning map. Dynamic partitioning may change between versions, meaning that you may get issues with addresses due to for instance changes in how large a partition is between the two different versions.

    You must also make sure that you sign your new application with keys which that your old bootloader recognizes so that the new image will be approved.

    In short, migrating through an update is quite more complex than simply migrating, but it is possible as long as you have enough headspace on the previous memory map (given that you will add features), and/or have static partitioning as well as you're using the same keys.

    Kind regards,
    Andreas

  • Hi Andreas (  ):

    Aha, yes please do that. The short reason for why you would want static partitioning is so you can migrate to newer versions further up with the same partitioning map. Dynamic partitioning may change between versions, meaning that you may get issues with addresses due to for instance changes in how large a partition is between the two different versions.


    This is great tip, didn't know that! (dynamic vs static partitioning). I ended up going static, and that worked out! :D I appreciate the help!

    You must also make sure that you sign your new application with keys which that your old bootloader recognizes so that the new image will be approved.


    Ahh yes I noticed that even the default one is now using "ec" instead of "rsa" , is that correct ?

    In short, migrating through an update is quite more complex than simply migrating, but it is possible as long as you have enough headspace on the previous memory map (given that you will add features), and/or have static partitioning as well as you're using the same keys.

    Great to know! Thanks a lot again Andreas!

    Cheers,

  • AlejandroM said:

    This is great tip, didn't know that! (dynamic vs static partitioning). I ended up going static, and that worked out! :D I appreciate the help!

    Great! Glad to hear that!

    Another FYI that you might not be aware of: If you need to change the static partitioning map later, you will need to update MCUboot i.e add a complete bootloader chain. This is also something that you can't do retroactively due to the device is already running an older version of MCUboot that only knows about it's old partitioning map, and retroactivly adding a bootloader chain with NSIB will both demand a change in start address for MCUboot and for your application. MCUboot will now become a second stage updatable bootloader and NSIB will become the first stage bootloader

    AlejandroM said:
    Ahh yes I noticed that even the default one is now using "ec" instead of "rsa" , is that correct ?

    That might be the case. I'm not 100% sure if the default key that we use in NCS (which we of course want users to change to their own custom keys in their products) has changed between the releases, but it might be the case.

    AlejandroM said:
    Great to know! Thanks a lot again Andreas!

    Happy to help! 

    Let me know when you feel we've resolved the topic of this case and we'll mark it of as verified answer! :) Until then we'll keep the case open if you have any follow ups related to this topic

    Kind regards,
    Andreas

Reply
  • AlejandroM said:

    This is great tip, didn't know that! (dynamic vs static partitioning). I ended up going static, and that worked out! :D I appreciate the help!

    Great! Glad to hear that!

    Another FYI that you might not be aware of: If you need to change the static partitioning map later, you will need to update MCUboot i.e add a complete bootloader chain. This is also something that you can't do retroactively due to the device is already running an older version of MCUboot that only knows about it's old partitioning map, and retroactivly adding a bootloader chain with NSIB will both demand a change in start address for MCUboot and for your application. MCUboot will now become a second stage updatable bootloader and NSIB will become the first stage bootloader

    AlejandroM said:
    Ahh yes I noticed that even the default one is now using "ec" instead of "rsa" , is that correct ?

    That might be the case. I'm not 100% sure if the default key that we use in NCS (which we of course want users to change to their own custom keys in their products) has changed between the releases, but it might be the case.

    AlejandroM said:
    Great to know! Thanks a lot again Andreas!

    Happy to help! 

    Let me know when you feel we've resolved the topic of this case and we'll mark it of as verified answer! :) Until then we'll keep the case open if you have any follow ups related to this topic

    Kind regards,
    Andreas

Children
  • Hello  

    Update:
    After migrating to 2.7 I was able to get it all working fine by defining a `pm_static.yml` partition layout file with only `mcuboot_primary`, `mcuboot_secondary` and `mcuboot_primary_1` ( no `mcuboot_secondary_1`). However, on 2.9 the existence of `mcuboot_secondary_1` seems mandatory and that makes mcumgr think that it needs to be there for many simple commands:


    And well minding the new slot configuration, for the most part works, uploading to the old slot ( slot 3 ) makes the system crash:



    Question is:

    Is there a way to define `mcuboot_secondary_1` partition so that we don't get this ?

    reminder: We don't have external flash in our system as most of the samples use that partition

  • Hi again,

    Hmm, yes it does indeed look like this is a mandatory partition to temporary store the netcore update image within. I'm not sure how this translates to non-simultaneous DFU though, but for simultaneous DFU it is atleast required. It seems to be the case that it is required for both types as mcuboot_secondary_1 is used to temporarily store the netcore image for image revertion in the solution we provide.

    I think the best option here is for you to customize the bootloader so that you get a solution where you can upload the netcore update image to mcuboot_secondary application slot, and then transport it to netcore when it detects that it is doing a netcore update.

    Non-simultaneous DFU of the 5340 is technically possible, but we favour the simultaneous DFU procedure both due to robustness and that the solution is simpler. 

    AlejandroM said:
    d we are not considering FOTA updates, as the ble module is part of another system (not standalone)

    Another item of discussion is this. If you're not considering FOTA updates, then you might not need any secondary partitions at all. Are the requirements such that you need image reversion, or is serial recovery an option instead? 

    Kind regards,
    Andras

  • Hi  !

    I think the best option here is for you to customize the bootloader so that you get a solution where you can upload the netcore update image to mcuboot_secondary application slot, and then transport it to netcore when it detects that it is doing a netcore update.

    You mean customize the code for mcuboot ( and/or potentially b0n ) ?
    I was basing myself on this scenario from the courses:


    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.


    Non-simultaneous DFU of the 5340 is technically possible, but we favour the simultaneous DFU procedure both due to robustness and that the solution is simpler. 

    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?


    Another item of discussion is this. If you're not considering FOTA updates, then you might not need any secondary partitions at all. Are the requirements such that you need image reversion, or is serial recovery an option instead? 

    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 )?

    Thanks,

  • 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

Related