NVS is erased after OTA

[MOHAMED AHMED ALI MAHMOUD ELSABAGH]

We have a product which is based on nrf52840 and nrf connect sdk 2.8.0

After OTA sometimes, I find that the NVS is erased, which could lead to some issues on client side.

Here is the content of pm_static file

app:
  address: 0xc200
  end_address: 0x85000
  region: flash_primary
  size: 0x78e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x85000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x79000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x85000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x78e00
  span: *id002
mcuboot_secondary:
  address: 0x85000
  end_address: 0xfe000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x79000
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

and on the overlay file we have 

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0x0000C000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x00067000>;
		};
		slot1_partition: partition@73000 {
			label = "image-1";
			reg = <0x00073000 0x00067000>;
		};
		scratch_partition: partition@da000 {
			label = "image-scratch";
			reg = <0x000da000 0x0001e000>;
		};

		/*
		 * The flash starting at 0x000f8000 and ending at
		 * 0x000fffff is reserved for use by the application.
		 */

		/*
		 * Storage partition will be used by FCB/LittleFS/NVS
		 * if enabled.
		 */
		storage_partition: partition@f8000 {
			label = "storage";
			reg = <0x000f8000 0x00008000>;
		};
	};
};

on proj.conf

# Enable mcumgr.
CONFIG_MCUMGR=y
# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y
# Enable FOTA over BLE
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y
CONFIG_SECURE_BOOT=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y
# This is enabled only in prodcution, but will limit debugging and breakpoints
# CONFIG_DISABLE_FLASH_PATCH=y # already defined in mcuboot.conf
# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.
CONFIG_BT_SMP=y
CONFIG_ZCBOR=y
CONFIG_STREAM_FLASH=y
CONFIG_MCUMGR_TRANSPORT_BT=y
CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW=n
CONFIG_MCUMGR_TRANSPORT_BT_CONN_PARAM_CONTROL=y
CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_OS=y
# Enable MCUmgr Packet Reassembly feature over Bluetooth and its
# configuration dependencies. MCUmgr buffer size is optimized to fit one SMP
# packet divided into five Bluetooth Write Commands, transmitted with the
# maximum possible MTU value: 498 bytes.
CONFIG_MCUMGR_TRANSPORT_BT_REASSEMBLY=y
CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE=2475
CONFIG_MCUMGR_GRP_OS_MCUMGR_PARAMS=y
# Enable custom SMP request to erase settings partition.
CONFIG_MCUMGR_GRP_ZBASIC=n
CONFIG_MCUMGR_GRP_ZBASIC_STORAGE_ERASE=y
CONFIG_MCUMGR_GRP_OS_ECHO=y
CONFIG_MCUMGR_GRP_OS_INFO=y

[Turbo J]

Your pm_static and DTS overlay disagree on the storage patition layout. pm_static says its at 0xFE000 and 0x2000 bytes while the overlay has it at 0xF8000 with 0x8000 bytes.

They need to match, otherwise the bootloader will overwrite your settings.

[MOHAMED AHMED ALI MAHMOUD ELSABAGH]

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0x0000C000>;
		};
		boot_pad_partition: partition@c000 {
			label = "mcuboot_pad";
			reg = <0x0000C000 0x0000200>;
		};
		slot0_partition: partition@c200 {
			label = "image-0";
			reg = <0x0000C200 0x00078E00>;
		};
		slot1_partition: partition@85000 {
			label = "image-1";
			reg = <0x00085000 0x00079000>;
		};

		storage_partition: partition@fe000 {
			label = "storage";
			reg = <0x000FE000 0x00002000>;
		};
	};
};

I updated the DTS overlay file, but still have the same issue

[Vidar Berg]

Hi,

The storage partition can become erased if you have both CONFIG_MCUMGR_GRP_ZBASIC_STORAGE_ERASE and CONFIG_MCUMGR_GRP_ZBASIC enabled and if the mcumgr client issues the settings erase command as part of the DFU process. But I see CONFIG_MCUMGR_GRP_ZBASIC is disabled in the configuration I posted, so I assume that is not the issue here. Can you inspect the storage partition after the DFU to see if the partition was erased or overwritten with FW data?

[MOHAMED AHMED ALI MAHMOUD ELSABAGH]

I found the issue was in my nvs_driver, the sector size, count and offset were not set correctly to match values in pm_static.yml, once those values were set correctly issue was resolved