ESP32 Forum

Hello,

I am looking forward to designing a product to run on an ESP32. So far I like what I have seen and found out via research, however, I'm having a bit of trouble finding simple answers to a few relatively simple questions. I have done some research, but keep coming up with technical documentation that provides deep details but simple answers to my simple questions. So please be nice! If you would include links/references to the parts of the documentation that have these clear answers (if available) will help me find these types of answers in the future for myself.

Project Scenario:
I would like to store a relatively simple data structure (made of ints and strings) in non-volatile memory to be retained over any and all power cycles, power failures and resets. It would be ideal if I could store the data structure as-is (so using the NVS library is non-ideal, although technically doable). The data structure is expected to be changed infrequently, on the order of an average of once per week for the lifetime of the product (2-6 years). I expect to develop in C/C++ on Eclipse.

Memory Questions:
1) How much non-volatile memory is available to me to use for storage on the "No embedded flash" versions of the ESP32? (I recognize that the versions with 2mb of embedded flash will have 2mb, of course)
2) Where is this stored? I reviewed the documentation and saw the partitioning, as well as the ROM/RAM/RTC Fast/Slow distribution. If this answer is complex, please give a 30,000 foot overview.
3) Can I use NVM, FAT and SPIFFS to access this area, or are only some of these methods supported/recommended?
4) What is the expected write lifetime of this memory? I have seen multiple answers anywhere from 10k to 100k writes proposed on this forum.
5) Do the provided NVS, FAT, and SPIFFS libraries/functions all automatically use wear leveling, or does it need to be explicitly invoked in code using the wear leveling API? In this case, can NVS even use wear leveling? I have seen conflicting answers to this question on the forum.
6) Will keeping this type of storage impact the ability to do an over the air firmware update?

Other Questions:
1) Are these assumptions correct: The RTC contains the system for managing low power modes, including an actual Real Time Clock. All storage in the RTC is volatile and will be lost upon power failure.
2) Can a battery easily be added to the RTC block to maintain both real time clock and RTC memory in case of a primary power failure?

Thats all I can think of at the moment. I may return with more questions.

Thank you all very much for your help and patience!

If your ESP32 has no embedded flash, you will need to add external flash to the chip to store your program in (or use a module that already has that chip built-in). NVS will use an (user-definable) part of this flash as storage. You're free to mix NVM, FAT and SPIFFS in your project, but as they're all different technologies, they all need to use a different part (partition, to be exact) of the flash. You can't write data using NVS, then read it back using FAT.
The lifetime of the flash chip depends on the flash chip as well as how you use it. Chip manufacturers usually indeed specify 10K to 100K erases per sector; the amount of erases per sector that will happen in real life depend on which technology you use (flash, nvs, spiffs) and how you use it. All three options, when used in ESP-IDF, have underlying wear level algorithms, so none should prematurely burn through your erase cycles, but again, it depends on how you use them.
OTA updates usually are written to a separate partition from NVS/SPIFFS/FAT (unless you specifically also update all data in those partitions) and isn't really affected by the use of the rest of the flash.

On the RTC: Yes, it does contains a real-time clock (actually, more accurately, a real-time counter, but ESP-IDF allows you to use it as a clock) as well as the sleep logic. Unfortunately, in the ESP32 there is no way to allow an external power source (e.g. a battery) to only keep powering the RTC.

(adding to the ESP_Sprite's comment above)

AsYouWishEngineer wrote: 2) Where is this stored? I reviewed the documentation and saw the partitioning, as well as the ROM/RAM/RTC Fast/Slow distribution.

NVS library stores data in flash memory. Typically ESP32 based modules contain 4MB or more of flash memory(link), which is used for the software itself, NVS, and other data. Since you mention "a relatively simple data structure", I assume that the default 24kB size of NVS paritition will be sufficient. If you need to increase this, you can do so via a custom paritition table (link).

AsYouWishEngineer wrote: 3) Can I use NVM, FAT and SPIFFS to access this area, or are only some of these methods supported/recommended?

Yes, flash memory can be used by NVS, FATFS, SPIFFS libraries. Relevant examples are in examples/storage directory of ESP-IDF.

AsYouWishEngineer wrote: 4) What is the expected write lifetime of this memory? I have seen multiple answers anywhere from 10k to 100k writes proposed on this forum.

Yes, 100k erase cycles is a typical value. Note that NVS cycles writes across multiple sectors, so 100k erase cycles might be equivalent to N * 100k NVS write operations, where N would be the ratio of the amount of free space in NVS to the size of your data structure in NVS. For example, assume that NVS partition size is 6 pages (=6 4kB sectors in Flash), 2 of which are filled with other data, 3 pages available, and 1 spare page required for NVS operation. Your data structure is 320 bytes long. In NVS it will occupy 352 bytes due to extra header. Each NVS page can hold up to 11 copies (versions) of this 352-byte data structure. So with 4 empty pages, it will take 11*4=44 write operations to generate one erase cycle per page. Therefore it will take 44 * 100k write operations to wear out these sectors of flash.

AsYouWishEngineer wrote: 5) Do the provided NVS, FAT, and SPIFFS libraries/functions all automatically use wear leveling, or does it need to be explicitly invoked in code using the wear leveling API? In this case, can NVS even use wear leveling? I have seen conflicting answers to this question on the forum.

NVS design results in certain amount of wear levelling. It is not as comprehensive as what NAND flash controllers can do, but as explained above can result in significant extension of flash life time, compared to raw flash write operations.

In ESP-IDF, FAT filesystem can be used either on top of a wear levelling library (in read/write mode), or without it (in read only mode).

SPIFFS also has wear levelling as part of its design, so doesn't need an extra wear levelling layer.

AsYouWishEngineer wrote: 6) Will keeping this type of storage impact the ability to do an over the air firmware update?

NVS format is forward-compatible, i.e. newer firmware versions will be able to load NVS partitions generated with older firmware. However if you plan to do roll back or factory reset, you may need to wipe the contents of NVS if the format changes.

Thank you both very much! This cleared up all of my questions. I really appreciate it!