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

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

Sealin — Thu, 08 May 2025 08:51:36 GMT

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.

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

Vidar Berg — Thu, 08 May 2025 07:12:13 GMT

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?

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

Sealin — Thu, 08 May 2025 06:37:18 GMT

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.

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

Vidar Berg — Wed, 07 May 2025 11:14:34 GMT

[quote user="Sealin"]

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.

[/quote]

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.

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

Sealin — Tue, 06 May 2025 08:45:06 GMT

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.

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

Vidar Berg — Wed, 30 Apr 2025 11:28:01 GMT

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.

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

Sealin — Tue, 29 Apr 2025 08:54:45 GMT

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.

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

Vidar Berg — Wed, 23 Apr 2025 11:31:46 GMT

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

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

Sealin — Thu, 17 Apr 2025 04:09:31 GMT

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.

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

Vidar Berg — Wed, 16 Apr 2025 13:11:10 GMT

Hello,

Sorry for the delay. Could you please try incrementing the version number between every update and see if you get the same result? The picture indicates that you are attempting a downgrade from 0.15.2 -> 0.15.1. I'm not sure whether downgrade prevention is enabled by default in this bootloader build or not.

Best regards,

Vidar

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

Sealin — Fri, 11 Apr 2025 01:56:56 GMT

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.

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

Vidar Berg — Thu, 10 Apr 2025 11:33:27 GMT

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