Undesired behaviour from mcuboot immediately after DFU

[i_4556]

Hello, thanks for reading and happy holidays!

We are using an nrf5340dk, with zephyr and SDK 2.5.0.

We seem to have two undesired behaviors from MCUBoot immediately after performing an OTA DFU, and I was wondering if you have any suggestions?

Firstly, if we have devices bonded before performing the OTA DFU, the bonds seem to be deleted during the update. Is there a way to preserve them? Even when Erase App Settings is turned off, sometimes the bond information is still deleted.

Secondly, is there a way we can speed up the DFU process, in particular the time from when the file transfer completes until the device reboots? We are using almost all the flash, so I have always assumed this time is just how long the swap takes, but if we could safely hurry it along that would be good.

Thank you for all your help!

[Hung Bui]

Hi, 

Firstly, if we have devices bonded before performing the OTA DFU, the bonds seem to be deleted during the update. Is there a way to preserve them? Even when Erase App Settings is turned off, sometimes the bond information is still deleted.

We would need to investigate this. Have you find a reliable way to reproduce this issue ? Do you external flash for DFU update or internal flash ? How is bond information stored ? Please provide the partition setting. 

Secondly, is there a way we can speed up the DFU process, in particular the time from when the file transfer completes until the device reboots? We are using almost all the flash, so I have always assumed this time is just how long the swap takes, but if we could safely hurry it along that would be good.

How did you do DFU ? Did you select Test and Confirm or Confirm Only. From my understanding Confirm only would make it faster as it doesn't backup the original application hence save time. 
Other than that I don't see how we can make the process faster. 

[i_4556]

Thank you for your reply.

Hung Bui said:

How did you do DFU ? Did you select Test and Confirm or Confirm Only. From my understanding Confirm only would make it faster as it doesn't backup the original application hence save time. 
Other than that I don't see how we can make the process faster. 

Yes, we did test and confirm in the NRF Connect app. Ok, thats what I had assumed, I just wanted to check.

Hung Bui said:

We would need to investigate this. Have you find a reliable way to reproduce this issue ? Do you external flash for DFU update or internal flash ? How is bond information stored ?

We use internal flash only, and bond information is all handled by zephyr. Unfortunately we havent found a reliable way to reproduce the issue.

Our flash partition is also largely handled by zephyr, but we added a user storage partition through a PM_Static.yml file. I have included the output partition file in case that somehow helps you, and can provide anything else if needed.

EMPTY_0:
  address: 0xf8000
  end_address: 0xfc000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0x4000
app:
  address: 0x10200
  end_address: 0x84000
  region: flash_primary
  size: 0x73e00
custom_nvs_storage:
  address: 0xfe000
  end_address: 0x100000
  region: flash_primary
  size: 0x2000
mcuboot:
  address: 0x0
  end_address: 0x10000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    align:
      start: 0x4000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0x84000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x74000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0x84000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x73e00
  span: *id002
mcuboot_secondary:
  address: 0x84000
  end_address: 0xf8000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x4000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x74000
otp:
  address: 0xff8100
  end_address: 0xff83fc
  region: otp
  size: 0x2fc
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
settings_storage:
  address: 0xfc000
  end_address: 0xfe000
  placement:
    align:
      start: 0x4000
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20000000
  end_address: 0x20070000
  region: sram_primary
  size: 0x70000

[Hung Bui]

Hi, 
My suggestion is to try reading the flash area at 0xfc000 to 0xfe000 to check if it's wiped out when you see the bond info has been lost. 
If the bond info is still there, you may want to double check if the device's BLE address is not changed after the DFU update. If it's changed the phone won't be able to recognize the device after DFU. However if the device use Resolvable Random Address then it's harder to spot this. We would need to have a sniffer trace to see which exact side losing the bond information, the phone or the nRF53.