Concurrent usage of NV and settings on the same partition

RE: Concurrent usage of NV and settings on the same partition

DominikRekawek — Tue, 02 Aug 2022 11:10:31 GMT

Hi,

You are correct, but seems this may be also achieved by calling:
int settings_subsys_init(void) at app init, what worked out for me.

Dominik,

RE: Concurrent usage of NV and settings on the same partition

Simon — Fri, 29 Jul 2022 20:18:30 GMT

A pull request has now been made to fix #48328, see https://github.com/zephyrproject-rtos/zephyr/pull/48420

RE: Concurrent usage of NV and settings on the same partition

Simon — Wed, 27 Jul 2022 12:43:10 GMT

I'm happy to help and glad it worked on your side.

One thing to be aware of, I think you need to run bt_enable() before using the nvs_fs settings struct. This is because it will indirectly populate the struct through bt_enable()-->bt_settings_init()-->settings_subsys_init()-->settings_backend_init().

Not sure if you can answer anymore here, since the status of the ticket is set to "Verified"

RE: Concurrent usage of NV and settings on the same partition

DominikRekawek — Wed, 27 Jul 2022 12:33:58 GMT

Hi Simon,

This is great, I ported this to product and so far I can't crash/break this.

I really like simplicity of this solution :D

Thanks a lot for your support!

Dominik,

RE: Concurrent usage of NV and settings on the same partition

Simon — Tue, 26 Jul 2022 15:51:36 GMT

My fix does the job, but is probably not an optimal solution. I created a Zephyr issue regarding this which you can follow here: https://github.com/zephyrproject-rtos/zephyr/issues/48328

Best regards,

Simon

RE: Concurrent usage of NV and settings on the same partition

Simon — Tue, 26 Jul 2022 15:39:09 GMT

I talked to a developer, and one thing we forgot to inform you about, is that you need to use the same nvs_fs struct as the settings backend.

Please apply this patch to Zephyr v3.0.99-ncs1 (part of NCS v2.0.0):

diff --git a/subsys/settings/src/settings_nvs.c b/subsys/settings/src/settings_nvs.c
index 24e7a9e79e..85c5da8f0c 100644
--- a/subsys/settings/src/settings_nvs.c
+++ b/subsys/settings/src/settings_nvs.c
@@ -273,9 +273,14 @@ int settings_nvs_backend_init(struct settings_nvs *cf)
 	return 0;
 }
 
