[Zigbee] FOTA mcuboot update

RE: [Zigbee] FOTA mcuboot update

Pawel(embeddedsolutions.pl) — Sat, 29 Mar 2025 07:33:35 GMT

Hello,

I was going through my tickets and changing tickets titles to be in compliance with other ones.
Didn't mean to bother you.

Anyway, regarding this ticket I think it deserves an update as a lot changed in between v2.3.0 and v2.9.1.
So for anyone interested in that topic, after migration to sysbuild it is still possible to support MCUboot FOTA via Zigbee by modifying the build and having a little bit of logic implemented to handle multiple images types.

Regards,

Pawel

RE: [Zigbee] FOTA mcuboot update

Maria Gilje — Thu, 27 Mar 2025 13:35:34 GMT

Hello,

I noticed that this case returned to my work queue today.

Do you have any current need for support?

Best regards,

Maria

RE: Zigbee FOTA mcuboot update

Pawel(embeddedsolutions.pl) — Thu, 14 Dec 2023 08:16:06 GMT

Hello once again,

I solved that problem.

As far as I noticed that timers are not the best option here, I have registered the endpoint handler and based on Query Next Image Response I change the ZB_ZCL_ATTR_OTA_UPGRADE_FILE_VERSION_ID and ZB_ZCL_ATTR_OTA_UPGRADE_IMAGE_TYPE_ID.
The rest is to handle properly the sequence restarting depending on different events in the app, but this is totally application depended which is not the goal of this topic

RE: Zigbee FOTA mcuboot update

Pawel(embeddedsolutions.pl) — Thu, 05 Oct 2023 12:19:58 GMT

Hi,
I will be more than happy to share the source code.
I wrongly thought that it is working correctly. Unfortunately it is not.

The goal is to change the FileVersion and ImageType attributes in the middle of the query interval then the the updated values for the attributes will be relevant from the next time the client queries the server.

I would like also to achieve following sequence:

Desired images sequence: Boot -> 1min -> QueryNextImageRequest (s0) -> ~1.5min -> keep s0 image -> ~3min -> QueryNextImageRequest(s0) -> ~4.5min -> switch to s1 image -> ~6min -> QueryNextImageRequest(s1) -> ~7.5min -> switch to app image -> ~9min -> QueryNextImageRequest(app) -> ~10.5min -> keep app image data, stop image switcher and set interval to 24h

This is the code which is trying to do such thing but what I have noticed is that the query interval does not change at all. QueryInterval is something about 1 minute.

/* CONFIG_ZIGBEE_FOTA_IMAGE_QUERY_INTERVAL_MIN set to 3 minutes */



/* Application is able to update s0, s1 (bootloader partitions) and app image. ZBOSS sends QueryNextImageRequest
 * each CONFIG_ZIGBEE_FOTA_IMAGE_QUERY_INTERVAL_MIN. In the middle of defined time ZBOSS changes the requested Image
 * Type and Image version */
static void zb_fota_start_image_switcher_timer(void) {
    k_timer_start(&image_type_switcher_timer, K_SECONDS(CONFIG_ZIGBEE_FOTA_IMAGE_QUERY_INTERVAL_MIN * 60 / 2),
                  K_MINUTES(CONFIG_ZIGBEE_FOTA_IMAGE_QUERY_INTERVAL_MIN));
    LOG_DBG("Image Type switcher timer started");
}

/* desired images sequence: Boot -> 1min -> QueryNextImageRequest (s0) -> 1.5min -> keep s0 -> 3min ->
 * QueryNextImageRequest(s0) -> 4.5min -> switch to s1 -> 6min QueryNextImageRequest(s1) -> 7.5min -> switch to app ->
 * 9min -> QueryNextImageRequest(app) -> 10.5min -> keep app data, stop image switcher, set interval to 24h */
