Previously, nvs_flash_init_custom would not be called if Storage for a
particular partition was already created. This caused issues if the
first call to nvs_flash_init failed due to Storage init error. This issue
exhibited itself as random failures of NVS CI test.
With this change, storage object is deleted (and not added to storage
list) if initialization fails.
This commit adds support for multiple NVS partitions. This provides application a flexibility to have multiple NVS
partitions such as separate partition with read-only manufacturing data and read-write partition with configuration.
Application can also use this to separate out application's configuration storage from system configuration.
This feature does not change any of the basic property of NVS subsystem. The same-named namespaces across partitions are
considered to be different namespaces. The original NVS API available for the applications remains unchanged. The only
difference is that instead of first NVS partition in the partition table, it now operates on the partition with label
"nvs" (which is default in the IDF provided partition table files). Additional APIs are provided to open a handle and
erase NVS with partition name as a parameter.
A test case is added in the host tests and it is made sure that all the host tests pass. nvs_rw_value app is also tested
with multiple partitions.
Signed-off-by: Amey Inamdar <amey.inamdar@gmail.com>
NVS is used to store PHY calibration data, WiFi configuration, and BT
configuration. Previously BT examples did not call nvs_flash_init,
relying on the fact that it is called during PHY init. However PHY init
did not handle possible NVS initialization errors.
This change moves PHY init procedure into the application, and adds
diagnostic messages to BT config management routines if NVS is not
initialized.
