keep Settings Data and existing bonds during OTA update - nRF Connect SDK

Hi,

SoC: nrf52840
Environment: nRF Connect SDK v2.4.1

When performing OTA app upgrade all settings and bonds are gone.
Settings subsystem seems to be working fine. Settings are corrently loaded at startup and data is preserved during MCU reboot. Data is also preserved when flashing app via SWD.
Is there any configuration that I am missing, which can preserve at least Settings during OTA?

prj.conf:
# Settings
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS=y

#MCUMGR
CONFIG_MCUMGR=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_SECURE_BOOT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y

code:
settings_subsys_init();
settings_load();

Regards,
Simon

Top Replies

Hung Bui over 1 year ago in reply to Simon +1 verified

Hi Simon, I think I know why that happens. Are you using nRF Device Manager for updating ? There is an option which is enabled by default that erase the application settings: If you click on the small…

Parents

0 Hung Bui over 1 year ago

Hi,
Please provide the partitions.yml in the build folder or the pm_static.yml if you are using static partitions. Please provide the file for both the old project and the new project that you are updating to.
I suspect that the partition was changed and somehow overlapping the setting partition.

Do you change anything that may change the partition allocation ?
How do you receive the image ? Did you use the smp_svr ?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 Simon over 1 year ago in reply to Hung Bui

Hi,

here is partitions.yml content. I don't use static one. Content of the partitions.yml is the same between the builds. There is basically no difference between the "old" and the "new" project as I am testing update proces just between the builds.

EMPTY_0:
  address: 0x15200
  end_address: 0x16000
  placement:
    before:
    - s1_pad
  region: flash_primary
  size: 0xe00
EMPTY_1:
  address: 0x22200
  end_address: 0x23000
  placement:
    before:
    - mcuboot_pad
  region: flash_primary
  size: 0xe00
EMPTY_2:
  address: 0xfd000
  end_address: 0xfe000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0x1000
app:
  address: 0x23200
  end_address: 0x90000
  region: flash_primary
  size: 0x6ce00
app_image:
  address: 0x23200
  end_address: 0x90000
  orig_span: &id001
  - app
  region: flash_primary
  size: 0x6ce00
  span: *id001
b0:
  address: 0x0
  end_address: 0x8000
  placement:
    after:
    - start
  region: flash_primary
  size: 0x8000
b0_container:
  address: 0x0
  end_address: 0x9000
  orig_span: &id002
  - b0
  - provision
  region: flash_primary
  size: 0x9000
  span: *id002
mcuboot:
  address: 0x9200
  end_address: 0x15200
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  sharers: 0x1
  size: 0xc000
mcuboot_pad:
  address: 0x23000
  end_address: 0x23200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  sharers: 0x2
  size: 0x200
mcuboot_primary:
  address: 0x23000
  end_address: 0x90000
  orig_span: &id003
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x6d000
  span: *id003
mcuboot_primary_app:
  address: 0x23200
  end_address: 0x90000
  orig_span: &id004
  - app
  region: flash_primary
  size: 0x6ce00
  span: *id004
mcuboot_secondary:
  address: 0x90000
  end_address: 0xfd000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x6d000
provision:
  address: 0x8000
  end_address: 0x9000
  placement:
    after:
    - b0
    align:
      start: 0x1000
  region: flash_primary
  size: 0x1000
s0:
  address: 0x9000
  end_address: 0x15200
  orig_span: &id005
  - s0_pad
  - mcuboot
  region: flash_primary
  size: 0xc200
  span: *id005
s0_image:
  address: 0x9200
  end_address: 0x15200
  orig_span: &id006
  - mcuboot
  region: flash_primary
  size: 0xc000
  span: *id006
s0_pad:
  address: 0x9000
  end_address: 0x9200
  placement:
    after:
    - b0_container
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_pad
  size: 0x200
s1:
  address: 0x16000
  end_address: 0x22200
  orig_span: &id007
  - s1_pad
  - s1_image
  region: flash_primary
  size: 0xc200
  span: *id007
s1_image:
  address: 0x16200
  end_address: 0x22200
  placement:
    after:
    - s1_pad
    - s0
  region: flash_primary
  share_size:
  - mcuboot
  size: 0xc000