/* Zigbee STACK sends first QueryNextImageRequest after 1min after boot and it is unchangeable */
static void zb_fota_change_requested_image_type(struct k_timer *switcher_timer) {
    ARG_UNUSED(switcher_timer);
    static zb_uint8_t idx = 0;

    if (restart_image_seq) {
        idx = 0;
        restart_image_seq = false;
    }

    zb_uint16_t image_types_list[] = {CONFIG_ZIGBEE_FOTA_S0_IMAGE_TYPE, CONFIG_ZIGBEE_FOTA_S1_IMAGE_TYPE,
                                      CONFIG_ZIGBEE_FOTA_IMAGE_TYPE};

    if (idx >= ARRAY_SIZE(image_types_list)) {
        /*  ImageType switcher reached 4th transition without detecting FOTA upgrades -> keep application image data and
         * change the interval to 24h */
        LOG_DBG("Set 24h interval for app image FOTA requests");
        k_timer_stop(&image_type_switcher_timer);
        zb_zcl_ota_upgrade_set_query_interval(CONFIG_ZB_DEVICE_ENDPOINT,
                                              CONFIG_ZIGBEE_FOTA_APP_IMAGE_QUERY_INTERVAL_TIME);
        return;
    }

    uint32_t img_ver = zb_fota_get_image_ver(image_types_list[idx]);
    ZB_ZCL_SET_ATTRIBUTE(CONFIG_ZIGBEE_FOTA_ENDPOINT, ZB_ZCL_CLUSTER_ID_OTA_UPGRADE, ZB_ZCL_CLUSTER_CLIENT_ROLE,
                         ZB_ZCL_ATTR_OTA_UPGRADE_FILE_VERSION_ID, (zb_uint8_t *)&img_ver, ZB_FALSE);

    ZB_ZCL_SET_ATTRIBUTE(CONFIG_ZIGBEE_FOTA_ENDPOINT, ZB_ZCL_CLUSTER_ID_OTA_UPGRADE, ZB_ZCL_CLUSTER_CLIENT_ROLE,
                         ZB_ZCL_ATTR_OTA_UPGRADE_IMAGE_TYPE_ID, (zb_uint8_t *)&image_types_list[idx], ZB_FALSE);

    LOG_INF("Image Type changed to=0x%03X", image_types_list[idx]);
    idx++;
}



/*
 Overwrite default Zigbee FOTA subsys attributes to send QueryNextImageRequest with s0 bootloader related
 attributes values rather than application image data */
static void zb_fota_overwrite_default_attr(void) {
    uint32_t img_ver = zb_fota_get_image_ver(CONFIG_ZIGBEE_FOTA_S0_IMAGE_TYPE);
    ZB_ZCL_SET_ATTRIBUTE(CONFIG_ZIGBEE_FOTA_ENDPOINT, ZB_ZCL_CLUSTER_ID_OTA_UPGRADE, ZB_ZCL_CLUSTER_CLIENT_ROLE,
                         ZB_ZCL_ATTR_OTA_UPGRADE_FILE_VERSION_ID, (zb_uint8_t *)&img_ver, ZB_FALSE);

    zb_uint16_t img_type = CONFIG_ZIGBEE_FOTA_S0_IMAGE_TYPE;
    ZB_ZCL_SET_ATTRIBUTE(CONFIG_ZIGBEE_FOTA_ENDPOINT, ZB_ZCL_CLUSTER_ID_OTA_UPGRADE, ZB_ZCL_CLUSTER_CLIENT_ROLE,
                         ZB_ZCL_ATTR_OTA_UPGRADE_IMAGE_TYPE_ID, (zb_uint8_t *)&img_type, ZB_FALSE);
}


void zb_fota_init(void) {
    zigbee_fota_abort();
    zb_fota_nsib_abort();
    int err = zigbee_fota_init(zb_fota_evt_handler);
    if (err) {
        LOG_ERR("err=%d zboss fota init", err);
        return;
    }

    /* Overwrite default OTA Upgrade ImageType, FileVersion attributes */
    zb_fota_overwrite_default_attr();

    err = zb_fota_nsib_register_cb(zb_fota_evt_handler);
    if (err) {
        LOG_ERR("err=%d zigbee nsib callback register", err);
        return;
    }

    err = zb_fota_confirm_image();
    if (err) {
        LOG_ERR("err=%d img confirm", err);
    }

    k_timer_init(&image_type_switcher_timer, zb_fota_change_requested_image_type, NULL);
    zb_fota_start_image_switcher_timer();
}

There is of course another part of the code responsible for restarting the sequence/stopping the timer based on various events detected in the zigbee_fota_zcl_cb but I do no think it is important in that case.

RE: Zigbee FOTA mcuboot update

Maria Gilje — Mon, 02 Oct 2023 13:03:20 GMT

Hello,

Thank you for the update.

From what I can see your implementation looks good.

I have one minor concern regarding 4.:

[quote user="pwpot"]I just have a timer which in the middle of CONFIG_ZIGBEE_FOTA_IMAGE_QUERY_INTERVAL_MIN changes two attributes in OTA Upgrade Cluster, which is ImageType and FileVersion.[/quote]

Can you please share how this is implemented? Or if you don't want to share more of your code, please describe more of the intended functionality.
Do I understand correctly that the updated values for the attributes will be relevant from the next time the client queries the server?

BR,

Maria

RE: Zigbee FOTA mcuboot update

Pawel(embeddedsolutions.pl) — Fri, 22 Sep 2023 08:52:15 GMT

