Issue with MCUboot integration in Zigbee R23 project for nRF54L15

[MAndris]

Dear Nordic Technical Support,

I'm writing to report an issue I'm experiencing when trying to integrate MCUboot with a Zigbee R23 project for the nRF54L15 platform.

Issue Description: When attempting to build a basic Zigbee R23 project with MCUboot support (without any FOTA functionality yet), the build process fails during the MCUboot compilation phase. The main application builds successfully, but the bootloader build fails with the following error:

C:/ncs/ZB_for290_R23_031/ncs-zigbee/subsys/osif/zb_nrf_pwr_mgmt.c:9:10: fatal error: zboss_api.h: No such file or directory
9 | #include <zboss_api.h>
| ^~~~~~~~~~~~~
compilation terminated.

Environment:

• Hardware: nRF54L15 Development Kit
• SDK: nRF Connect SDK with Zigbee R23 add-on (ZB_for290_R23_031)
• Build system: West/CMake

Steps Taken:

1. Created a basic Zigbee R23 project that builds successfully without bootloader
2. Added MCUboot configuration through sysbuild.conf with SB_CONFIG_BOOTLOADER_MCUBOOT=y
3. Created configuration files in the sysbuild directory to disable components that shouldn't be needed for the bootloader:

   • Added mcuboot.conf with CONFIG_SERIAL=n, CONFIG_SPI=n, CONFIG_SPI_NOR=n, etc.
   • Attempted to disable Zigbee components in the bootloader with CONFIG_ZIGBEE=n, CONFIG_ZIGBEE_ADD_ON=n

Despite these configurations, the build system still attempts to include Zigbee libraries in the bootloader build, which causes the compilation error.

Goal: My ultimate goal is to implement FOTA updates in my Zigbee R23 application, but I'm currently blocked at this initial stage of just integrating the bootloader.

I would appreciate any guidance on how to properly configure the build system to exclude Zigbee components from the MCUboot build, or any other approach to resolve this issue.

Thank you for your assistance.

Best regards, Andris M.

[Amanda Hsieh]

Hi, 

Update the information from the team:

FOTA is a mandatory feature but at least for now not supported. We have it on our roadmap in Q2'2025. 

Regards,
Amanda H.

[MAndris]

Hello Amanda,

I'm still very interested in implementing Zigbee FOTA and hope your roadmap is progressing without delays.
I have completed the DFU and FOTA modules in the DevAcademy, and today I tried to implement Zigbee FOTA using SDK 0.4.0 of the Zigbee r23 library.

---

 Progress so far

I managed to:

• Integrate MCUboot using the modern sysbuild.conf approach

• Launch the Zigbee sample firmware using the bootloader

• Configure SB_CONFIG_BOOTLOADER_MCUBOOT=y

• Maintain separated configurations for mcuboot and the main app

---

 Problem when enabling Zigbee FOTA

When I enable:

CONFIG_ZIGBEE_FOTA=y

Only the bootloader builds successfully. The Zigbee firmware fails to build due to a missing Kconfig symbol:

error: ‘CONFIG_UPDATEABLE_IMAGE_NUMBER’ undeclared

---

️ My workaround attempt

I added the following to my custom Kconfig to unblock the build:

config UPDATEABLE_IMAGE_NUMBER
    int "Number of updateable images"
    default 2
    help
        This sets the number of updateable images for Zigbee FOTA.

And added to prj.conf:

CONFIG_UPDATEABLE_IMAGE_NUMBER=1

This allowed the build to proceed further, but then linker errors appeared:

undefined reference to `boot_is_img_confirmed'
undefined reference to `boot_write_img_confirmed'
undefined reference to `boot_read_bank_header'
undefined reference to `dfu_target_mcuboot_set_buf'

 Question

At this point, I assume full Zigbee FOTA support is still not functional, as mentioned earlier (planned for Q2 2025).
Could you confirm if this is still the case and if an official FOTA-compatible integration is expected soon?

Thank you in advance!

Best regards,
Andris M.

[Amanda Hsieh]

Hi, 

We are progressing with FOTA support for Moonlight (54L15). The target is to release it in the coming weeks (probably at the end of June 2026), but no promise. 

