ESP32 "#define EEPROM_SIZE"

I have sketch for the ESP32 which has the line #define EEPROM_SIZE 2 and later reads (or writes) one or two digit integers into EEPROM.read(0) - EEPROM.read(4). It seems to work fine. But if I change #define EEPROM_SIZE to, say 10, the sketch crashes after uploading. Two things are confusing me here:

  1. If the #define EEPROM_SIZE 2 means 2 bytes, how come I can write 5 integers into the vitual EEPROM?

  2. Why does the sketch only work with #define EEPROM_SIZE 2

EEPROM.h is deprecated on the ESP32. It's better for you to transition to using Preferences.h instead.
https://forum.arduino.cc/t/eeprom-issues-on-esp32/950863/12

Yes, I realise that, but I would still like to know how eeprom.h works out of:

  1. General interest.
  2. Because older code uses eeprom.h and I would like to know what the code is doing before re-writing it with a different library.

There have been several changes to EEPROM.h to accomodate the move away from reserved memory space for eeprom emulation. What version of the Arduino core for the ESP32 are you using. What version of EEPROM.h is is using?

My guess is that for small values of size, the library may be assigning more space.

Post a minimal example of code which compiles and demonstrates what you see with EEPROM.h and your being able to write more than size.

Are you convinced that the values are indeed stored after a power cycle?

Thanks for taking the time with my problem. Unfortunately it would take me more time than I have at the moment to reduce the code as you requested. However I can say that the error I receive when the eeprom size is not 2 is "Guru Meditation Error: Core 1 panic'ed (LoadStoreError). Exception was unhandled."

The EEPROM.h file may not be aware of the ESP32's memory scheme.

There have been several major revisions of EEPROM.h for the ESP32 and the core version and library used in legacy code is of relevance.

https://github.com/espressif/arduino-esp32/pull/2678

https://github.com/espressif/arduino-esp32/pull/5775

Unravelling the issues with use of a deprecated library is not of any great value given that Preferences.h is pretty simple to use.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.