DFU on NR54L15. The image in slot 1 was gone after the device power cycle.

[Sealin]

I'm using ncs 2.9.0.

1. I flashed the firmware V0.15.1 on the device. And .

2. Update it "Confirm only" with nRF Connect Device Manager App to V0.15.2The update was Compelete.

3. Then I reconnected to the device and read the images:

4. I powered cycle the device and read the images. again:

The image in Slot 1 is gone.

The update log is as follows:

[00:00:01.142,531] <inf> ieee802154_nrf5: nRF5 802154 radio initialized
[00:00:01.148,279] <inf> fs_zms: 4 Sectors of 4096 bytes
[00:00:01.148,292] <inf> fs_zms: alloc wra: 0, fc0
[00:00:01.148,301] <inf> fs_zms: data wra: 0, 0
[00:06:51.263,420] <wrn> bt_l2cap: Ignoring data for unknown channel ID 0x003a
[00:06:52.193,496] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:06:52.467,832] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:06:52.467,868] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:06:52.467,891] <inf> nordic_dfu_ble: DFU in progress, image 0: 0 B / 728290 B
[00:06:52.467,954] <inf> nordic_dfu_ble: Current image version: 0.15.1
[00:06:52.467,991] <inf> nordic_dfu_ble: New image version: 0.15.2
[00:06:52.468,002] <inf> nordic_dfu_ble: Enter update mode
[00:06:52.468,029] <inf> nordic_dfu_ble: DFU Started
[00:06:52.733,428] <inf> nordic_dfu_ble: DFU in progress, image 0: 1972 B / 728290 B
…
…
[00:08:00.395,757] <inf> nordic_dfu_ble: DFU in progress, image 0: 721812 B / 728290 B
[00:08:09.507,486] <inf> ieee802154_nrf5: nRF5 802154 radio initialized
[00:08:09.513,018] <inf> fs_zms: 4 Sectors of 4096 bytes
[00:08:09.513,031] <inf> fs_zms: alloc wra: 0, f00
[00:08:09.513,040] <inf> fs_zms: data wra: 0, c0
[00:08:09.529,476] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
                                            2d 79 a1 c8 6a 40 b7 3c  f6 74 f9 0b 22 d3 c4 80 |-y..j@.< .t.."...
                                            74 72 82 ba                                      |tr..             
[00:08:09.532,302] <inf> bt_hci_core: Identity: C2:C0:46:12:4B:D6 (random)
[00:08:09.532,323] <inf> bt_hci_core: HCI: version 6.0 (0x0e) revision 0x306b, manufacturer 0x0059
[00:08:09.532,340] <inf> bt_hci_core: LMP: version 6.0 (0x0e) subver 0x306b
[00:09:16.697,336] <inf> mcuboot_util: Image index: 0, Swap type: perm

I tested "Test and Confirm", too. The result is the same.

Could you give me some advice?

Thanks in advance!

[Vidar Berg]

Hello,

I have not noticed this myself.  But since it is not possible to revert back to the old image after the new app is confirmed, why is it a problem that the secondary slot is not shown at that stage? I can of course investigate to find out why, but it would be nice to know if it really is a problem first.

Best regards,

Vidar

[Sealin]

Hello,

Thank you for your reply.

I tried upgrading to 0.15.3 for the second time in step 3. When I click 'Start' in the application, the device will automatically restart. After restarting, I upgraded it again and it worked.

Or if I upgrade it directly after step 4, the second upgrade will also work.

It seems that the second upgrade only works when the second slot is empty.

So, I want to know why.

And I tested Lesson 9 – Exercise 5, the secondary slot was always shown. And the second upgrade worked.

BR.

[Sealin]

Hello,

Thanks for your reply.

The picture on step 3 was catptured after I upgraded the device from 0.15.1 to 0.15.2.  And the picture on step 4 was captured after I power cycle the device on 0.15.2 or it automatically reboot itself on 0.15.2 when I tried to update it to 0.15.3.  

BR.

[Vidar Berg]

Hello,

Is it possible that these versions may have different memory layouts? You can check the generated partitions.yml file in the build folder to confirm this (Partitioning device memory). It would also be helpful to view the logs from MCUBoot. This may show why the secondary slot is being erased.