Regards,
Amanda H.

[Reinis]

Hi Amanda Hsieh 

This is MAndris colleague.

We are currently in process of ordering first production batch (Q 2000) of devices based on nRF54L15.
Zigbee stuff for home and commercial building automation, will be used in our objects https://www.piche.eu/en, if everything runs smoothly then next batches incoming.

It was planned to happen already ~ month ago, but the process was delayed - contracted manufacturer had to wait on burner for the MCU, stakeholders had second thoughts on functionality, a.o. usual suspects.

Anyways, we can still stretch deadlines a bit if we knew that we could have OTA for the first batch. Any potential mistake or tuning would not be that painful.

Is there some exact date that we can count on? And not shy to ask – mby it can be sped up?

Thanks in advance!

Regards,
Reinis

[Amanda Hsieh]

Please contact your regional sales manager or use the form of Sales related questions for the feature/roadmap/plan/schedule. 

[Amanda Hsieh]

Hi Reinis, 

FOTA support for L15/L10 is available on main branch (still no officially released), tested, and it’s working.

You can download the main branch and continue work with it temporarily. 

Temporary documentation is available here: Zigbee R23 add-on_documentation_html.zip

-Amanda H.

[MAndris]

Good day Amanda,

Thanks a lot for the update and for confirming that Zigbee FOTA support is now available in the main branch for nRF54L15.

I successfully integrated MCUboot using the sysbuild.conf method and generated a signed image with the following configuration:

SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
SB_CONFIG_BOOT_SIGNATURE_KEY_FILE="${APPLICATION_CONFIG_DIR}/priv.pem"

I also added FOTA-specific options:

CONFIG_ZIGBEE_FOTA=y
CONFIG_ZIGBEE_FOTA_HW_VERSION=52
CONFIG_ZIGBEE_FOTA_ENDPOINT=5
CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="1.2.3"
CONFIG_ZIGBEE_FOTA_COMMENT="light_switch"
CONFIG_IMG_MANAGER=y
CONFIG_STREAM_FLASH=y
CONFIG_DFU_TARGET_MCUBOOT=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y
CONFIG_ZIGBEE_FOTA_PROGRESS_EVT=y

The application was built and signed successfully, and I copied the resulting partition map into pm_static.yaml.

The firmware runs fine, and I can see the OTA cluster exposed on endpoint 5. Using deCONZ, I’m able to read OTA attributes, and when I trigger an OTA update, the device receives the image header correctly.

To simulate a real update, I tried sending the same signed binary currently running on the device (so image size, version, and headers are correct) using the following nrfutil command:

nrfutil nrf5sdk-tools pkg generate \
  --hw-version 52 \
  --sd-req 0x00 \
  --application-version 0x01020040 \
  --application zephyr.signed.bin \
  --key-file ../../../priv.pem \
  app_dfu_package.zip \
  --zigbee True \
  --zigbee-manufacturer-id 0x127f \
  --zigbee-image-type 0x0141 \
  --zigbee-comment good_image \
  --zigbee-ota-hw-version 52

This created a .zigbee file: 127F-0141-01020040-good_image.zigbee
However, the actual OTA update fails at the very beginning. Only 0.3% of the image is transferred before the process aborts. Logs from the device show the following:

[00:14:23.794,935] <err> zigbee_fota: dfu_multi_image_write err -12 offset: 0 len: 15
[00:14:23.794,981] <inf> zigbee_fota: Zigbee DFU Aborted
[00:14:23.794,986] <inf> zigbee_fota: ABORT Zigbee DFU
[00:14:23.794,997] <err> app: OTA image transfer failed.

 Questions / Request for Help

1. What exactly does dfu_multi_image_write err -12 mean?
   I assume -12 is -ENOMEM, but the memory pool should be large enough.

2. Could this error be related to how the .zigbee file is generated via nrfutil?
   Is there any official method to generate OTA packages (especially for multi-image DFU)?

I’d appreciate any guidance or even just hints where to look next — especially to avoid wasting time debugging the wrong layer (OTA file, integration, or memory limits). Thank you!

Best regards,
Andris Matveev