Hi, I came back here just to share with you how I implemented the Zigbee FOTA bootloader update:
1. Create module for dfu update based on dfu_target_stream API. (init, target_done, offset_get, write, get_bootloader_versions) -> As a reference I took dfu_target_mcuboot module.
2. Basically copy the implementation of Zigbee FOTA subsys for app image and adapt it to created earlier dfu module.
3. Create Kconfigs for bootloader image types like: CONFIG_ZIGBEE_FOTA_S1_IMAGE,_TYPE CONFIG_ZIGBEE_FOTA_S0_IMAGE_TYPE
3. To generate fota images from the bootloaders .bin files, I added following code in the CMakeLists.txt

if (CONFIG_ZIGBEE_FOTA_GENERATE_LEGACY_IMAGE_TYPE)
		set(legacy_cmd "--legacy")
	elseif(CONFIG_DFU_MULTI_IMAGE_PACKAGE_BUILD)
		set(legacy_cmd )
	endif()

	set(add_zigbee_header_cmd
		${PYTHON_EXECUTABLE}
		${NRF_DIR}/scripts/bootloader/zb_add_ota_header.py
		#								Provide acceptable format x.y.z
		--application-version-string 	"0.0.${mcuboot_CONFIG_FW_INFO_FIRMWARE_VERSION}"
		--zigbee-manufacturer-id 		${CONFIG_ZIGBEE_FOTA_MANUFACTURER_ID}
		--zigbee-ota-min-hw-version 	${CONFIG_ZIGBEE_FOTA_MIN_HW_VERSION}
		--zigbee-ota-max-hw-version 	${CONFIG_ZIGBEE_FOTA_MAX_HW_VERSION}
		--out-directory 				${PROJECT_BINARY_DIR}/zephyr
		${legacy_cmd}
	)

	set(FOTA_HEADER_STEP_S0 "dummy_s0")
	add_custom_command(
		COMMAND ${add_zigbee_header_cmd} --application ${PROJECT_BINARY_DIR}/zephyr/signed_by_mcuboot_and_b0_s0_image_update.bin
		--zigbee-image-type ${CONFIG_ZIGBEE_FOTA_S0_IMAGE_TYPE}
		--zigbee-comment "${CONFIG_ZIGBEE_FOTA_BOOTLOADER_COMMENT}_s0"
		OUTPUT ${FOTA_HEADER_STEP_S0}
		DEPENDS zigbee_ota_image
		COMMENT "Add Zigbee FOTA header to s0 bootloader image..."
	)

	set(FOTA_HEADER_STEP_S1 "dummy_s1")
	add_custom_command(
		COMMAND ${add_zigbee_header_cmd} --application ${PROJECT_BINARY_DIR}/zephyr/signed_by_mcuboot_and_b0_s1_image_update.bin
		--zigbee-image-type ${CONFIG_ZIGBEE_FOTA_S1_IMAGE_TYPE}
		--zigbee-comment "${CONFIG_ZIGBEE_FOTA_BOOTLOADER_COMMENT}_s1"
		OUTPUT ${FOTA_HEADER_STEP_S1}
		DEPENDS ${FOTA_HEADER_STEP_S0}
		COMMENT "Add Zigbee FOTA header to s1 bootloader image..."
	)

	add_custom_target(
		post_bin ALL
		DEPENDS
		${FOTA_HEADER_STEP_S1}
	)

4. Multiple FOTA images handling on the Zigbee End device.
I just have a timer which in the middle of CONFIG_ZIGBEE_FOTA_IMAGE_QUERY_INTERVAL_MIN changes two attributes in OTA Upgrade Cluster, which is ImageType and FileVersion.
Handling of these images is really application depended. I did in such way but You can change the requested image type (QueryNextImageRequest) on specific events.

I would like to get your thoughts about that implementation and I will be very grateful if let me know if You notice any problems in provided solution.

RE: Zigbee FOTA mcuboot update

Maria Gilje — Mon, 10 Jul 2023 12:42:54 GMT

Due to the summer holiday period in Norway we currently have low staffing on DevZone. We apologize for possible delays caused by this and thank you for your patience.

Hello,

[quote user="pwpot"]I assume that if I will choose the DFU lib I will have to write the code which will be similar to dfu_target_mcuboot.c
is that right ? [/quote]

Yes, your DFU target is MCUboot, so the functions to use are in that file as well as in dfu_target.c. Please see the MCUBoot-style upgrades part of the DFU target library documentation for information on how to use the API functions.