You can increase the log level in mcubtoot by adding this line to your mcuboot configuration: 

CONFIG_MCUBOOT_LOG_LEVEL_DBG=y

[Sealin]

Hello,

Thanks for your reply and sorry for the delay.

The versions I used are nearly the same except the version number（CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION）.

The partitions.yml is as follow:

app:
  address: 0x8000
  end_address: 0xc0400
  region: flash_primary
  size: 0xb8400
mcuboot:
  address: 0x0
  end_address: 0x7800
  region: flash_primary
  size: 0x7800
mcuboot_pad:
  address: 0x7800
  end_address: 0x8000
  region: flash_primary
  size: 0x800
mcuboot_primary:
  address: 0x7800
  end_address: 0xc0000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0xb8800
  span: *id001
mcuboot_primary_app:
  address: 0x8000
  end_address: 0xc0400
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xb8400
  span: *id002
mcuboot_secondary:
  address: 0xc0400
  end_address: 0x179000
  orig_span: &id003
  - mcuboot_secondary_pad
  - mcuboot_secondary_app
  region: flash_primary
  size: 0xb8c00
  span: *id003
mcuboot_secondary_app:
  address: 0xc0c00
  end_address: 0x179000
  region: flash_primary
  size: 0xb8400
mcuboot_secondary_pad:
  address: 0xc0400
  end_address: 0xc0c00
  region: flash_primary
  size: 0x800
otp:
  address: 0xffd500
  end_address: 0xffd9fc
  region: otp
  size: 0x4fc
settings_storage:
  address: 0x179000
  end_address: 0x17d000
  region: flash_primary
  size: 0x4000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

I added the 

"CONFIG_LOG=y

CONFIG_MCUBOOT_LOG_LEVEL_DBG=y"

in sysbuild/mcuboot/prj.conf.

But I got "region `FLASH' overflowed by 7540 bytes" when I built.

It seems that there is not enough space for the log.

BR.

[Vidar Berg]

Hello, you can increase the size of the mcuboot partition with the CONFIG_PM_PARTITION_SIZE_MCUBOOT setting. For example, you can CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x12000 to your sysbuild/mcuboot/prj.conf file.

[Sealin]

Hello,

I'm very sorry for the delay.

I added CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x12000. But it still showed "region `FLASH' overflowed by 3024 bytes" .

It showed "3024 bytes" whether I didn't set CONFIG_PM_PARTITION_SIZE_MCUBOOT or I set it a larger size, like 0x13000.

I  modified the size 0x7800 of mcuboot in partition.yml to 0x8000, the overflowed size would decrease to "976 bytes".

When I increase it to 0x8400,  the building was still failed, but without "overflow xxx bytes" 

