EEPROM location was changed

[byq13]

In the thirst place I have update to v2.5.2 and it was working ok, but when I have downloaded the newest branch from GIT, then I have discovered problem with EEPROM.
In the newest branch EEPROM location was changed.
My problem is that I have put authentication key there. Now I have to have access to it.

EEPROM function is working fine. In v2.52 and with the newest. It is just not the same part of the flash memory.

How can I have access to old EEPROM location with the newest Arduino framework from GIT?

ESP-12S with 4MB, - 4M2M=4MB (FS:2MB OTA:~1019KB)

[d-a-v]

Current eeprom location:

(((uint32_t)&_FS_end - 0x40200000) / SPI_FLASH_SEC_SIZE)

Arduino/libraries/EEPROM/EEPROM.cpp

Line 44 in 5d609fd

: _sector((((uint32_t)&_FS_end - 0x40200000) / SPI_FLASH_SEC_SIZE))

_FS_end in current master:

Arduino/tools/sdk/ld/eagle.flash.4m2m.ld

Line 18 in 5d609fd

PROVIDE ( _FS_end = 0x405FA000 );

In 2.5.2:

Arduino/tools/sdk/ld/eagle.flash.4m2m.ld

Line 18 in 8b899c1

PROVIDE ( _SPIFFS_end = 0x405FB000 );

By calliing EEPROM.begin((((uint32_t)0x405FB000 - 0x40200000) / SPI_FLASH_SEC_SIZE), you might recover what you had in 2.5.2.
You would then need to close and EEPROM.begin() again to save it to the new location.

Sorry for this change, it should be documented for next release.

[d-a-v]

You can also try to add 4096 to the offset of your data, without calling .begin(newaddress) like above.

[byq13]

Working. Thank you.
I would like to stay with old data in its place.

For what old address will be reserved in next framework version?
OLD eeprom @0x405FB000 (4KB)
NOW: _FS_end = 0x405FA000 -> EEPROM = 8KB.

[d-a-v]

It should not change anymore.
It was changed because of an oddness in flash mapping (#5989).

[byq13]

May I assume, that now we have 8 KB of EEPROM?
Or EEPROM will be on the end of FS and on old EEPROM space will be something else?
At the moment is noones land.

Many thanks for help. It is working perfectly.

[devyte]

@byq13 #5989 addressed a bug in the calculation of the SPIFFS end address. In a cormer case, it could theoretically corrupt the filesystem. I now realize the fix shifts the location of tbe EEPROM, so after an update the EEPROM data wouldn't be seen by the class.
What you may want to do is copy the EEPROM data from the old address to the new correct address. This would need to be done only once, and only when updating from before that fix to after the fix.

Notes:
-retro-mark #5989 as breaking and include the above description on how to address it.
-size of eeprom doesn't change, stays at 4KB

[earlephilhower]

For 2.6, I'll fix the EEPROM sector to point back to the same address as it was, by making boards.txt.py calculate it using the old (busted) formula and removing the implicit calculation in eeprom.cpp. This will make EEPROM backwards compat w/o any changes for users. For 3.0 we may move it to the last sector after the FS, but IMO that's probably not worth the trouble and breakage.

[liebman]

@earlephilhower If this was in 2.5.2 maybe a config option? Someone who has built with 2.5.2 may have the same issue if you change the calculation back...... never mind - it looks to be post 2.5.2

[earlephilhower]

Thanks for checking that. This bug report was very timely and caught a subtle problem!