[GH-ISSUE #242] Does WifiManager suffers EEPROM failures?

kerem commented

2026-02-28 01:23:58 +03:00

Owner

Originally created by @ortegafernando on GitHub (Nov 4, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/242

HI, I am a newbie with ESP8266 (no with Arduino).

I have read this issue https://github.com/esp8266/arduino/issues/1054 about corrupting eeprom after some restarts.

They solve it with Wifi.persistent(false).

I don't know if this library could suffer the same issue, or it already has a method to avoid it (his own way to save and restore settings, .....)

Thanks a lot for your great library.

Originally created by @ortegafernando on GitHub (Nov 4, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/242 HI, I am a newbie with ESP8266 (no with Arduino). I have read this issue [https://github.com/esp8266/arduino/issues/1054](url) about corrupting eeprom after some restarts. They solve it with Wifi.persistent(false). I don't know if this library could suffer the same issue, or it already has a method to avoid it (his own way to save and restore settings, .....) Thanks a lot for your great library.

kerem closed this issue

2026-02-28 01:23:58 +03:00

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@tzapu commented on GitHub (Nov 8, 2016):

hi , wifimanager is made so it doesn't write ssid/pwd each time it starts, it rather uses the previously saved settings by the system
in theory it should't cause anymore corruption than using the esp modules normally
hope this helps
thanks for using it

@tzapu commented on GitHub (Nov 8, 2016): hi , wifimanager is made so it doesn't write ssid/pwd each time it starts, it rather uses the previously saved settings by the system in theory it should't cause anymore corruption than using the esp modules normally hope this helps thanks for using it

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jan 3, 2017):

Hi, I have read again this https://github.com/esp8266/arduino/issues/1054 and seems to be a problem also in this library. I mean, if you call wifi.begin could be a problem.
It is not a real problem of your library, it is from SDK.
As you see here, igrr said about updating examples: https://github.com/esp8266/arduino/issues/1054#issuecomment-158663415
And I have checked several, and all of them have persistent = false.

You can read more about PERSISTENT here: https://github.com/esp8266/Arduino/blob/master/doc/esp8266wifi/generic-class.md that explain this:

"""""
Module is able to reconnect to last used Wi-Fi network on power up or reset basing on settings stored in specific sectors of flash memory. By default these settings are written to flash each time they are used in functions like WiFi.begin(ssid, password). This happens no matter if SSID or password has been actually changed.
This might result in some wear of flash memory depending on how often such functions are called.
Setting persistent to false will get SSID / password written to flash only if currently used values do not match what is already stored in flash.
Please note that functions WiFi.disconnect or WiFi.softAPdisconnect reset currently used SSID / password. If persistent is set to false, then using these functions will not affect SSID / password stored in flash.
To learn more about this functionality, and why it has been introduced, check issue report #1054
""""

What I don't know is why they have defined PERSISTENT's default value as TRUE. I think it will be better for all to use FALSE.

I think that we have to add wifi.persistent(false); in this library. don't we ?

Hope your answer.

NOTE: I will advise also to kentaylor (afterwards .... i don't know how !!!! Excuse me. I am not very used to github)

@ortegafernando commented on GitHub (Jan 3, 2017): Hi, I have read again this https://github.com/esp8266/arduino/issues/1054 and seems to be a problem also in this library. I mean, if you call wifi.begin could be a problem. It is not a real problem of your library, it is from SDK. As you see here, igrr said about updating examples: https://github.com/esp8266/arduino/issues/1054#issuecomment-158663415 And I have checked several, and all of them have persistent = false. You can read more about PERSISTENT here: https://github.com/esp8266/Arduino/blob/master/doc/esp8266wifi/generic-class.md that explain this: """"" Module is able to reconnect to last used Wi-Fi network on power up or reset basing on settings stored in specific sectors of flash memory. By default these settings are written to flash each time they are used in functions like WiFi.begin(ssid, password). This happens no matter if SSID or password has been actually changed. This might result in some wear of flash memory depending on how often such functions are called. Setting persistent to false will get SSID / password written to flash only if currently used values do not match what is already stored in flash. Please note that functions WiFi.disconnect or WiFi.softAPdisconnect reset currently used SSID / password. If persistent is set to false, then using these functions will not affect SSID / password stored in flash. To learn more about this functionality, and why it has been introduced, check issue report #1054 """" What I don't know is why they have defined PERSISTENT's default value as TRUE. I think it will be better for all to use FALSE. I think that we have to add wifi.persistent(false); in this library. don't we ? Hope your answer. NOTE: I will advise also to kentaylor (afterwards .... i don't know how !!!! Excuse me. I am not very used to github)

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@tzapu commented on GitHub (Jan 3, 2017):

hi
this looks fixed though
github.com/esp8266/Arduino@6be74ec95e

cheers
alex

@tzapu commented on GitHub (Jan 3, 2017): hi this looks fixed though https://github.com/esp8266/Arduino/commit/6be74ec95e16d9f64804d90e3d318249e0b65183 cheers alex

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jan 3, 2017):

I think that is a different thing

I think the solution t memory corruption is this:
github.com/esp8266/Arduino@40da463ee6

The default value of PERSISTENT is TRUE, So, as you can see in the commit that I have said, for example:

if (_persistent)
wifi_station_set_config(&conf);
else
wifi_station_set_config_current(&conf);

So the set_config order is different. I think "current" one check first by reading de EEPROM and if the config user and password are the same, then they are not written, the normal set_config function save ALWAYS (overwrite) the EEPROM.

This is my guess.

""""MORE""""
What I don't understand now is the diferrent between what is being said here:
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/include/espressif/esp_sta.h
(set_config_current DOESN'T SAVE)
and what I have written before:
https://github.com/esp8266/Arduino/blob/master/doc/esp8266wifi/generic-class.md that explain this:

"""""
Module is able to reconnect to last used Wi-Fi network on power up or reset basing on settings stored in specific sectors of flash memory. By default these settings are written to flash each time they are used in functions like WiFi.begin(ssid, password). This happens no matter if SSID or password has been actually changed.
This might result in some wear of flash memory depending on how often such functions are called.
Setting persistent to false will get SSID / password written to flash only if currently used values do not match what is already stored in flash.
Please note that functions WiFi.disconnect or WiFi.softAPdisconnect reset currently used SSID / password. If persistent is set to false, then using these functions will not affect SSID / password stored in flash.
To learn more about this functionality, and why it has been introduced, check issue report #1054
""""

Cheers,

@ortegafernando commented on GitHub (Jan 3, 2017): I think that is a different thing I think the solution t memory corruption is this: https://github.com/esp8266/Arduino/commit/40da463ee631133a16fc8ddde7c82d507060068b The default value of PERSISTENT is TRUE, So, as you can see in the commit that I have said, for example: if (_persistent) wifi_station_set_config(&conf); else wifi_station_set_config_current(&conf); So the set_config order is different. I think "current" one check first by reading de EEPROM and if the config user and password are the same, then they are not written, the normal set_config function save ALWAYS (overwrite) the EEPROM. This is my guess. """"MORE"""" What I don't understand now is the diferrent between what is being said here: https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/include/espressif/esp_sta.h (set_config_current DOESN'T SAVE) and what I have written before: https://github.com/esp8266/Arduino/blob/master/doc/esp8266wifi/generic-class.md that explain this: """"" Module is able to reconnect to last used Wi-Fi network on power up or reset basing on settings stored in specific sectors of flash memory. By default these settings are written to flash each time they are used in functions like WiFi.begin(ssid, password). This happens no matter if SSID or password has been actually changed. This might result in some wear of flash memory depending on how often such functions are called. Setting persistent to false will get SSID / password written to flash only if currently used values do not match what is already stored in flash. Please note that functions WiFi.disconnect or WiFi.softAPdisconnect reset currently used SSID / password. If persistent is set to false, then using these functions will not affect SSID / password stored in flash. To learn more about this functionality, and why it has been introduced, check issue report #1054 """" Cheers,

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@tablatronix commented on GitHub (Jan 4, 2017):

I really do not understand this at all, or that statement, maybe this was true as a workaround in one version of the sdk ?

correct me if I am wrong but WiFista, checks current config always, not sure why the decision would be different for persistent status.

    struct station_config current_conf;
    wifi_station_get_config(&current_conf);
    if(sta_config_equal(current_conf, conf)) {
        DEBUGV("sta config unchanged");
    } else do save stuff

Is this referring to this workaround ?

        if(WiFi._persistent) {
            // workaround for #1997: make sure the value of ap_number is updated and written to flash
            // to be removed after SDK update

@tablatronix commented on GitHub (Jan 4, 2017): I really do not understand this at all, or that statement, maybe this was true as a workaround in one version of the sdk ? correct me if I am wrong but WiFista, checks current config always, not sure why the decision would be different for persistent status. ``` struct station_config current_conf; wifi_station_get_config(&current_conf); if(sta_config_equal(current_conf, conf)) { DEBUGV("sta config unchanged"); } else do save stuff ``` Is this referring to this workaround ? ``` if(WiFi._persistent) { // workaround for #1997: make sure the value of ap_number is updated and written to flash // to be removed after SDK update ```

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@tablatronix commented on GitHub (Jan 4, 2017):

Also you realize you are referencing posts from 2015, also the persistent = false, is a workaround for a flash out of bounds corruption which is what the workaround above is for.

I fail to see the concern here. This should not be an issue using the current stable version of the sdk.

I should say this is no longer an issue, if you are having issues, it is either you are using an old library, OR you found a new bug and need some reproduction sketches.

@tablatronix commented on GitHub (Jan 4, 2017): Also you realize you are referencing posts from 2015, also the `persistent = false`, is a workaround for a flash out of bounds corruption which is what the workaround above is for. I fail to see the concern here. This should not be an issue using the current stable version of the sdk. I should say this is no longer an issue, if you are having issues, it is either you are using an old library, OR you found a new bug and need some reproduction sketches.

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jan 5, 2017):

Hi, "the problem" is still there. See this recently link (German to english)

https://translate.googleusercontent.com/translate_c?depth=1&hl=es&rurl=translate.google.es&sl=de&tl=en&u=http://www.forum-raspberrypi.de/Thread-esp8266-achtung-flash-speicher-schreibzugriff-bei-jedem-aufruf-von-u-a-wifi-begin&usg=ALkJrhg19FzTPWW1p-6a7lrJ624D2ZdDWA

Also read this from oficial github esp8266 arduino core: https://github.com/esp8266/Arduino/blob/master/doc/esp8266wifi/generic-class.md

"""""
Module is able to reconnect to last used Wi-Fi network on power up or reset basing on settings stored in specific sectors of flash memory. By default these settings are written to flash each time they are used in functions like WiFi.begin(ssid, password). This happens no matter if SSID or password has been actually changed.
This might result in some wear of flash memory depending on how often such functions are called.
Setting persistent to false will get SSID / password written to flash only if currently used values do not match what is already stored in flash.
Please note that functions WiFi.disconnect or WiFi.softAPdisconnect reset currently used SSID / password. If persistent is set to false, then using these functions will not affect SSID / password stored in flash.
To learn more about this functionality, and why it has been introduced, check issue report #1054
""""

I have marked with bold the main reason to use persistent(false). It doesn't hurt, and is good in case you have a lot of reset (once an hour is almost 10.000 / year. Depends on EEPROM it will be very bad to it).

Another from June: http://rayshobby.net/esp8266-reboot-cycled-caused-by-flash-memory-corruption-fixed/

Please read them.

@ortegafernando commented on GitHub (Jan 5, 2017): Hi, "the problem" is still there. See this recently link (German to english) https://translate.googleusercontent.com/translate_c?depth=1&hl=es&rurl=translate.google.es&sl=de&tl=en&u=http://www.forum-raspberrypi.de/Thread-esp8266-achtung-flash-speicher-schreibzugriff-bei-jedem-aufruf-von-u-a-wifi-begin&usg=ALkJrhg19FzTPWW1p-6a7lrJ624D2ZdDWA Also read this from oficial github esp8266 arduino core: https://github.com/esp8266/Arduino/blob/master/doc/esp8266wifi/generic-class.md """"" Module is able to reconnect to last used Wi-Fi network on power up or reset basing on settings stored in specific sectors of flash memory. By default these settings are written to flash each time they are used in functions like WiFi.begin(ssid, password). This happens no matter if SSID or password has been actually changed. This might result in some wear of flash memory depending on how often such functions are called. **Setting persistent to false will get SSID / password written to flash only if currently used values do not match what is already stored in flash**. Please note that functions WiFi.disconnect or WiFi.softAPdisconnect reset currently used SSID / password. If persistent is set to false, then using these functions will not affect SSID / password stored in flash. To learn more about this functionality, and why it has been introduced, check issue report #1054 """" I have marked with bold the main reason to use persistent(false). It doesn't hurt, and is good in case you have a lot of reset (once an hour is almost 10.000 / year. Depends on EEPROM it will be very bad to it). Another from June: http://rayshobby.net/esp8266-reboot-cycled-caused-by-flash-memory-corruption-fixed/ Please read them.

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@tablatronix commented on GitHub (Jan 5, 2017):

Yeah I know I read it.
I am just saying that is probably old, as in old as when persistence was first added.

I also posted the code that does this..
And you can clearly see it, its not a mystery, its right there.
I even tested it ( there is a debugV even already in the code )!
DEBUGV("sta config unchanged");

It says that in your debug output ( if enabled), you can test this yourself, or throw a scope on the flash, I mean are you basing this on some assumption or actual tests?

Are you talking about some other use case, like constantly switching back and forth between aps, or AP mode, or that wifimanager is causing this bug because it is constantly disconnecting and reconnecting and causing flash erases.

@tablatronix commented on GitHub (Jan 5, 2017): Yeah I know I read it. I am just saying that is probably old, as in old as when persistence was first added. I also posted the code that does this.. And you can clearly see it, its not a mystery, its right there. I even tested it ( there is a debugV even already in the code )! `DEBUGV("sta config unchanged");` It says that in your debug output ( if enabled), you can test this yourself, or throw a scope on the flash, I mean are you basing this on some assumption or actual tests? Are you talking about some other use case, like constantly switching back and forth between aps, or AP mode, or that wifimanager is causing this bug because it is constantly disconnecting and reconnecting and causing flash erases.

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jan 5, 2017):

Hi @tablatronix . I think that it is old, yes, but it is also effective nowadays. I haven't already test it. I am used to arduino and I am working now with esp8266. I will isntalla wifiManager and OTA updates as defaults in all my sketchs, but for that I have read tons of forum about esp8266. One thing that I have found is about EEPROM corruption; and persisten boolean variable seems to help a lot, but it is necessary to be in wifiManager.
I don't know why you think that it is solved now. Normally, for people that only reset their ESP8266 once a day, EEPROM will not have problems, but in other cases yes. persistent(false) doesn't hurt nothing in wifiManager, does it ?
Imagin that I use, as lots of people use, wifiManager as a template for all my sketchs. I COULDN'T do a sensor monitor each 15 minutes with deep sleep, becuase of ONLY in 3 months, my ESP8266 would reset more than 10.000 times, .... so EEPROM .... Imagine one year ...
I can't say you that I have test, but lots of forum, web pages, and so on say about use persistent(false). Otherwise they would have delete it from the source code, wouldn't they?
I could fork this great library and add persistent(false) to my own projects, but I prefer that both @tzapu and @kentaylor include that line in their libraries, so all people will get this improvement.

I don't know if I am wrong, but I have read in a lot of places about using persistent(false).

Do you think that it is NOT necessary? Is wifiManager saving in EEPROM (wifi.Begin) each boot ?

Regards,

@ortegafernando commented on GitHub (Jan 5, 2017): Hi @tablatronix . I think that it is old, yes, but it is also effective nowadays. I haven't already test it. I am used to arduino and I am working now with esp8266. I will isntalla wifiManager and OTA updates as defaults in all my sketchs, but for that I have read tons of forum about esp8266. One thing that I have found is about EEPROM corruption; and persisten boolean variable seems to help a lot, but it is necessary to be in wifiManager. I don't know why you think that it is solved now. Normally, for people that only reset their ESP8266 once a day, EEPROM will not have problems, but in other cases yes. persistent(false) doesn't hurt nothing in wifiManager, does it ? Imagin that I use, as lots of people use, wifiManager as a template for all my sketchs. I COULDN'T do a sensor monitor each 15 minutes with deep sleep, becuase of ONLY in 3 months, my ESP8266 would reset more than 10.000 times, .... so EEPROM .... Imagine one year ... I can't say you that I have test, but lots of forum, web pages, and so on say about use persistent(false). Otherwise they would have delete it from the source code, wouldn't they? I could fork this great library and add persistent(false) to my own projects, but I prefer that both @tzapu and @kentaylor include that line in their libraries, so all people will get this improvement. I don't know if I am wrong, but I have read in a lot of places about using persistent(false). Do you think that it is NOT necessary? Is wifiManager saving in EEPROM (wifi.Begin) each boot ? Regards,

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@tablatronix commented on GitHub (Jan 6, 2017):

Because https://github.com/esp8266/Arduino/issues/1997
I found the bug, and igrr implemented a workaround for the issue.
github.com/esp8266/Arduino@f2fb43cabf

Now if you have people using espressif SDK and not arduino sdk , then there might be still an issue, but that is not the case here, unless people are incorrectly using espressif sdk functions instead of the arduino ones.

I also found this to be a good standard test to reproduce that issue, instead of crafting my own.
https://github.com/esp8266/Arduino/issues/1699#issue-137113910

@tablatronix commented on GitHub (Jan 6, 2017): Because https://github.com/esp8266/Arduino/issues/1997 I found the bug, and igrr implemented a workaround for the issue. https://github.com/esp8266/Arduino/commit/f2fb43cabfde9bfcc52cb4a4288e7c70c5bdc326 Now if you have people using espressif SDK and not arduino sdk , then there might be still an issue, but that is not the case here, unless people are incorrectly using espressif sdk functions instead of the arduino ones. I also found this to be a good standard test to reproduce that issue, instead of crafting my own. https://github.com/esp8266/Arduino/issues/1699#issue-137113910

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jan 6, 2017):

Thanks @tablatronix for your great effort. At this time I have no knowledge about SDK and so on.
I can see that you are a great expert !!! ;)
I have read also that @kentaylor said somethnig similar on 1 Dec 2016:
"@Ttech, disconnecting from WiFi is fine and reduces power. Call WiFi.disconnect(false) which doesn't erase flash, then WiFi.begin() when you want to reconnect. Deep sleep will reduce power consumption much more. Search around for explanations of how to do it.
You can also avoid using the flash store by calling WiFi.persistent(false) prior to calling WiFi.begin(SSID,password).
I'm wondering if corrupted flash is commonly associated with Exception (3). It looks likely to be the underlying problem here."

But I don't know why @kentaylor doesn't implement WiFi.persistent(false) prior to calling WiFi.begin(SSID,password) in his wifiManager's fork.

I am not an expert, but the question is:

does wifi.persistent(false) hurt ?
does it help a little bit not to have future problems with flash memory failures ?

Could @kentaylor tell us his opinion ?

Regards,

@ortegafernando commented on GitHub (Jan 6, 2017): Thanks @tablatronix for your great effort. At this time I have no knowledge about SDK and so on. I can see that you are a great expert !!! ;) I have read also that @kentaylor said somethnig similar on 1 Dec 2016: "@Ttech, disconnecting from WiFi is fine and reduces power. Call WiFi.disconnect(false) which doesn't erase flash, then WiFi.begin() when you want to reconnect. Deep sleep will reduce power consumption much more. Search around for explanations of how to do it. You can also avoid using the flash store by calling WiFi.persistent(false) prior to calling WiFi.begin(SSID,password). I'm wondering if corrupted flash is commonly associated with Exception (3). It looks likely to be the underlying problem here." But I don't know why @kentaylor doesn't implement WiFi.persistent(false) prior to calling WiFi.begin(SSID,password) in his wifiManager's fork. I am not an expert, but the question is: 1. does wifi.persistent(false) hurt ? 2. does it help a little bit not to have future problems with flash memory failures ? Could @kentaylor tell us his opinion ? Regards,

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@tablatronix commented on GitHub (Jan 6, 2017):

