Please set core debug level to verbose and flash the firmware again. Post the detailed log. This should show the reason for the failure.

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() {
}

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.

So this 3 devices are faulty.

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

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.

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

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.

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

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

Thank you for the suggestion to use CRC during EEPROM read/write operations — that will definitely help in detecting issues related to EEPROM data integrity.

However, we’re also facing a different issue related to RAM corruption, and I’d appreciate your input on how to handle it.
Here’s a summary of the situation:

1. The entire application runs on a single core of the ESP32.
2. We initialize EEPROM with 4000 bytes using EEPROM.begin(4000)
3. At startup, we read a configuration structure (225 bytes) from EEPROM and store it in a global variable in RAM.
4. This structure is read only once after reboot — we do not access EEPROM again afterward.
5. The structure is then used in various parameter calculations.
6. Initially, everything works correctly — calculations are accurate for the first 5–6 hours.
7. Suddenly, calculations become incorrect, indicating that the structure variable has been corrupted in RAM.
8. We do not modify or update this structure during runtime.
9. Interestingly, after around 10 minutes, the calculations return to normal — suggesting that the structure variable somehow "corrects itself."
10. This hardware has been running fine for 10 days, and this issue has occurred only once.

How can we detect and handle such a case where a global RAM variable gets corrupted and then seemingly recovers, even though we don’t explicitly touch it?