Timeline for Value of uninitialized EEPROM in ESP8266?
Current License: CC BY-SA 4.0
17 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Feb 4, 2019 at 17:01 | history | bumped | Community Bot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Jan 5, 2019 at 16:52 | answer | added | user47164 | timeline score: 1 | |
Jan 3, 2019 at 20:34 | answer | added | JRobert | timeline score: 2 | |
Jan 3, 2019 at 19:53 | answer | added | linhartr22 | timeline score: 0 | |
Dec 30, 2018 at 15:19 | comment | added | Jot | I sure hope so, or else calibration data or a wifi password has to be entered every time. Do they "guarantee" that the values stays there? When you use @Jot, then I get notified. | |
Dec 30, 2018 at 4:47 | comment | added | Llaves | The point is not to tell if a new sketch was uploaded. It's to persist data between reboots. What you suggest, for a different purpose, requires that data persist across a re-flash of the memory. I wrote a quick test program and can verify (that at least for my simple test) the simulated EEPROM does persist across a reflash. This suggests that the device could be "prepared" by running a program that initializes EEPROM to some known value, then the desired program is flashed after that and can depend on a known EEPROM state. | |
Dec 30, 2018 at 4:17 | history | edited | Llaves | CC BY-SA 4.0 |
add use case
|
Dec 29, 2018 at 16:58 | comment | added | Jot | You coud add an identifier and checksum to the data. When a sketch is compiled, it is possible to put the compilation date and time in the sketch with __ DATE __ and __ TIME __ if you check those and store them in eeprom, then you know if a new sketch was uploaded. Please tell us the reason for your question. What problem are you trying to solve? | |
Dec 29, 2018 at 16:41 | comment | added | Gerben | Flash and EEPROM are the same thing in the case of the ESP. I think they always use the same location of the Flash/EEPROM to store the "fake" EEPROM data. | |
Dec 29, 2018 at 16:26 | comment | added | Llaves | @Gerben - the idea of writing a number of values and checking is something I thought about and may try if nobody comes up with an actual solution. As you note, it's not guaranteed, but statistically it's pretty safe (unless the consequences of an error are large, which they are not in my application) | |
Dec 29, 2018 at 16:25 | comment | added | Llaves | @Gerben - the ESP8266 doesn't contain actual EEPROM, it simulates the behavior using flash. Clearing the "EEPROM" with a separate program would fail in this case as the flash memory would be over-written when a new program is flashed. | |
Dec 29, 2018 at 16:24 | comment | added | Gerben | Alternatively; write like 10 constant values to 10 unused locations in the flash. On boot check if those 10 locations contain those 10 constants. If they don't you know you have uninitialized flash. The chance that uninitialized flash contains those 10 constants is pretty slim. | |
Dec 29, 2018 at 16:21 | comment | added | Gerben | Have a separate sketch that clear the EEPROM. Upload that first, run it, then upload your own sketch. | |
Dec 29, 2018 at 14:36 | comment | added | Llaves | @Jot - Barring the use of persistent memory like EEPROM, a program (sketch) is the same every time you run it. How do you propose to "solve this in your sketch" if the goal is to determine if it has every been run since the device was flashed? | |
Dec 29, 2018 at 11:12 | comment | added | Pararera | Just buy I2C EEPROM.. Much better solution | |
Dec 29, 2018 at 10:25 | comment | added | Jot | You have to solve this in your sketch. That's how it should be in the first place. Even with an atmega it is dangerous to rely on the eeprom being all 0xff. When you use an atmega for testing, and forgot about it, the eeprom might no longer be 0xff. This question is the same, according to the rules of stackexchange, I think this question will be closed. | |
Dec 29, 2018 at 5:02 | history | asked | Llaves | CC BY-SA 4.0 |