NVS write succeeds, but read fails intermittently after flash erase on first boot (nRF52840, NCS v2.6.0)

RE: NVS write succeeds, but read fails intermittently after flash erase on first boot (nRF52840, NCS v2.6.0)

sai varma datla — Tue, 12 Aug 2025 07:30:13 GMT

Yes, exactly — BLE and Zigbee can both use settings_storage, which can cause NVS conflicts.
We fixed it by defining a static flash layout in pm_static.yml with a separate NVS partition for our app data, keeping it isolated from BLE/Zigbee settings and preventing read failures.

Thanks for pointing this out and for the helpful reference!

RE: NVS write succeeds, but read fails intermittently after flash erase on first boot (nRF52840, NCS v2.6.0)

Susheel Nuguru — Fri, 08 Aug 2025 11:16:07 GMT

Hi Dalta,

I am not very experienced with Zigbee but it seems like it can also use the default storage partition like BLE and can cause issues over time. The safest approach is to define a second, dedicated flash partition for your own NVS data. This is done by adding a custom_storage entry to partitions.yml and mounting it separately in your code. This keeps the application’s flash writes completely separate from the settings partition used by BLE and Zigbee, eliminating contention and improving stability, especially after a flash erase.

Lot of these are discussed in the devzone discussions
Flash partitionin

Wrong read from settings_storage flash in nRF52840 and nRF Connect SDK 2.4.1

RE: NVS write succeeds, but read fails intermittently after flash erase on first boot (nRF52840, NCS v2.6.0)

sai varma datla — Wed, 06 Aug 2025 10:55:06 GMT

Hi Susheel Nuguru,

Thank you for your response.

We have observed that there's only one storage partition being used in our project, and it's currently being shared by BLE (settings) and Zigbee. We suspect this overlap might be contributing to the intermittent nvs_read() failures, especially during the early boots after flash erase.

Additionally, in our code, we are calling bt_enable(NULL) before initializing our storage (i.e., before mounting the nvs_fs). While debugging, we also noticed in the NCS source code that the Bluetooth stack might also be using the same storage partition internally (possibly via the settings subsystem). This could lead to conflicts or data races when multiple components access the same flash region.

Follow-up Questions:

Is there a recommended way to create a dedicated/custom storage partition specifically for application data, separate from the one used by BLE/Zigbee settings?
Are there known conflicts or best practices when multiple subsystems (like BLE and Zigbee) share the same storage partition?
If partitioning is not an option, are there any other known resolutions or sync strategies to ensure data stability across boots?
If we need to create a static (custom) storage partition, could you please provide the correct steps to define and use it properly (e.g., using partitions.yml, nvs_fs, dts, etc.)?

We’re using the nRF52840 with NCS v2.6.0, and appreciate any guidance on how to resolve this storage overlap cleanly.

Thanks again for your support.

Best regards,
Sai Varma

RE: NVS write succeeds, but read fails intermittently after flash erase on first boot (nRF52840, NCS v2.6.0)

Susheel Nuguru — Wed, 06 Aug 2025 08:03:52 GMT

Hi Sai Varma,

If I understand correctly what you mean by nvs_read intermittently fails after write and reboot is that after couple of reboots the nvs_read succeeds sometimes? If that is the case, then the nvs_write was successful and there is some issue with the read sometimes.

Is it possible for you to provide me a minimalistic project on nRF52840DK so that I can try to understand the issue better?