NVS data in internal flash occasionally erased after MCUboot OTA update (nRF5340 + nRF7003, NCS v2.6.2)

[Urvisha Andani]

Hello,

We are using a custom board based on the nRF5340 + nRF7003 Fanstel module with NCS SDK v2.6.2.

Our application uses MCUboot with dual-bank OTA updates. The secondary image slot is located in external flash, while application-specific data is stored permanently in internal flash using NVS.

During production, we write some configuration data to the internal flash only once. This data is then used by the application during normal operation and communication throughout the product lifetime. The data is not modified after production programming.

Issue:

We have observed that after a successful OTA update, the data stored in the NVS partition is occasionally erased.

The issue is intermittent and difficult to reproduce consistently. It occurs approximately once in every 10 OTA update attempts.

Expected behaviour:

The NVS data stored in internal flash should remain intact after OTA updates and device reboots.

Observed behaviour:

• OTA update completes successfully.
• MCUboot swaps the image and boots into the new application.
• The device operates normally after the update.
• However, in some cases, the NVS partition appears to be erased and all stored production data is lost.
• This issue occurs randomly and cannot be reproduced on every OTA attempt

Partition Manager configuration:

EMPTY_0:
  address: 0xfe000
  end_address: 0x100000
  placement:
    after:
    - settings_storage
  region: flash_primary
  size: 0x2000

app:
  end_address: 0xfc000
  region: flash_primary
  size: 0xebe00

external_flash:
  address: 0xec000
  end_address: 0x800000
  region: external_flash
  size: 0x714000

mcuboot:
  address: 0x0
  end_address: 0x10000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x10000

mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200

mcuboot_primary:
  address: 0x10000
  end_address: 0xfc000
  region: flash_primary
  size: 0xec000

mcuboot_primary_app:
  address: 0x10200
  end_address: 0xfc000
  region: flash_primary
  size: 0xebe00

mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xec000
  region: external_flash
  size: 0xec000

nvs_storage:
  address: 0xfa000
  end_address: 0xfc000
  region: flash_primary
  size: 0x2000

settings_storage:
  address: 0xfc000
  end_address: 0xfe000
  region: flash_primary
  size: 0x2000

Additional information:

• Data is stored in nvs_storage (0xFA000 - 0xFC000).
• OTA image is downloaded to external flash (mcuboot_secondary).
• MCUboot performs the image swap during reboot.
• We are not intentionally erasing the NVS partition anywhere in the application.

Request

Could you please help us identify the root cause of this behaviour and suggest a solution?

We already have approximately 1000 devices deployed in the field. Because of this, changing the flash layout or relocating the production data storage is not a practical option for the deployed products.

We are looking for a solution or workaround that can be implemented through a firmware update without affecting the current flash layout or existing device operation.

Any guidance would be greatly appreciated.

Thanks & Regards,

Urvisha Andani

 

[Einar Thorsrud]

Hi Urvisha,

The partition layout is icorrect, as nvs_storage overlaps with mcuboot_primary. As MCUboot here is not updatable, there is no way to fix this in the field for MCUboot. The only proper fix is to make a new partition layout where you ensure no overlaps.

For devices in the field, you do not have any guarantees against loss of data. However, it may be possible to push an update of the app, where the new app has nvs_storage placed at what is now reseved as EMPTY_0. This is just two pages though. You must expect loss of data though, but in cases where the original NVS data is intact, you could then have the new application copy it to the new region. This is not a good approach nor a recommended approach, but it may be a solution.

As the data never changes during the product lifecycle, a better approach could be to put it in UICR OTP. That is well suited for fixed data, and you have no conflict with DFU and it is outside of the normal partition layout. See this thread.

A last option is to use settings storage, as that does not overlap.

Best regards,

Einar