-
Notifications
You must be signed in to change notification settings - Fork 13.3k
EEPROM unstable again #279
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
Suggested change: bool EEPROMClass::end()
} |
And to my problem: It seems that
never gives SPI_FLASH_RESULT_OK, so COMMIT is never written.... |
Which flash size do you select from the Tools menu?
|
all. :-) First the 4M that fits my esp-12, then rolled back to 512k (first on). Both don't work. I just rolled back to old version, everything is good again. So I'm not insane... :-) |
My EEPROM code no longer works. (Using the build using boards manager, and the latest 1.6.4 i think arduino ide..) I've been using the same code for all versions, to write SSID, IPs for MQTT, device name, states of various variables etc and never had a problem. This latest code saves nothing, every reboot it is gone. here is a dump of my EEPROM before saving anything
dump of my serial shows that the info has been received, and saved to EEPROM...
here is a dump of the EEPROM after save (interestingly it has in it contents of wifi networks surrounding me... this does not seem right... is this now heap space? my stuff is written to EEPROM, the ? are buffer characters i use to overwrite the old contents...
here is a dump after reboot.... ok... it saved the details... now I'm confused... I did this twice and each time on reboot none of the saved info... name, access point, password were retrieved... now it has worked... quite why the EEPROM is full of the access points from around me, is weird... i may have a bug somewhere... this is new behaviour though, did not see this with previous side versions. |
I've made another discovery. You need to power cycle the ESP.. it looks to me like things are over written on power cycle... my esp gives me an EEPROM dump that looks ok, but reboot it by removing power, not just with the reset... and boom its all gone. mine gets replaced by gibberish, and what look like variables from an array of nearby access points... heres what it looks like before...
Power cycle... then....
I'm definitely calling commit.. this has been working flawlessly up until now. |
This was an easy one: |
Current EEPROM looks good. Write works, survives Reset and Powerdown, so at least on my side it seems a winner. Thank you! |
Mine is still not working! done git pull, compiled the latest version using ant dist. Flashed to node-mcu... |
Which memory config did you try? On Thu, May 21, 2015 at 8:02 PM, sticilface [email protected]
|
the 512K, 64K SPIFFS.... however that is correct for my module. when i get flash size it is 512K |
If i load the EEPROM.clear sketch then the EEPROM.read it is still full of numbers, not 0s... so it is not my sketch doing it! |
In my understanding, 512k should work on all platforms... I did a Arduino 1.6.4-IDE download (arduino cc) and then via Config/JSON/Boardthingy. Worked. |
now if i use the write sketch example, I changed it to write 41 to all address... it still fails.. on reboot i get random numbers. The curious thing is that when i dump my main sketch EEPROM it is full of local AP... this is happening because a variable from my sketch is over writing the EEPROM area of memory, i.e. part of heap? I mean at no point to i write the array containing the local wifi stations to EEPROM? I should add that this happens with my ESP-12 as well, so its not just a node thing. And my sketches compile and store values just fine if i roll back to pre-spiffs. |
What is interesting is if i compile with a pre-SPIFFS version ( the one where the EEPROM works), |
@sticilface just a word of warning — if you have the board manager package installed in your system, and then run the compiled version, the board manager package will take precedence over the version of the core bundled with the compiled version. So if you compile anything, be sure to delete the package installed via the board manager. Older versions were 1.6.1 so they are not affected by the core installed via board manager. |
Ah. I thought that might be the case. I saw some debug lines that suggested Cheers On Thursday, May 21, 2015, Ivan Grokhotkov [email protected] wrote:
|
I had a problem saving to EEPROM, it was losing its content at every reboot and every byte of its storage was reset to 0xFF. I solved this problem by clearing its content before I upload the main sketch. Now it seems working fine. I don't know what was causing that behaviour. |
Version ? Mb used ? ota ? is a bitt generic
|
I had same problem. Using this bellow sketch, has reporting a wrong size: Then i cleaned the EEPROM and works
|
I really, really don't understand what goes wrong.
My simple test program write/reads the EEPROM and results are simply strange.... Program first:
include <EEPROM.h>
void setup()
{
// initialize serial and wait for port to open:
Serial.begin(115200);
delay(5000);
test();
}
void DumpEEpromdata(String msg) {
EEPROM.begin(500);
Serial.println();
Serial.println(msg);
Serial.println();
for (int i = 0; i < 240; i++) {
yield();
byte p = EEPROM.read(i);
}
yield();
EEPROM.end();
Serial.println();
Serial.println();
}
void test(void) {
DumpEEpromdata("Test0");
EEPROM.begin(500);
for (int i=0;i<10;i++) {
EEPROM.write(i+20,i);
}
EEPROM.end();
DumpEEpromdata("Test1");
EEPROM.begin(512);
for (int i=0;i<10;i++) {
Serial.print(EEPROM.read(i+20));
Serial.print(" ");
}
EEPROM.end();
DumpEEpromdata("Test2");
EEPROM.begin(512);
for (int i=0;i<10;i++) {
Serial.print(EEPROM.read(i+20));
Serial.print(" ");
}
EEPROM.end();
DumpEEpromdata("Test3");
}
void loop()
{
delay(100);
}
And here the result for the first two tests, only first lines displayed:
Test0
D6 4C D2 F2 FA 25 46 8C 75 B0 3B 70 9E CA B0 C3
D6 A0 19 E3 15 DF 1F 76 8A 87 4E 7F FD B3 D4 03
Test1
04 05 06 07 08 09 46 8C 75 B0 3B 70 9E CA B0 C3
D6 A0 19 E3 15 DF 1F 76 8A 87 4E 7F FD B3 D4 03
If I reboot I get:
Test0
D6 4C D2 F2 FA 25 46 8C 75 B0 3B 70 9E CA B0 C3
D6 A0 19 E3 15 DF 1F 76 8A 87 4E 7F FD B3 D4 03
Both results (first: wrong positions of bytes, second; data gone after reboot) is so wrong on so many levels... Am I crazy or made a stupid error?
The text was updated successfully, but these errors were encountered: