-
Notifications
You must be signed in to change notification settings - Fork 7.7k
This issue has been moved to a discussionGo to the discussion
Closed
Labels
Resolution: Unable to reproduceWith given information issue is unable to reproduceWith given information issue is unable to reproduce
Description
Board
ESP32
Device Description
ESP32 Devkit
Hardware Configuration
No Hardware Configuration, only reading Internal Flash EEPROM.
Version
v3.2.0
IDE Name
Arduino IDE
Operating System
Windows 11
Flash frequency
80MHz
PSRAM enabled
no
Upload speed
921600
Description
In SDK version v3.2.0, the EEPROM.begin() function intermittently fails when called after a device reboot. This behavior does not occur in SDK v1.0.6, where EEPROM.begin() works reliably under the same conditions.
Sketch
#include <EEPROM.h>
#define EEPROM_SIZE 4000
void setup() {
Serial.begin(115200);
if (!EEPROM.begin(EEPROM_SIZE)) {
Serial.println("EEPROM.begin() FAILED!");
} else {
Serial.println("EEPROM.begin() succeeded.");
}
}
void loop() {
ESP.restart(); // Reboot the device to observe if EEPROM.begin fails after reboot
}
Debug Message
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
EEPROM.begin() FAILED!
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
EEPROM.begin() succeeded.
and so on...
Other Steps to Reproduce
Run This is both SDK 3.2.0, and SDK 1.6.0
I have checked existing issues, online documentation and the Troubleshooting Guide
- I confirm I have checked existing issues, online documentation and Troubleshooting guide.To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Metadata
Metadata
Assignees
Labels
Resolution: Unable to reproduceWith given information issue is unable to reproduceWith given information issue is unable to reproduce
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
lbernstone commentedon Jun 4, 2025
Please set core debug level to verbose and flash the firmware again. Post the detailed log. This should show the reason for the failure.
SuGlider commentedon Jun 5, 2025
I can't reproduce it. I have run it over 10,000 times with no failure - using Arduino Core 3.2.0 and ESP32 Dev kit.
It shall be some Flash failure in the board used for testing.
In order to test this issue, I have modified the sketch to show me how many time it has restated, if it has failed (including an LED to show me the status).
You can try it as well...
mightChamp commentedon Jun 6, 2025
We encountered another EEPROM-related issue:
Initially, data is read from EEPROM into a structure variable (not a pointer, so the data is copied into structure variable). The values are correct at first. However, after some time, the parameter values within the structure become incorrect, even though the structure is neither modified nor re-read. Strangely, the correct values eventually reappear without any further access or changes.
Its very rare to generate issue, From 100 of devices, we get issue in 3 device.
Jason2866 commentedon Jun 6, 2025
So this 3 devices are faulty.
SuGlider commentedon Jun 6, 2025
EEPROM Library simulates EEPROM functionality over regular Flash space for storing data.
Flash memory may wear out along time and fail.
Please note that EEPROM Arduino Library is deprecated as stated here: https://github.com/espressif/arduino-esp32/tree/master/libraries/EEPROM
There are other libraries that may help better with the wear out issue, such as LittleFS or FatFS.
Dynamic wear leveling - littlefs is designed with flash in mind, and provides wear leveling over dynamic blocks. Additionally, littlefs can detect bad blocks and work around them. Bounded RAM/ROM - littlefs is designed to work with a small amount of memory.
ESP IDF also has support to Wear Leveling:
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/storage/wear-levelling.html
Example: https://github.com/espressif/esp-idf/tree/v5.4.1/examples/storage/wear_levelling
lbernstone commentedon Jun 6, 2025
NVS also has wear leveling. But, the default size is only 20k, so there's only 5 sectors to level across. If you are using the flash heavily for NVS (which is not a great design to start with), it would make sense to allocate more space to provide for a longer lifetime of the device.
If you are reading data off the flash, and later find that the data in memory has changed, then you have a real problem. Note that the esp32 is not rated for work in locations subject to gamma radiation 😄 Remember that the esp32 has SMT, so data that might be modified by different cores needs to have gated access.
mightChamp commentedon Jun 7, 2025
@lbernstone Thanks for pointing to
esp32 is not rated for work in locations subject to gamma radiation
Configuration data is stored in flash using the EEPROM library. It is read either during reboot or when a configuration update occurs (typically 2 to 5 times at most). For all other operations, the configuration is maintained in a global structure variable in RAM. The size of this configuration structure is approximately 225 bytes.
The ESP32 is currently operating on a single core. The main logic runs in the loop() function, and any additional tasks—such as LED handling—are also executed on the same core.
However, we are observing a critical issue: after reading configuration data from flash into the structure, the data appears to get altered and auto-corrected unexpectedly during runtime. This is concerning and could potentially indicate memory corruption or environmental interference.
esp32 is not rated for work in locations subject to gamma radiation
This can be an issue, because Our device controls Contactors, and also installed near a Power Transformer.
Questions:
lbernstone commentedon Jun 7, 2025
This forum is for code in this repo. You are now way off topic.
If you need an electrical engineer, I'd recommend you get one with a license.
mightChamp commentedon Jun 9, 2025
@lbernstone Apologies if I seemed off-topic earlier.
What I intended to ask was more about the code-level handling for such situations. Specifically, how can we detect if memory has been corrupted, so that we can take appropriate action in response?
While we can try to mitigate electrical noise through hardware measures, I believe that alone may not be a complete solution. It would be more robust if we also implement software-side safeguards to ensure data integrity and reliability.
SuGlider commentedon Jun 9, 2025
it may be possible to store a binary blob that included some CRC for data integrity verification... This would be a change in the way how data is stored in the NVS. Instead of storing data fields, one by one, it could create a data structure that includes a CRC or something similar as a binary blob into the NVS.
lbernstone commentedon Jun 9, 2025
You could also use the last 4 or 8 bytes of your EEPROM to store a checksum of the rest of the content and verify on every read. That would be a pretty easy mod to the library. If you want to go full NASA, then make another nvs partition on the flash, and double-write everything (in addition to the checksum).