Function now always rewrites old value under same key
regardless existing data type. Users requiring old API behaviour
can enable it by kconfig option CONFIG_NVS_LEGACY_DUP_KEYS_COMPATIBILITY
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.
spi_flash driver knows how to write data from cache (DROM or PSRAM)
into flash, so the extra check in nvs_flash is unnecessary.
Besides, the hardcoded address limit (0x3ff00000) is wrong for some
of the newer chips.
This fixes the issue where multiline strings and strings with delimiters inside the nvs input csv file were incorrectly parsed, and adds back the ability to add comment lines anywhere in the CSV file.
The issue stems from the move away from the python built in csv module to manual parsing, which was made after moving away from using the csv module to parse mfg data.
This reverts back to using the csv module for parsing and writing csv data in both mfg_gen and nvs_partition_gen, fixes the original issue in mfg_gen and improves code quality which makes the code more readable and maintainable.
Closes https://github.com/espressif/esp-idf/issues/7175
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