[quote user="pwpot"]I compared both binaries and they have got a lot of differences. I noticed that every bin file contains the firmware info which also contains the start address of image, so when the signed_by_mcuboot_and_b0_s1_image_update.bin is used for updating the s0 partition, b0 (NSIB) tries to boot the s0 from PM_S1_ADDRESS which ends with error:
"Firmware info doesn't point to itself".[/quote][quote user="pwpot"]What I am trying to achieve is to have only one binary file which will be suitable for both partitions. Is it even possible ? If not, why ?[/quote]

From Pre-signed variants in the Secure bootloader chain documentation:

You must build with pre-signed variants when building upgrade images for the image that follows the nRF Secure Immutable Bootloader in the boot chain, such as the upgradable bootloader or the application. Firmware update packages of the upgradable bootloader must contain images for both slots, since it may not be known which slot is in use by its current version while deployed in the field.

From the documentation excerpt above it looks like it will not be possible to have one binary to fit both slots.

Edit: I want to add that the reason for the different images is that the code is memory-dependent. The difference in images is necessary for the firmware to run properly.

Best regards,

Maria

RE: Zigbee FOTA mcuboot update

Pawel(embeddedsolutions.pl) — Tue, 04 Jul 2023 11:17:46 GMT

Hi, in the past few days, I have implemented the source code for handling the mcuboot image update over Zigbee.
Since today I am able to send the image through Zigbee FOTA server, parse the image on the client side, save it to flash and correctly boot with the new version.
Implementation has got some limitations which I am going to overcome in the next steps.
I am using CONFIG_FW_INFO (fw_info_find) to read the content of both s0,s1 partitions metadata like firmware version. On the application side when the Zigbee Image Response arrives I check the greatest firmware version stored in any of the partitions to avoid downgrading.
If that requirement is met I decide which partition should be updated. In other words I look for slot which has got the lowest firmware version.
Then the update starts and data is being saved to flash starting from  PM_S0_ADDRESS or PM_S1_ADDRESS.

Everything works well if  signed_by_mcuboot_and_b0_s0_image_update.bin is used for updating s0 partition, and signed_by_mcuboot_and_b0_s1_image_update.bin for s1 partition.

I compared both binaries and they have got a lot of differences. I noticed that every bin file contains the firmware info which also contains the start address of image, so when the signed_by_mcuboot_and_b0_s1_image_update.bin is used for updating the s0 partition, b0 (NSIB) tries to boot the s0 from  PM_S1_ADDRESS which ends with error:
"Firmware info doesn't point to itself".

That problem might be resolved by giving the s1 and s0 updatable images their own Zigbee image types. The FOTA client will periodically send the request for image type 0xXXX which will inform FOTA server to send the bootloader update image for s0. For s1 the client will send request for image type 0xYYYY.
It should work as intended but it seems like a waste of memory on the FOTA server side because it will need to have enough space for containing s0, s1 and app images.

The other option is to use s0 as a main bootloader (well-tested, lifeguard) and update only bootloader in s1 partition.

What I am trying to achieve is to have only one binary file which will be suitable for both partitions. Is it even possible ? If not, why ?

RE: Zigbee FOTA mcuboot update

Pawel(embeddedsolutions.pl) — Sun, 02 Jul 2023 19:33:06 GMT

Hi Maria,

Thank you so much for taking a look on that topic.

I did some further research regarding choosing option A or B, but I have not decided yet. From my understanding option A
will require using Flash API, which seems like code duplication knowing that dfu target(stream) is already using that.
At this moment I tend to use the dfu library.
I assume that if I will choose the DFU lib I will have to write the code which will be similar to dfu_target_mcuboot.c
is that right ?

I am looking forward to hearing from you.

RE: Zigbee FOTA mcuboot update

Maria Gilje — Fri, 30 Jun 2023 12:14:12 GMT

Hello again,

Thanks again for your patience.

You seem to have covered the steps needed to adding an upgradable bootloader to your Zigbee application.

I have a few comments on step 4:

You can choose the option which suits you best (A or B).

Choosing option A will give you the most control over what is happening and more of the development is on you. The generated pm_config.h defines the start addresses for the different sections of flash and the header file can be included in your project. From your build folder it can be found in zephyr/include/generated.

If you opt for option B and choose the DFU target library, the functionality for firmware upgrade is already implemented. This option will include that you get familiar with the library and its complexity.

Other than the above, I recommend that you take the instructions and documentation for Zigbee FOTA into account:
Enabling Zigbee FOTA in an application
Zigbee FOTA library

Best regards,

Maria

RE: Zigbee FOTA mcuboot update

Maria Gilje — Thu, 29 Jun 2023 15:14:13 GMT

Hello,

I will look into this. Thank you for your patience.

Best regards,

Maria