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

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

Parents

0 Nick_RA 5 months ago

There's definitely something wacky going on when I use zms_write().

This is my snip of code to do the save:

	struct zms_fs fs;
	struct flash_pages_info info;
	fs.flash_device = ZMS_PARTITION_DEVICE;
	if (!device_is_ready(fs.flash_device)) {
		printk("Storage device %s is not ready\n", fs.flash_device->name);
		return 0;
	}
	fs.offset = ZMS_PARTITION_OFFSET;
	rc = flash_get_page_info_by_offs(fs.flash_device, fs.offset, &info);
	if (rc) {
		printk("Unable to get page info, rc=%d\n", rc);
		return 0;
	}
	fs.sector_size = info.size;
	fs.sector_count = 3U;
	rc = zms_mount(&fs);
	if (rc) {
		printk("Flash Init failed, rc=%d\n", rc);
		return rc;
	}
	rc = zms_write(&fs, NVS_SETTINGS_ADDR, &nv_settings, sizeof(nv_settings));
	if (rc == sizeof(nv_settings))
	{
		printk("Settings saved" CRLF);
	}
	else
	{
		printk("Error saving settings" CRLF);
	}
	return rc;

(nv_settings is a struct)

And this is an example of the debug log when it goes wrong

[00:01:40.674,492] <inf> fs_zms: 3 Sectors of 4096 bytes
[00:01:40.674,514] <inf> fs_zms: alloc wra: 0, ed0
[00:01:40.674,523] <inf> fs_zms: data wra: 0, 410
Settings saved
[00:01:47.214,505] <wrn> app: Not able to allocate UART receive buffer
[00:01:47.264,545] <wrn> app: Not able to allocate UART receive buffer

The uart handling is basically a copy of the sample project lp_uart. I have a command to print a menu of the settings (so lots of printing) which I can run repeatedly, but I can make this crash after multiple (14 last time I tried it) saves.

I don't think this is a UART issue, because I can make the system do the same thing by command sent via BLE.

Note there is no kernel panic, reboot etc happening. Just as you see it in the log.

Reply