+static struct settings_nvs default_settings_nvs;
+
+struct nvs_fs* get_nvs_fs_structure(void){
+	return &default_settings_nvs.cf_nvs;
+}
+
 int settings_backend_init(void)
 {
-	static struct settings_nvs default_settings_nvs;
 	int rc;
 	uint16_t cnt = 0;
 	size_t nvs_sector_size, nvs_size = 0;

I simply added an API to get the nvs_fs struct

Then test the following sample:

devzone.nordicsemi.com/.../settings_5F00_nvs_5F00_ble_5F00_v2.zip

I modified your sample to use the API to get the nvs_fs settings struct and use that for your nvs calls.

RE: Concurrent usage of NV and settings on the same partition

Simon — Fri, 22 Jul 2022 22:34:52 GMT

Hello Dominik,

I'll test your sample next week

Best regards,

Simon

RE: Concurrent usage of NV and settings on the same partition

DominikRekawek — Wed, 20 Jul 2022 13:09:48 GMT

Hi,

Sorry for long idle time but we had to consider other options that could replace NVS. The discussion ends up with a statement that NV + Settings is what we really need to have in product. Please find attached reproduction app.

Application flow is:
- Initialize NV, do some read/write

- Pair

-Read/Write

-Reboot

After reboot there is no bounded device found.

I wonder if NVS+Settings shopuld work using theirs own APIs or if I should provide custorm load/save implementation for settings that will use NVS that is initialized in sope of my application.

Dominik,

devzone.nordicsemi.com/.../settings_5F00_nvs_5F00_ble.7z

RE: Concurrent usage of NV and settings on the same partition

Simon — Thu, 07 Jul 2022 13:51:03 GMT

Could you upload a minimal reproducible sample? Then I can continue to investigate this on my side

Best regards,

Simon

RE: Concurrent usage of NV and settings on the same partition

DominikRekawek — Wed, 06 Jul 2022 13:14:22 GMT

Hi,

Following settings_nvs.h hint:

After reusing code from settings_backend_init() and settings_nvs_backend_init() I am still meeting the issue with BT settings. I can see that new data is being stored in flash (by dumping the chip) both for NVS and settings, but unfortunately bt_foreach_bond() does not find any boundings after reboot. Hovewer I can see that bt keys have found some keys in flash:

On boot:

Load settings
[00:00:11.085,601] <dbg> bt_settings: bt_settings_decode_key: Decoded 10a51d0830f80 as 10:A5:1D:08:30:F8 (public)
[00:00:11.112,213] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0004 value 0x0002
[00:00:11.135,528] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0013 value 0x0001
[00:00:11.158,874] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0024 value 0x0001
[00:00:11.182,189] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x0028 value 0x0001
[00:00:11.205,535] <dbg> bt_gatt: ccc_set: Read CCC: handle 0x002c value 0x0001
[00:00:11.228,881] <dbg> bt_gatt: ccc_load: Restoring CCC: handle 0x0004 value 0x0002
[00:00:11.252,807] <dbg> bt_gatt: ccc_load: Restoring CCC: handle 0x0013 value 0x0001
[00:00:11.276,733] <dbg> bt_gatt: ccc_load: Restoring CCC: handle 0x0024 value 0x0001
[00:00:11.300,628] <dbg> bt_gatt: ccc_load: Restoring CCC: handle 0x0028 value 0x0001
[00:00:11.324,523] <dbg> bt_gatt: ccc_load: Restoring CCC: handle 0x002c value 0x0001
[00:00:11.348,541] <dbg> bt_gatt: ccc_set: Restored CCC for id:0 addr:10:A5:1D:08:30:F8 (public)
[00:00:11.373,413] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/ccc/10a51d0830f80
[00:00:11.399,353] <dbg> bt_settings: bt_settings_decode_key: Decoded 10a51d0830f80 as 10:A5:1D:08:30:F8 (public)
[00:00:11.425,903] <dbg> bt_gatt: find_sc_cfg: id: 0, addr: 10:A5:1D:08:30:F8 (public)
[00:00:11.449,981] <dbg> bt_gatt: find_sc_cfg: id: 0, addr: 00:00:00:00:00:00 (public)
[00:00:11.474,182] <dbg> bt_gatt: sc_set: Read SC: len 4
[00:00:11.495,544] <dbg> bt_gatt: sc_set: Restored SC for 10:A5:1D:08:30:F8 (public)
[00:00:11.519,317] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/sc/10a51d0830f80
[00:00:11.545,288] <dbg> bt_gatt: db_hash_set: Stored Hash:
89 fc 9b 50 41 66 fc 4d bb 6d 6c b2 3c 2c d7 e2 |...PAf.M .ml.<,..
[00:00:11.576,690] <dbg> settings: settings_call_set_handler: set-value OK. key: bt/hash

As a result of foreach command (I have added extra log there):

[00:00:12.751,403] <dbg> bt_keys: bt_foreach_bond: bonded (nil) 0 id 0

        struct bt_keys *keys = &key_pool[i];
        BT_DBG("bonded %p %d id %d",keys->keys,i, keys->id);
Can you please help me to identify why restored keys are not found by foreach command?

Dominik,

RE: Concurrent usage of NV and settings on the same partition

Simon — Wed, 06 Jul 2022 09:08:35 GMT

I asked internally about this, if the bonding and custom data can use the same partition.

It is possible to use the same NVS instance for custom data. I can refer you to zephyr/subsys/settings/include/settings/settings_nvs.h. The backend is using id starting from NVS_NAMECNT_ID (0x8000) till the maximum nvs' id value. All Id's below 0x8000 are available for custom usage currently.

Best regards,

Simon

RE: Concurrent usage of NV and settings on the same partition

DominikRekawek — Tue, 05 Jul 2022 12:46:23 GMT

Some updates:

Initializing and storing NV on the same partition, after settings have been loaded is causing sittuation where BLE/Settings is not storing new boundings in flash anymore. Also settings_save is not helping here.

Let's change a question here to following one: is this usecase possible from architectural point of view or settings and NV access should use separate partitions.

RE: Concurrent usage of NV and settings on the same partition

Simon — Thu, 30 Jun 2022 13:12:09 GMT

Hello Dominik,

I'll take a look at this today/Monday

Best regards,

Simon