In SDK v3.2.0, EEPROM.begin() sometimes fails after a reboot(need to call EEPROM.begin() again). This issue doesn't occur in SDK v1.0.6

[mightChamp]

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.

[lbernstone]

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]

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...

#include <EEPROM.h>

#define EEPROM_SIZE 4000
#define LED_PIN 21

RTC_DATA_ATTR int bootCount = 0;
RTC_DATA_ATTR int failureCount = 0;
RTC_DATA_ATTR bool EEPROM_HasFailed = false;

void setup() {
  Serial.begin(115200);
  // just runs in the first time it boots to test the LED
  if (bootCount == 0) {
    pinMode(LED_PIN, OUTPUT);
    digitalWrite(LED_PIN, HIGH);
    delay(1000);
    digitalWrite(LED_PIN, LOW);
  }
  //Increment boot number and print it every reboot
  ++bootCount;
  Serial.println("Boot number: " + String(bootCount) + " || #Failures = " + String(failureCount));

  if (!EEPROM.begin(EEPROM_SIZE)) {
    Serial.println("EEPROM.begin()============================>>>>>>>> FAILED!");
    EEPROM_HasFailed = true;
    failureCount++;
  } else {
    Serial.println("EEPROM.begin() succeeded.");
    delay(150); // just to be able to glance it in the Serial Monitor
  }
  // shows the failure
  if (EEPROM_HasFailed) {
    pinMode(LED_PIN, OUTPUT);
    digitalWrite(LED_PIN, HIGH);
    delay(5000);
  }
  esp_sleep_enable_timer_wakeup(10);
  esp_deep_sleep_start();
  //ESP.restart();  // Reboot the device to observe if EEPROM.begin fails after reboot
}

void loop() {
}

[mightChamp]

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]

So this 3 devices are faulty.

[SuGlider]

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

EEPROM is deprecated. For new applications on ESP32, use Preferences.
EEPROM is provided for backwards compatibility with existing Arduino applications.
EEPROM is implemented using a single blob within NVS, so it is a container within a container.
As such, it is not going to be a high performance storage method.
Preferences will directly use nvs, and store each entry as a single object therein.

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]

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]

@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:

1. Could this environment be causing memory corruption?
2. What steps can we take to safeguard against such interference?