About the NVS Partition Generator (IDFGH-14513) #15279
Assignees
Labels
Status: In Progress
Work is in progress
Comments
github-actions
bot
changed the title
|
@adokitkat care to chime in? |
espressif-bot
assigned pacucha42, rrtandler and adokitkat and unassigned pacucha42 and rrtandler
|
Hello, thank you both for the report. I will be taking a look at it this week. It doesn't seem to affect the NVS when it is loaded by ESP-IDF from what I know, that's why it was in lower priority. Also minimum (not recommended) partition size should be |
espressif-bot
added
Status: In Progress
|
Hi, |
|
Just a note, the main use case for NVS partition generator is to create partitions with factory-programmed data or settings. Such factory settings partitions typically should never be written to, since if the partition gets corrupted, factory data may be lost. Therefore we weren't carefully testing this scenario when the generated NVS partition is further written to. And as @adokitkat mentioned, this bug didn't affect the case when the partition is read-only. |
|
I understand that point of view, but factory settings may also be just a set of default values which can be changed by user. Thanks PS the partition still may be corrupted, because data can be altered, only problem is the empty pages are not usable |
|
No, this is a bug in Python implementation of NVS partition generator and will be fixed. |
Regardless of fixing this bug I think this (keeping values changed by the user in a separate partition) would be much more robust. If the partition gets corrupted, the device can still be factory reset and will maintain at least the factory defaults. If you start modifying the factory-programmed data directly, you risk not being able to recover the defaults should the partition get corrupted. |
|
And now i understand why there was no response in my issue for 2 months. |
|
I modified I think it doesn't matter much because it should still be able to use the unavailable free space in the first page when all other pages will be full in reality, it should move the content to another empty page making it active, while erasing the first full page - as you can see the 2nd page is now page 6 and properly used. It is still a bug but it doesn't seem to affect the real capacity, that's why I said it was lower priority. NVS tool output |
|
@adokitkat glad that got cleared up. But I didn't get the question about the minimum size. Was it rhetorical? @igrr Interesting. My use case is both to provide defaults as well as factory data, all on the same partition to avoid waste, without much concern for reliability beyond the physical one of the flash itself, which the wear leveling is supposed to mitigate the risks of. This leads me to several questions: how effective is the wear leveling? And now that your brought it up, what else could cause NVS partitions to get corrupted? If possible, how to avoid it? And must partitions be erased when |
|
Sorry, I made a mistake about the size and it isn't 4kiB. It really is 12kiB meaning 0x3000 in hexadecimal, which means 3 pages. |
|
@KaeLL - the minimum NVS partition size answer is driven by the states of NVS pages on initialisation. In regular case, there is typically one page "active", several pages "full" and several pages "free". For correct initialisation, there has to be at least one free page available in the pool of pages. If the power is interrupted during the moment, when the NVS library writes the data and has to "compress" some of full pages, there may be one page temporarily marked as "freeing". This process might be interrupted i.e. by power-loss event. Then, during subsequent initialisation, there would be 2 pages present in states 'active' and 'freeing' and as there is a requirement to have at least one 'free' page, the minimal number of NVS pages is 3. To your question related to the wear levelling - the wear levelling is triggered at the moment, when there are all pages except the 2 (one currently active and one deliberately kept free) marked as full.
The typical situation that makes NVS partition corrupted is the unstable power supply during erase or write operation. One of other situations is the use of firmware compiled with the NVS library code not understanding the newer NVS version i.e. the fallback to original firmware during the OTA, after the new firmware already did some changes in the NVS parition. That might explain, why we allow to specify the NVS version in the NVS partition generator and why we recommend to use the factory defaults in the R/O partition. |
|
Thanks for the answers and explanation, @rrtandler. I'm not acquainted enough with storage systems to fully grasp your explanation, but I think I got the gist of it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Why is the minimum partition size 12KiB? And given the following csv
With K pages, why are pages [1,K - 1] generated with status Full even though they're empty?
Demonstration below
After running
nvs_partition_gen.py generate nvs.csv nvs.bin 32768...nvs_tool.py -i -f text nvs.bin
Pages 1 to 6 statuses is Full.
The text was updated successfully, but these errors were encountered: