I made an example based on the NVS sample code (Connect SDK 2.2.0) which simply reads a value from the storage partition if it exists, then updates it if either it's different than a specific value or it didn't exist in the first place. That works great.
But what I noticed is that, at least using Visual Studio Code, when I flash a new application (or even the same application) it clears the data in the storage partition, which I did not expect. So my question is about the best practice in using the NVS module for storage of device specific parameters for deployment.
The objective is that I would like to have a set of configuration parameters stored in the flash of specific devices that store some parameters (e.g., BLE name, IMU calibration, etc) that can be read in through the NVS module and won't get overwritten by a firmware flash. (The less-than-desirable alternative is an easy way to define an NVS-readable storage hex that can be merged in the flash, per-device). My original thought is that I could simply flash an application to set the flash parameters "permanently" (they don't change even with firmware updates) then flash my application, but as mentioned this doesn't work at least through the default VSCode workflow.
I've read a few mentions in passing on the forums of others indicating adding a device-specific hex file to be merged in whenever flashed. This is definitely less desirable because it doesn't seem obviously supported through VSCode in any way, it'll be more cumbersome to keep track of which calibration files to merge when flashing multiple devices, and there's no immediately obvious way I see to take advantage of the NVS storage format in a custom-spun hex dump.
Does anyone have recommendations on a reasonable way to handle this use case?