s1_pad:
  address: 0x16000
  end_address: 0x16200
  placement:
    after:
    - s0
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_pad
  size: 0x200
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    align:
      start: 0x1000
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Hung Bui said:
Do you change anything that may change the partition allocation ?

This is hard to answer. I might changed something unintentionaly.

Hung Bui said:
How do you receive the image ?

Image is generated with default build task, generated by nRF Connect vscode plugin.

For OTA update I used "app_update.bin" file from build/zephyr/ directory.

Hung Bui said:
Did you use the smp_svr ?

I am using mcumgr SMP:

#include <zephyr/mgmt/mcumgr/transport/smp_bt.h>
...
int main(void)
{
...
    smp_bt_register();
...
}

# sleep/shutdown
smp_bt_unregister();

Maybe it's worth mentioning that I also tried to enable Direct XIP without success. I get similar issue as described here:

https://devzone.nordicsemi.com/f/nordic-q-a/102186/partition-manager-error-w-direct-xip-and-mcuboot-enabled

0 Hung Bui over 1 year ago in reply to Simon

Hi Simon,
If you have an identical partitions.yml then the partition may not be the culprit here.

I suspect that there could be change in the setting module that may change the layout of the setting data. Causing the data mismatch.
Have you tried to read the setting flash area out before the settings_subsys_init() is called in the new firmware (maybe putting an infinite loop there, then read flash using nrfjprog.exe --memrd or nrfjprog --readcode). You would need to read flash at address 0xfe000.

You may want to compare the flash before and after DFU update to see if the setting area is overwritten or not. If the content doesn't change, then it must be something changed in the settings layout causing it not able to read the bond information.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Simon over 1 year ago in reply to Hung Bui

Hi,

I saved settings area before upgrade and then added hardcoded asm breakpoint instruction at the beggining of int main(void). With this image I made DFU update and read the same settings area after the update. It seems that DFU erased "settings_storage" section completely.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
+1 Hung Bui over 1 year ago in reply to Simon

Hi Simon,

I think I know why that happens.
Are you using nRF Device Manager for updating ?
There is an option which is enabled by default that erase the application settings:

If you click on the small arrow button in Firmware Upgrade , you will find the option to not to Erase application settings.
In nRF Connect app this setting is hidden in Settings/Mcu Manager options/Erase application settings

Could you please disable it and try again?
Cancel
Vote Up +1 Vote Down

Sign in to reply

Reject Answer

Cancel

Reply

+1 Hung Bui over 1 year ago in reply to Simon

Hi Simon,

I think I know why that happens.
Are you using nRF Device Manager for updating ?
There is an option which is enabled by default that erase the application settings:

If you click on the small arrow button in Firmware Upgrade , you will find the option to not to Erase application settings.
In nRF Connect app this setting is hidden in Settings/Mcu Manager options/Erase application settings

Could you please disable it and try again?
Cancel
Vote Up +1 Vote Down

Sign in to reply

Reject Answer

Cancel

Children

0 Simon over 1 year ago in reply to Hung Bui

Hi,

I am using nRF Connect mobile app and I was not aware of this setting as nothing is shown during DFU update process.

I can confirm that everything works fine if I disable this option.

Thanks for your support!
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Marko W 7 months ago in reply to Simon

Hello, I have the same problem and the workaround works for me.
But can't you protect the settings from being deleted via the OTA update?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Marko W 6 months ago in reply to Marko W

I have now found a solution to prevent deletion via BLE directly in the firmware.

You can disable support for this by switching off the function via CONFIG_MCUMGR_GRP_ZBASIC_STORAGE_ERASE=n or the entire SMP group 63 "Zephyr Management Group" via CONFIG_MCUMGR_GRP_ZBASIC=n (erase storage is currently the only function in the group anyway).

Notes: I had originally tried to solve the problem with MGMT_EVT_OP_SETTINGS... hooks, spent a lot of time and recorded BLE via Wireshark to find out that the SMP group 3 "Settings (Config) Management Group" not used.

I also found when looking through the source code that there are no hooks for the SMP group 63 "Zephyr Management Group" where you could intervene in the process.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Reject Answer

Cancel