Global EEPROM instance always returns 0

[LexNastin]

Board

ESP32 Dev Module

Device Description

N/A

Hardware Configuration

N/A

Version

v2.0.1

IDE Name

Arduino IDE

Operating System

Windows 11

Flash frequency

N/A

PSRAM enabled

no

Upload speed

115200

Description

Expected Behaviour

After running EEPROM.begin(2048) on the global EEPROM instance, EEPROM.length() should return 2048

Current Behaviour

After running EEPROM.begin(2048) on the global EEPROM instance, EEPROM.length() returns 0

Sketch

N/A

Debug Message

N/A

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[VojtechBartoska]

Hello, can you please retest this on v2.0.3-rc1?

[LexNastin]

I am not currently sure where my second test ESP is, so can't it test at the moment. When I find it I will try it out

[VojtechBartoska]

Thank you!

[VojtechBartoska]

Any news on this?

[LexNastin]

Oh shit sorry, I couldn't find my ESP so I didn't end up testing. Sorry...

[UnicodeMan]

Hi. I tested this today with platformIO, pressed update all (updating both libraries and boards, but the result is still that EEPROM returns 0 when used outside in other classes and such. In other words, behaviour is still not global.

Oh wait! Actually, adding EEPROM.begin(4096) in setup() screws up my serial lcd output. EDIT: its cpu panic
Could this be a clue as to what is happening here?

EndeavourOS (arch-Linux based distribution), Linux 5.17.5.

[lbernstone]

@UnicodeMan Are you testing the result of EEPROM.begin()? If it fails to initialize (perhaps your nvs partition is full), then length will still be 0. Setting the EEPROM length is one of the last things done in the begin function.

[UnicodeMan]

I tested the result. EEPROM.begin(4096) returns 1. EEPROM.length(), however, returns 0.
Im not sure about NVS partition being full or not, I reduced compiled binary by removing BT dependency, so its ~282kBytes.
If there are any specific instructions about checking whether nvs partition is being used by the program (or being used some other way), I'd be happy to cooperate and test it again.

[UnicodeMan]

Seeing as EEPROM is deprecated on ESP32, I decided to use Preferences library. It works great. So anyone having issues with EEPROM should consider migrating to Preferences (though I see why EEPROM is still used).

[LexNastin]

Seeing as EEPROM is deprecated on ESP32, I decided to use Preferences library. It works great. So anyone having issues with EEPROM should consider migrating to Preferences (though I see why EEPROM is still used).

Interesting. The reason I'm using it is because I tried to port over a project for the ESP8266 and got it working, but nothing would persist a restart. I just added lots of Serial.print statements to find what the culprit was in the saving code and it came down to this. Seeing as it wasn't any sort of dynamic number, I hardcoded the expected length, but a fix to the EEPROM library would be useful nonetheless.

[UnicodeMan]

Nevermind, same issue. It doesn't save the values.

Seeing as EEPROM is deprecated on ESP32, I decided to use Preferences library. It works great. So anyone having issues with EEPROM should consider migrating to Preferences (though I see why EEPROM is still used).

[lbernstone]

Checking the nvs status is more difficult than just erasing it. Open a command prompt and find esptool (usually %userdata%/Arduino15/packages/esp32/tools/esptool/) and run esptool erase_flash. That will wipe you whole device, and then you can upload your firmware again. If that fixes Preferences, then please test EEPROM again.

[UnicodeMan]

Checking the nvs status is more difficult than just erasing it. Open a command prompt and find esptool (usually %userdata%/Arduino15/packages/esp32/tools/esptool/) and run esptool erase_flash. That will wipe you whole device, and then you can upload your firmware again. If that fixes Preferences, then please test EEPROM again.

did that. behaviour didn't change. Both Preferences and EEPROM libraries don't do what they ought to (they still act with previously mentioned behaviour).

[lbernstone]

Does the StartCounter example work?
Please make sure you have debugging set to verbose to check for any errors.

[UnicodeMan]

Does the StartCounter example work? Please make sure you have debugging set to verbose to check for any errors.

Works fine. Currently at counter value 28 and going up. Debugging set to verbose? Without any external hardware attached? Is there a platformio.ini value to be set for that? I do have some output:
...
rst:0xc (SW_CPU_RESET),boot:0x13 (SPd_FArv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:12776
load:0x40080400,len:3032
entry 0x400805e4

Current counter value: 28
Restarting in 10 seconds...
...

[lbernstone]

build_flags = -DCORE_DEBUG_LEVEL=5

[UnicodeMan]

With flags, example library prints this:
...
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:12776
load:0x40080400,len:3032
entry 0x400805e4
[␀␘␂␂␂��m␑um����2-hal-cpu.c:211] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, APB: 80000000 Hz

Current counter value: 68
Restarting in 10 seconds...
...

Interestingly, with these flags, my project now has problems, when:
ESP32-bluetooth-ArduinoBased.zip

1. I create Preferences object in main.cpp,
2. I pass the object to my library class. Within the library class the Preferences object is defined as a pointer
3. I try to use Preferences as before (with . replaced as ->, in the library, of course)
   The following will cause reboot loop.

...
Rebooting...
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:12776
load:0x40080400,len:3032
entry 0x400805e4
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.

Core 0 register dump:
PC : 0x400d318a PS : 0x00060130 A0 : 0x800d187b A1 : 0x3ffe3b90
A2 : 0x00000000 A3 : 0x3f400175 A4 : 0x00000000 A5 : 0x00000000
A6 : 0x3ffbae98 A7 : 0x00000000 A8 : 0x8008a0d8 A9 : 0x3ffe3b70
A10 : 0x00000000 A11 : 0x00000064 A12 : 0x00000000 A13 : 0x00060123
A14 : 0x00060120 A15 : 0x00000001 SAR : 0x00000018 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000004 LBEG : 0x4008657d LEND : 0x4008658d LCOUNT : 0xffffffff

Backtrace:0x400d3187:0x3ffe3b900x400d1878:0x3ffe3bb0 0x400d22ea:0x3ffe3bd0 0x400d275c:0x3ffe3bf0 0x400ddbff:0x3ffe3c10 0x400827d1:0x3ffe3c40 0x400791f2:0x3ffe3c90 |<-CORRUPTED

ELF file SHA256: 0000000000000000

Core 0 register dump:
PC : 0x400d318a PS : 0x00060130 A0 : 0x800d187b A1 : 0x3ffe3b90
A2 : 0x00000000 A3 : 0x3f400175 A4 : 0x00000000 A5 : 0x00000000
A6 : 0x3ffbae98 A7 : 0x00000000 A8 : 0x8008a0d8 A9 : 0x3ffe3b70
A10 : 0x00000000 A11 : 0x00000064 A12 : 0x00000000 A13 : 0x00060123
A14 : 0x00060120 A15 : 0x00000001
...
--- exit ---
(i CTRL-C-ed the serial output)

I am attaching whole project that can be opened as-is in VSCode / VSCode-based applications.
My noob thinking is that there are problems with global variables in some kind library that is causing undefined behaviour.
I license the project with MIT license.
I will try to reproduce the error with way less bloated and less complex project. It should throw same errors when adding preferences abject in seperate library (that is class-based). If it doesn't fail, throwing in LCD_I2C library and using LCD at the same time might be a good idea (good as in making the ESP fail).

[UnicodeMan]

Dismiss previously sent project file, it had a problem because Preferences object was used before it was passed on.
Making it less complex by using the Preferences library in the class only (creating the object in the class). It magically has no problem now. Why? No idea. No global use, I guess.
ESP32-bluetooth-ArduinoBased.zip

[VojtechBartoska]

Can I consider this as solved?

[UnicodeMan]

I think it is better left as open.
Even though EEPROM is deprecated, it's functionality is seriously damaged by the fact it has problems when its used globally. It's still not solved, just stalled.

[lbernstone]

see #6572

[mrengineer7777]

Likely fixed by PR #6910.