The swap algorithm is executed every time the device is powered on, and the swap type is "perm".

[Denghongyan]

Hello, 

We use nrf54l15dk + MX25R8035F external flash to do the matter development on NCS2.9.0, and we meet some problems:

1. when the matter.ota is 1003KB, takes about 10min30s to get the new fw, and 3min18s to do the swap algorithm, is it a normal speed?

2. The swap algorithm is executed every time the device is powered on, and the swap type is "perm". Following is my log:

[Vidar Berg]

Hello,

To reduce the swap time, you can set CONFIG_NRF_RRAM_WRITE_BUFFER_SIZE to '=20' in your MCUBoot configuration. This will be the default in the upcoming SDK v3.0.0 release. Regarding the confirm failure, do you have the same partition layout in the new and old version of the app (Partitioning device memory)?

It also looks like you are using the wrong JDEC ID for MX25R8035F:

Best regards,

Vidar

[Denghongyan]

For JDEC ID，I have solved the problem by adding 

&mx25r64

{

    status = "disabled";

};

[Vidar Berg]

Denghongyan said:

For JDEC ID，I have solved the problem by adding 

Have you cut the solder bridges connecting the MX25R64 on the development kit so you could use the same pins to connect to the MX25R8035F instead?

Denghongyan said:

It looks like if the mcuboot swap type is BOOT_SWAP_TYPE_TEST, it will return (we use nrf54l15), not excute boot_write_img_confirmed(). Is this ok?

The log says the swap is 'perm' which indicates that the image has been confirmed already. I.e. it will not be reverted.

[Denghongyan]

when i set CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y and

CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--confirm", the swap is perm.

Here is my newest test log, I don't use CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE and CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS:

1. thread dfu ok, excute swap test algorithm, in the app code confirm the fw:

2. reboot, It will excute the swap algorithm again:

3. every time I do the power off and power on, it will do the swap test and switch the fw with v400 and v401, did my pm_static.yml config wrong?

[Vidar Berg]

It seems like the bootloader fails to erase the image trailer for the secondary slot during the swap. Have you also tested the same with the on-board mx25r64 flash IC?

[Denghongyan]

I test dfu thread nrf54l15dk(mx25r64), at least ble ota works well, and now, I am using our customized board with MX25R8035F , then this problem occurred.

I also tried ble ota with this customized board, same problem, like you said, seems like the bootloader fails to erase the image trailer for the secondary slot during the swap, so always excute swap action.

[Vidar Berg]

I see. I thought you were testing on the nRF54L15 DK. Do you have logging from the custom board? It would help if we could view the logs from the bootloader. 

You can enable CONFIG_MCUBOOT_LOG_LEVEL_DBG in the bootloader configuration to increase the log level.

Example of what your mcuboot configuration overlay may look like:

<project root>/sysbuild/mcuboot.conf

CONFIG_NRF_RRAM_WRITE_BUFFER_SIZE=20
CONFIG_MULTITHREADING=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000
CONFIG_SPI_NOR=y
CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_BOOT_MAX_IMG_SECTORS=512
CONFIG_MCUBOOT_LOG_LEVEL_DBG=y

[Denghongyan]

Hey! it looks like a assigned problem about external flash:

[Denghongyan]

Here is my swap log, and I did one reboot, you can find two "Starting swap using move algorithm":

swap_log.txt

[Vidar Berg]

Hi,

Thanks for the logs. It looks like the image trailer in the secondary slot is not actually erased here:

: swap_erase_trailer_sectors: erasing trailer; fa_id=1 

To troubleshoot this, I suggest you add more logging in the function here: https://github.com/nrfconnect/sdk-mcuboot/blob/9d9d524407df6da0815c79c5b9cf645f1ce25592/boot/bootutil/src/swap_misc.c#L35. For example,  print the return value from the boot_erase_region() call (I'm not sure if ASSERTs are enabled..). 

[Denghongyan]

Hi,

boot_erase_region return error -22, there'is the log:

[Vidar Berg]

Thanks. I assume -EINVAL (-22) is returned here: https://github.com/zephyrproject-rtos/zephyr/blob/e96bf44d934050b404e53aefdcb9756290b4c18e/subsys/storage/flash_map/flash_map.c#L79. Does the offset + size exceed the size of your mcuboot slots? You can look up the partition sizes from the build/<proj name>/zephyr/include/generated/pm_config.h header.