Because then you have to wait until begin to connect to wifi, else persistant starts connecting at boot. Also begin requires hardcodig credentials in your sketch. Persistant uses flash which you can set however you want.

He is also referencing deep sleep modes which are highly optimized. So there might be something with that

@tablatronix commented on GitHub (Jan 6, 2017): Because then you have to wait until begin to connect to wifi, else persistant starts connecting at boot. Also begin requires hardcodig credentials in your sketch. Persistant uses flash which you can set however you want. He is also referencing deep sleep modes which are highly optimized. So there might be something with that

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jan 6, 2017):

I don't understand you. Sorry. May be this is difficult for me.

@ortegafernando commented on GitHub (Jan 6, 2017): I don't understand you. Sorry. May be this is difficult for me.

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jan 12, 2017):

Meanwhile I have forked your github library and added option to use persistent(false), I will try to use it and see if there is any problem

Here is another little problem about persistent(false) https://github.com/tzapu/WiFiManager/issues/280

I hope anyone else could give us their experience or knowledge.

@ortegafernando commented on GitHub (Jan 12, 2017): Meanwhile I have forked your github library and added option to use persistent(false), I will try to use it and see if there is any problem Here is another little problem about persistent(false) https://github.com/tzapu/WiFiManager/issues/280 I hope anyone else could give us their experience or knowledge.

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@Defozo commented on GitHub (May 18, 2017):

@ortegafernando Any news on this?

@Defozo commented on GitHub (May 18, 2017): @ortegafernando Any news on this?

kerem commented

2026-02-28 01:23:59 +03:00

Author

Owner

@ortegafernando commented on GitHub (Jun 21, 2017):

Hi, I have been busy with an Arduino Project, so I have left ESP8266 for a few months. Has anybody any other news ?

@ortegafernando commented on GitHub (Jun 21, 2017): Hi, I have been busy with an Arduino Project, so I have left ESP8266 for a few months. Has anybody any other news ?

Rows
Columns

[GH-ISSUE #242] Does WifiManager suffers EEPROM failures? #200