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.

[Vidar Berg]

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

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