Users of the nvs API are likely to have `nvs_handle_t` in all cases, but
not all of them carry around the partition name and namespace name (as
they aren't needed after creating an `nvs_handle_t`).
Allow this common case to use nvs iteration without them tracking
additional data by using the `nvs_handle_t` to locate the namespace
index and the partition name by introducing an alterate to
`nvs_entry_find` called `nvs_entry_find_in_handle`, which operates
similarly except that it is given a `nvs_handle_t` instead of partition
and namespace strings.
This is somewhat more limited than the `nvs_entry_find` API as one
cannot examine all keys in a given partition.
- This features allows the NVS encryption keys to be derived and protected using
the HMAC peripheral. Since the encryption keys are derived at runtime, they
are not stored anywhere in the flash and hence this feature does not require
a separate `nvs_keys` partition.
Closes https://github.com/espressif/esp-idf/issues/7826
* nvs_entry_find(), nvs_entry_next() and nvs_entry_info()
return error codes now
* nvs_entry_find() and nvs_entry_next() access/modify iterator via
parameters, instead of returning an new iterator.
Added appropriate documentation in Chinese and English
add: private include header
add: macro encapsulation for assertion or error check
add: ESP_FAIL return code documentation in public headers
change: replaced all assertions by NVS_ASSERT_OR_RETURN macro
change: few internal function return values from void to esp_err_t
change: ESP_ERR_NVS_VALUE_TOO_LONG macro comment
The following files have been ported:
* esp_rom_crc.h
* esp_rom_sys.h
* esp_rom_efuse.h (mostly no-ops)
* esp_rom_md5.h
Integrated Linux-based rom implementation into log
and NVS component.
Added brief host tests for ROM to ensure basic
consistency on Linux.
Added ROM printf host unit tests.
Temporarily added reset reason for Linux in ROM.
handling (only when nvs encryption is enabled)
* NVS Encryption will now be turned on by default with flash encryption
* Updated the flash encryption example to shocase NVS encryption
along with information on how to configure and use NVS encryption
* Updated respective test case
* Added two partition tables for NVS encryption
i) Table 1- Single factory app, no OTA, encrypted NVS
ii) Table 2- Factory app, Two OTA, encrypted NVS
* General tests like page loading from flash
* Rough test of fixed-size data types
* Rough test of blob read
* Added coverage target in cmake, also accessible
via `idf.py coverage`
* Fixed unsigned comparison in comp. enum table
* introducing temporary LINUX_TARGET define
* When deinitializing or erasing a partition,
nvs used to close all handles instead of only
the current partition's handles.
This is fixed now
* Added a unit test for that case
Closes FCS-533
* partition api changed from spi_flash* API to
esp_partition* API and is abstracted as a C++
interface.
* The old nvs encryption is still possible
* changed default unit test app partition table
* Partitions coming from esp_partition API are
checked for generic flash encryption. If yes,
an error is returned since generic flash
encryption isn't compatible with nvs
encryption
* esp32, esp32s2 tests don't require nvs_flash
but mbedtls now
Closes IDF-1340
Closes IDF-858
1. separate rom include files and linkscript to esp_rom
2. modefiy "include rom/xxx.h" to "include esp32/rom/xxx.h"
3. Forward compatible
4. update mqtt
Currently, only erase operation performed by the application leads
to detection of NVS key partition as uninitialised. This change
adds additional checks for detecting partition as uninitialised,
when device boots first time right after encryption by bootloader.
Users needs functions to count the number of free and used entries.
1. `nvs_get_stats()` This function return structure of statistic about the uspace NVS.
(Struct: used_entries, free_entries, total_entries and namespace_count)
2. `nvs_get_used_entry_count()` The second function return amount of entries in the namespace (by handler)
3. Added unit tests.
Closes TW<12282>
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.
