Matter OTA from MATTER1.1 ~ MATTER1.3

[hoorii-zzy]

Hello,

the mass production firmware of our product was generated on NCS 2.2.0 (MATTER 1.1). Now, we are attempting to OTA upgrade our product to the firmware based on NCS 2.7.0 (MATTER 1.3). However, I encountered an issue where the OTA download succeeds but the update does not take effect properly.

I used chip-tool for testing and confirmed that the download was successful and the device restarted after a while. However, when I checked the version number, it still showed as 1, indicating that the update did not succeed.

I would like to know how to troubleshoot this issue. I have already confirmed that the .dts and pm_static.yml files are identical between the two versions.

Here are the chip-tool logs。I am looking forward for your reply.
Jerry

HooRiiCD-OTA-request-2-21.txtHooRiiCD-OTA-provide-2-21.txt

[Amanda Hsieh]

Hi, 

What is the application size? Could you provide the size report at the end of the build log?

Could you provide the mcuboot log from the device after the OTA upgrade to help us investigate the issue?

You can add the following configs into child_image/mcuboot.conf

# Enable logging
CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y

Regards,
Amanda H.

[SemiBrain]

Hi Amanda,
The firmware Flash build information that needs to be updated is as follows. Additionally, I have obtained the corresponding MCUBoot logs, which indicate that an exception occurred during firmware startup after the swap, resulting in a rollback. 

Memory region         Used Size  Region Size  %age Used
           FLASH:      711852 B     970240 B     73.37%
             RAM:      190812 B       256 KB     72.79%
        IDT_LIST:          0 GB        32 KB      0.00%

I: Starting bootloadert image slot
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
D: erasing trailer; fa_id=3
D: initializing status; fa_id=3
D: writing swap_info; fa_id=3 off=0xeafd8 (0xf3fd8), swap_type=0x2 image_num=0x0
D: writing swap_size; fa_id=3 off=0xeafd0 (0xf3fd0)
D: writing magic; fa_id=3 off=0xeaff0 (0xf3ff0)
D: erasing trailer; fa_id=1
D: writing copy_done; fa_id=3 off=0xeafe0 (0xf3fe0)
I: Bootloader chainload address offset: 0x9000
I: Starting bootloadert image slot
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: revert
I: Starting swap using move algorithm.
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
D: erasing trailer; fa_id=1
D: writing image_ok; fa_id=1 off=0xeafe8 (0xeafe8)
D: writing swap_size; fa_id=1 off=0xeafd0 (0xeafd0)
D: writing magic; fa_id=1 off=0xeaff0 (0xeaff0)
D: erasing trailer; fa_id=3
D: initializing status; fa_id=3
D: writing swap_info; fa_id=3 off=0xeafd8 (0xf3fd8), swap_type=0x4 image_num=0x0
D: writing image_ok; fa_id=3 off=0xeafe8 (0xf3fe8)
D: writing swap_size; fa_id=3 off=0xeafd0 (0xf3fd0)
D: writing magic; fa_id=3 off=0xeaff0 (0xf3ff0)
D: erasing trailer; fa_id=1
D: writing copy_done; fa_id=3 off=0xeafe0 (0xf3fe0)
I: Bootloader chainload address offset: 0x9000
I: Jumping to the first image slot

Regards,
Charles

[Amanda Hsieh]

Hi, 

Could you upload the image with Confirm mode?

-Amanda H.

[SemiBrain]

Thank you for your response. After submitting the content, I also considered this possibility and carried out some investigation and trials using the firmware confirmation approach. I have identified the specific cause of the issue and successfully completed the OTA.

I generated a confirmed and fully functional OTA image using the following configuration settings.

CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y
CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--confirm"

However, after completing the OTA with this approach, we encountered a new issue that is unrelated to the OTA process itself. I will submit a new ticket to address and discuss this issue. Thank you once again.

Regards,
Charles

[Amanda Hsieh]

Happy to know the OTA issue is solved.

[SemiBrain]

Hi, Amanda

We need to reopen this issue.
The current approach of using the configuration option to provide a confirmed image does not fully meet our application requirements.
Since this method imposes strict constraints on DTS partitions, we are looking for an alternative solution to ensure that the old version of MCUBoot can successfully boot our firmware rather than rolling it back. Would you be able to provide any alternative solutions to help us resolve this issue?
Additional information: The old version of MCUBoot is v1.9.99-ncs3-rc2.

Regards,
Charles