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

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!

Parents
  • 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

  • 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.

  • 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.

  • 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.

  • 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.

  • 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?

  • 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.

Reply Children
No Data
Related