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

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

AHaug — Sun, 02 Feb 2025 13:01:24 GMT

[quote user="AlejandroM"]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.[/quote]

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.

[quote user="AlejandroM"]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?[/quote]

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.

[quote user="AlejandroM"]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 )?[/quote]

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

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

AlejandroM — Fri, 31 Jan 2025 22:01:15 GMT

Hi AHaug !

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/520894"]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.[/quote]

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.

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/520894"]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. [/quote]

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?

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/520894"]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? [/quote]

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,

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

AHaug — Fri, 31 Jan 2025 13:51:57 GMT

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.

[quote user="AlejandroM"]d we are not considering FOTA updates, as the ble module is part of another system (not standalone)[/quote]

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

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

AlejandroM — Wed, 29 Jan 2025 21:24:21 GMT

Hello AHaug

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

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

AHaug — Tue, 21 Jan 2025 09:25:14 GMT

[quote user="AlejandroM"]
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!
[/quote]

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

[quote user="AlejandroM"]Ahh yes I noticed that even the default one is now using "ec" instead of "rsa" , is that correct ?[/quote]

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.

[quote user="AlejandroM"]Great to know! Thanks a lot again Andreas![/quote]

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

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

AlejandroM — Mon, 20 Jan 2025 17:32:06 GMT

Hi Andreas ( AHaug ):

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518688"]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.[/quote]

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!

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518688"]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.[/quote]

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

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518688"]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.[/quote]

Great to know! Thanks a lot again Andreas!

Cheers,

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

AHaug — Thu, 16 Jan 2025 15:34:46 GMT

Aha, thank you for verifying.

[quote user="AlejandroM"]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.[/quote]

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

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

AlejandroM — Wed, 15 Jan 2025 19:21:29 GMT

Hi Andreas ( AHaug )

Here are some more tidbits

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518464"]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:[/quote]

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

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518464"]
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?[/quote]

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.

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518464"]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.[/quote]

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

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518464"]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.[/quote]

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,

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

AHaug — Wed, 15 Jan 2025 14:18:30 GMT

Hi,

[quote user="AlejandroM"]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. [/quote]

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?

[quote user="AlejandroM"]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.[/quote]

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

[quote user="AlejandroM"]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,[/quote]

Ah, I see.

[quote user="AlejandroM"]Perhaps we should move to 2.8.0 and skip 2.7.0 ? [/quote]

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

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

AlejandroM — Tue, 14 Jan 2025 19:57:49 GMT

Hi Andreas ( AHaug ),

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

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518190"]Out of curiosity, how large is your application?[/quote]

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:

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518190"]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. [/quote]

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:

devzone.nordicsemi.com/.../1050.mcuboot.conf

As for:

[quote userid="107683" url="~/f/nordic-q-a/117954/nrf5340-custom-board-non-simultaneous-updates-without-external-flash-with-sysbuild-on-ncs2-7-0/518190"]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.[/quote]

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. 🙂

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

AHaug — Mon, 13 Jan 2025 15:05:39 GMT

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?

[quote user=""]Using sysbuild (because we were advised to move to 2.8.0 and sysbuild is now a must)[/quote]

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:

[quote user=""]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? [/quote]

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