NVS write fails error -22 when building with sysbuild

[Nick_RA]

nRF54L15 - ncs 3.02 - toolchain 3.02

I changed my build settings from no sysbuild to sysbuild in order to use serial recovery and/or FOTA. I thought everything was OK until I tried saving settings to NVS where I now get error -22

(Before asking why I'm using NVS not ZMS I was advised to as ZMS is still buggy and it gives problems)

Do I need to manually change partitioning to make this work?

Here is the NVS write code:

	struct nvs_fs fs;
	struct flash_pages_info info;

	fs.flash_device = NVS_PARTITION_DEVICE;

	if (!device_is_ready(fs.flash_device)) {
		printk("Flash device %s is not ready\n", fs.flash_device->name);
		return 1;
	}

	fs.offset = NVS_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 rc;
	}

	fs.sector_size = info.size;
	fs.sector_count = 3U;
	rc = nvs_mount(&fs);
	if (rc) {
		printk("Flash Init failed, rc=%d\n", rc);
		return rc;
	}

	rc = nvs_write(&fs, NVS_SETTINGS_ADDR, &mybuff, sizeof(mybuf));

	return rc;

[Simonr]

Hi Nick

If you stripped out BLE from your project, why would you also have configs for Bluetooth settings like CONFIG_BT_DIS_SETTINGS. I think the selection of the settings subsystem which this config sets is what causes it to fail on your end. Probably because the NVS tries accessing addresses expected to be used by CONFIG_SETTINGS.

Have you used the NVS sample for reference to see how the NVS subsystem should be used. I'd try to get that up and running with sysbuild before incorporating the Bluetooth controller.

Best regards,

Simon

[Nick_RA]

I think you might be missing or maybe evading the point here...

Yes the sample runs correctly, I actually ran the zms not nvs, but I'm sure both will work. As will Blinky and the rest of the samples - but that's completely irrelevant to my actual problem!

I haven't stripped BLE from my project. I spent half a day stripping out code section by section until I ended up with the simplest bit of code that will reproduce my problem and that is what I have uploaded. I can't upload the project itself as it contains a lot of proprietary IP including custom protocols, PSK etc. In this project I use a lot of subsystems including crypto, uart, i2c, gpio ppi, timers, GAP/GATT, DIS, wdt so you can appreciate it's a bit of a headache trying to isolate conflicts.

Simonr said:

Probably because the NVS tries accessing addresses expected to be used by CONFIG_SETTINGS.

Is this speculation or something you know to be so? Sounds like a bug to me if two subsystems are trying to use the same memory especially considering it is all macro driven. If true, then surely all I have to do is adjust my NVS partition offset if there is a way to reliably do that at compile time or run time (I do NOT want to just choose some arbitrary value). Currently the offset is defined by macro:

#define NVS_PARTITION			storage_partition
#define NVS_PARTITION_DEVICE	FIXED_PARTITION_DEVICE(NVS_PARTITION)

Alternatively is there another way I can store 100 bytes or so non volatile? In hindsight I wish I had added an external EEPROM to my board but it's too late for that now.