Problem to read back flash with NVS when concurrent use with Bluetooth

[Romain]

Hi,

We need to save 3 strings to flash using NVS. Based on the code sample in zephyr\samples\subsys\nvs we set the initialization and then write and read these data.

To have successful read back we need to make some dummy write to NVS before, else the reading doesn't correspond to the previous written value.

We have done the following observation:

• doing read/write of the NVS before enabling Bluetooth works fine
• doing read/write after enabling Bluetooth retrieves the very first data instead of the last written (and some more strange behaviour)
• the Bluetooth stack is doing a second nvs_init() with larger sector number to fs structure

Our question are the following

• is there more documentation on NVS than the basic developer source ?
• is there any precautions to use "custom" access to NVS at the same time as Bluetooth stack ?
• should we split the storage area for each uses or ID's should be fully managed by Bluetooth stack without any problems ?

We initiate fs with DTS flash controller definition (ex: nRF52833 -> storage begin at 0x7a000)

Config is NCS 1.5.0 or 1.6.0, nRF52840DK

Best regards,

Romain

[Vidar Berg]

Hi,

It sounds like NVS should have plenty of time to complete the write operations then. So the question why CONFIG_BT_GATT_CACHING=n seems to improve the behaviour still remains. Would you be able to share your project so I can try to debug it here (assuming it can run on a nordic DK without too much effort). Otherwise I'll just try to set up a new project.

Edit: have you defined a new flash partition for your NVS instance so there is not any conflict with the NVS instance used by Settings?

e.g.

[Romain]

Hi Vidar,

Vidar Berg said:

have you defined a new flash partition for your NVS instance

No I didn't.

But I am not clear with sectors overlapping on the storage partition which is 32kb. Bluetooth settings defines 8 sectors of 4096b (the whole storage partition as defined in dts), my custom NVS parameters defines 2 (3 in Simon example) sectors of 4096b and you propose to separate NVS to 2x16kb partitions. Could that be really OK ?

[Vidar Berg]

Hi,

Romain said:

you propose to separate NVS to 2x16kb partitions. Could that be really OK ?

This was just an example. Bluetooth settings will allocate 4 sectors with this partitioning. My point is that your NVS instance should not cover the same flash area as the other NVS instance used by Settings.

Romain said:

custom NVS parameters defines 2 (3 in Simon example) sectors

Are these 2 sectors currently placed in the same partition as Bluetooth settings?

[Romain]

Vidar Berg said:

Are these 2 sectors currently placed in the same partition as Bluetooth settings?

Yes they were...

But I tried your proposal and it seems working fine.
The Bluetooth settings now takes 4 sectors instead of 8.

So your point is that every user NVS data should go in a dedicated partition and the OS NVS data will take place in the original storage partition.

Thank you

[Vidar Berg]

Thanks for the update.

Romain said:

So your point is that every user NVS data should go in a dedicated partition and the OS NVS data will take place in the original storage partition.

I think creating a new storage partition might be the easiest way to ensure separation between the NVS area used by Settings from the NVS area you are using in your application. But it's not the only solution, you could also use the CONFIG_SETTINGS_NVS_SECTOR_COUNT configuration and prevent Settings from allocating the whole partition to itself.