Bootloader, App, & when NVS is not 'Non-Volatile' Storage

genedyne
Posts: 18
Joined: Wed Jun 06, 2018 12:47 pm

Bootloader, App, & when NVS is not 'Non-Volatile' Storage

Postby genedyne » Fri Oct 25, 2019 12:20 pm

I am using a WIFI OTA bootloader to update my application code. My application code stores configuration & calibration information, in the NVS ('NON VOLATILE' Storage). WIFI requires NVS (not sure why, I think I saw something about storing PHY calibration), so the bootloader needs to initialize the NVS module. Initialization of the NVS module will fail if the NVS module determines that the format 'version' of the NVS partition is greater than the version of NVS support code (see ESP_ERR_NVS_NEW_VERSION_FOUND). ESP-IDF example code resolves this condition by wiping (re-initializing) the NVS partition (definitely NOT 'Non-Volatile'!). This means the NVS partition is more like a semi-persistent-scratch-pad. In any event, I'd suggest this issue should be documented (possibly in the programming guide?).

I'm not sure when the version of the NVS partition changed such that was out-of-sync with the NVS module in the booloader. Possibly this occurs when compiling a new version of the app against a new ESP-IDF build (which would include the latest NVS code), and the app then updates some configuration information in the NVS partition. Certainly, if the 'new build' app code finds there is no space to store updated configuration it will re-initialize the nvs partition before re-writing the updated data, and I'd expect this would update the format version.

In terms of resolution, it seems the NVS module code supports using partitions other than the default 'nvs' partition. Is the preferred way to resolve this issue making another partition for my configuration & calibration data, so it can truly be 'persistent'?

Other possibilities:
- Backward- compatability, so that older nvs code can still provide core functionality with new-format nvs partitions, without forcing a complete wipe & re-initialize (which does seem a little draconian).
- some way to mark data in the NVS partition as 'persistent', such that it will survive a re-initialization?
- a different way to 're-initialize' the 'nvs' partition, more like a 'garbage collect' cycle to free-up space.

Who is online

Users browsing this forum: No registered users and 138 guests