[180/185] Linking C executable zephyr/zephyr_pre0.elf
FAILED: zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map /opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr/zephyr_pre0.map 
: && ccache /opt/nordic/ncs/toolchains/b8efef2ad5/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -Os -DNDEBUG -gdwarf-4 -gdwarf-4 zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr/zephyr_pre0.elf  zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj  -T  zephyr/linker_zephyr_pre0.cmd  -Wl,-Map=/opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr/zephyr_pre0.map  -Wl,--whole-archive  app/libapp.a  zephyr/libzephyr.a  zephyr/arch/common/libarch__common.a  zephyr/arch/arch/arm/core/libarch__arm__core.a  zephyr/arch/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a  zephyr/arch/arch/arm/core/cortex_m/cmse/libarch__arm__core__cortex_m__cmse.a  zephyr/arch/arch/arm/core/mpu/libarch__arm__core__mpu.a  zephyr/lib/libc/minimal/liblib__libc__minimal.a  zephyr/lib/libc/common/liblib__libc__common.a  zephyr/soc/soc/nrf54l15/libsoc__nordic.a  zephyr/drivers/cache/libdrivers__cache.a  zephyr/drivers/clock_control/libdrivers__clock_control.a  zephyr/drivers/flash/libdrivers__flash.a  zephyr/drivers/timer/libdrivers__timer.a  modules/mcuboot/boot/bootutil/zephyr/libmcuboot_util.a  modules/hal_nordic/nrfx/libmodules__hal_nordic__nrfx.a  -Wl,--no-whole-archive  zephyr/kernel/libkernel.a  -L/opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr  zephyr/arch/common/libisr_tables.a  -mcpu=cortex-m33  -mthumb  -mabi=aapcs  -mfp16-format=ieee  -fuse-ld=bfd  -Wl,--gc-sections  -Wl,--build-id=none  -Wl,--sort-common=descending  -Wl,--sort-section=alignment  -Wl,-u,_OffsetAbsSyms  -Wl,-u,_ConfigAbsSyms  -nostdlib  -static  -Wl,-X  -Wl,-N  -Wl,--orphan-handling=warn  -Wl,-no-pie -L"/opt/nordic/ncs/toolchains/b8efef2ad5/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/thumb/v8-m.main/nofp" -lc -lgcc && cd /opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr && /opt/homebrew/Cellar/cmake/3.26.3/bin/cmake -E true
/opt/nordic/ncs/toolchains/b8efef2ad5/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: app/libapp.a(main.c.obj): in function `k_sem_give':
/opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr/include/generated/zephyr/syscalls/kernel.h:1120: undefined reference to `z_impl_k_sem_give'
/opt/nordic/ncs/toolchains/b8efef2ad5/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: app/libapp.a(main.c.obj): in function `k_thread_create':
/opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr/include/generated/zephyr/syscalls/kernel.h:85: undefined reference to `z_impl_k_thread_create'
/opt/nordic/ncs/toolchains/b8efef2ad5/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: app/libapp.a(main.c.obj): in function `k_thread_name_set':
/opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr/include/generated/zephyr/syscalls/kernel.h:436: undefined reference to `z_impl_k_thread_name_set'
/opt/nordic/ncs/toolchains/b8efef2ad5/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: app/libapp.a(main.c.obj): in function `k_sem_take':
/opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot/zephyr/include/generated/zephyr/syscalls/kernel.h:1103: undefined reference to `z_impl_k_sem_take'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
[10/20] No configure step for 'ac1'
FAILED: _sysbuild/sysbuild/images/bootloader/mcuboot-prefix/src/mcuboot-stamp/mcuboot-build /opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/_sysbuild/sysbuild/images/bootloader/mcuboot-prefix/src/mcuboot-stamp/mcuboot-build 
cd /opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug/mcuboot && /opt/homebrew/Cellar/cmake/3.26.3/bin/cmake --build .
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /opt/homebrew/bin/cmake --build /opt/nordic/ncs/v2.9.0/ac1/build_ac1_debug

Is 0x8000 the upper limit ?

Is there any way to decrease the usage of mcuboot?

BR.

[Vidar Berg]

Sealin said:

I added CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x12000. But it still showed "region `FLASH' overflowed by 3024 bytes" .

It showed "3024 bytes" whether I didn't set CONFIG_PM_PARTITION_SIZE_MCUBOOT or I set it a larger size, like 0x13000.

Did you add it to your mcuboot configuration? Also note that this configuration will be ignored if you are using a static partition layout (pm_static.yaml). Please test without the static partitioning file if you are using one.

[Sealin]

Hello,

Thanks for your reply.

After I removed the pm_static.yml, it built successfully.

But I didn't find any log of mcuboot on RTTViewer during DFU and reboot.

I have set "CONFIG_USE_SEGGER_RTT=y" in sys build/mcuboot/prj.conf. 

But the DFU became normal. I can update the device to 0.15.2 from 0.15.1, and then update it to 0.15.3 from 0.15.2. It didn't reboot itself when the second update starts. The image in slot 1 isn't gone. It's Flags are "Bootable", without "Pending" and "Permanent".

BR.

[Vidar Berg]

Hello,

I see now from your pm_static.yml that the size of the mcuboot slots are not aligned to a 0x1000 byte boundary as required (is currently 0xb8800). This will also lead to the same issues as discussed in this thread: 

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

Did you create the pm_static.yml yourself?

[Sealin]

Hello，

I copied the pm_static.yml from a sample and modified the size of the regions.

I added the pm_static.yml back, and modified the size of mcuboot to 0xb000. Then the DFU works now.

Thank you very much!

BR.