-
Notifications
You must be signed in to change notification settings - Fork 13.3k
eeprom no longuer working since 2.5.1 #6551
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for the detailed description and MCVE. Please try with GIT head. EEPROM just had a few changes applied to it which fixed some issues with its calculated address. The test you gave shows the correct behavior during runtime and after a reboot with git head:
|
I have downloaded the latest git version using this doc https://arduino-esp8266.readthedocs.io/en/latest/installing.html.
reboot
|
I think you have some other problem, unfortunately. In #6531 @liebman and others saw the EEPROM location was moved vs. prior versions, but it was working for them (once they rewrote it). So it may be a HW problem with your specific board or a SW one that others don't seem to be having. What is the exact board and options used in the IDE? Can you enable full debug output and rerun? Do SPIFFS examples work and preserve data after a reboot? |
Also, what is the flash chip on your board? There are known issues with PUYA flash requiring a special define in the code to make them work, since they're out of spec. This might be the same thing. A quickie test would be to make |
Sorry, but I've the exact same setup (wemos d1 mini, 4MB, no spiffs, 80mhz) and not able to reproduce this with your test. On reboot I get the random values written before the reboot, always. Do you have any other EEPROM libs in your path? Full verbose build output would help check. What it looks like to me is that there's some simulated EEPROM that's just using a bit of RAM (hence the reset to 0) and never actually writing to your flash. If the flash itself had issues, sketch upload would be problematic. Unless someone else can hit it, there's nothing we can do. The actual flash writing routines are from the SDK, not our code, and EEPROM itself is a very simple library. |
Is that correct for your board? Most Wemos D1 today are r2. |
@viknet365 , my mistake. @devyte was asking you to double-check your board. It should probably be |
hello, it is this kind of board: |
Well, there you go. According to the DOCS, it only has 2MB, not 4MB. Try fixing your flash size to 2MB and see if you're still out of luck... ...snip...
Also, check the flash speed in The docs imply the flash only supports the slowest, 26MHz mode. Uploading with esptool.py may auto-slowdown and work, but flash ops on-chip might not if your menu selection is at 40MHz.
And boards.txt: Lines 4160 to 4162 in 244dbd7
|
Yes it is now working if I use a generic ESP8266 board with 2MB or less memory. Because new implementation ( since 2.5.1) is a bit more "sensitive" maybe some safeguards could be added (if possible) to check that memory defined really exist. Sketch that give memory info such as the one here: Maybe one line in the github release explaining that mismatched memory option will no longer work could also be usefull. |
Add debug printouts when EEPROM calls fail, even if the API doesn't allow returning a success/failure code. Adds error checking to the example to make it explicit that when you call EEPROM::commit(), you need to look at the result code in your code. Fixes esp8266#6551 , or would fix it if there was error checking in the MCVE.
* Add EEPROM debug printouts, error check to example Add debug printouts when EEPROM calls fail, even if the API doesn't allow returning a success/failure code. Adds error checking to the example to make it explicit that when you call EEPROM::commit(), you need to look at the result code in your code. Fixes #6551 , or would fix it if there was error checking in the MCVE. * Clarify example error message
* add fixes from esp8266#6551 (comment) * add flashfreq_26 to the macro list
* add fixes from esp8266#6551 (comment) * add flashfreq_26 to the macro list
* add fixes from esp8266#6551 (comment) * add flashfreq_26 to the macro list
* add fixes from esp8266#6551 (comment) * add flashfreq_26 to the macro list
* add fixes from esp8266#6551 (comment) * add flashfreq_26 to the macro list
* add fixes from #6551 (comment) * add flashfreq_26 to the macro list
* add fixes from esp8266#6551 (comment) * add flashfreq_26 to the macro list
----------------------------- Delete above -----------------------------
Basic Infos
Platform
Settings in IDE
Problem Description
The eeprom.read functions no longer work on my board with my IDE since 2.5.1
it works if using core 2.5.0.
The following sketch read eeprom (emulated eeprom), then write random data to it. and commit at the end.
The sketch read 0 if compiled with core 2.5.1 and later
the sketch dump correct eeprom value if run with core 2.5.0
Other project using eeprom no longuer work either (in my environment).
MCVE Sketch
Debug Messages
reboot arduino
recompile using 2.5.0
The text was updated successfully, but these errors were encountered: