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

[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.