How to determine if flash write has completed using zms_write() or nvs_write()

[Nick_RA]

NCS 3.02 + nRF54L15

I'm troubleshooting a potential bug. Are these blocking routines, or if not how do I monitor for successful completion of flash write? I looked the the API docs and the ZMS sample project but neither give any clue.

My concern is if the system is rebooted too soon after saving might result in corruption.

Thanks

[Susheel Nuguru]

Emil Lenngren said:

I wouldn't use ZMS at this stage though since I wouldn't call the code stable/bug-free yet.

As written in nrf/doc/nrf/app_dev/data_storage.rst, Nordic´s official stance is

The :ref:`Zephyr Memory Storage (ZMS) <zephyr:zms_api>` is the recommended storage solution for the nRF54L and nRF54H Series.
ZMS uses a flexible data management system that reduces write and erase cycles, extending the lifespan of non-volatile memory.
ZMS stores data as values identified by a 32-bit integer ID.

and as shown in nrf/doc/nrf/app_dev/device_guides/nrf54l/zms.rst

For the nRF54L and nRF54H Series, use the :ref:`Zephyr Memory Storage (ZMS) <zephyr:zms_api>`.
ZMS utilizes a flexible data management system that reduces write and erase cycles, extending the lifespan of non-volatile memory.

For trusted storage as written in nrf/doc/nrf/libraries/security/trusted_storage.rst

    ZMS is the only allowed storage option for nRF54L Series devices, while other devices using the trusted storage library can choose between the two options.

Now regarding the issue you are seeing with ZMS, There seems to be one unhandled bug that Emil has already linked to, which seems a bit related to the memory leak kind of issue you are seeing. Lots of other systems in our solutions are using ZMS, but since you have hit this one where there does not seem to a fix yet, maybe you can try using NVS. But you wont be able to use some trusted_storage libraries as ZMS is the only backend supported for nRF54L devices for those libraries.

[Nick_RA]

Susheel Nuguru said:

Now regarding the issue you are seeing with ZMS, There seems to be one unhandled bug that Emil has already linked to, which seems a bit related to the memory leak kind of issue you are seeing. Lots of other systems in our solutions are using ZMS, but since you have hit this one where there does not seem to a fix yet, maybe you can try using NVS. But you wont be able to use some trusted_storage libraries as ZMS is the only backend supported for nRF54L devices for those libraries.

So, just to be clear, are you saying that NVS is OK to use on nRF54lxx for basic flash read/write?

This is just to store configuration data, The configuration is held into a structure of maybe 30 bytes, and is written either by CLI command via uart, or by a command written via BLE. The record is then read back at boot time.

I do actually have code for both NVS & ZMS, because this code needs to run on nRF52 as well. So I use Kconfig and some #if...#endif directives to select which one is compiled.

(The reason I was enquiring about blocking, is in case the board is reset after a save.)

Regards,

Nick

[Susheel Nuguru]

I do not see why NVS cannot work on the nRF54L.

Looking into the files (NCSv3.1.1) in zephyr/drivers/flash/soc_flash_nrf_rram.c reports erase value 0xFF, 4 KB erase blocks, and 16‑byte write blocks which seem to be within NVS requirements. If you do not worry about flash endurance and trusted_storage, then you should try NVS, especially when you have hit the bugs with ZMS where there is no workaround, yet.