• State Verified Answer
  • Replies 6 replies
  • Subscribers 69 subscribers
  • Views 761 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 321968
Options

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

Simon

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

Parents
  • 0

    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 ? 

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

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

Reply Children
Related