Hello,
Jerry
Hello,
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.
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
Hi,
Could you upload the image with Confirm mode?
-Amanda H.
CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--confirm"
Happy to know the OTA issue is solved.
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
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