Skip to content
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

Does WifiManager suffers EEPROM failures? #242

Closed
ortegafernando opened this issue Nov 4, 2016 · 16 comments
Closed

Does WifiManager suffers EEPROM failures? #242

ortegafernando opened this issue Nov 4, 2016 · 16 comments

Comments

@ortegafernando
Copy link

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.

@tzapu
Copy link
Owner

tzapu commented 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

@ortegafernando
Copy link
Author

ortegafernando commented Jan 3, 2017

Hi, I have read again this esp8266/Arduino#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: esp8266/Arduino#1054 (comment)
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)

@tzapu
Copy link
Owner

tzapu commented Jan 3, 2017

hi
this looks fixed though
esp8266/Arduino@6be74ec

cheers
alex

@ortegafernando
Copy link
Author

ortegafernando commented Jan 3, 2017

I think that is a different thing

I think the solution t memory corruption is this:
esp8266/Arduino@40da463

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,

@tablatronix
Copy link
Collaborator

tablatronix commented 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
Copy link
Collaborator

tablatronix commented 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.

@ortegafernando
Copy link
Author

ortegafernando commented 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.

@tablatronix
Copy link
Collaborator

tablatronix commented 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.

@ortegafernando
Copy link
Author

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,

@tablatronix
Copy link
Collaborator

tablatronix commented Jan 6, 2017

Because esp8266/Arduino#1997
I found the bug, and igrr implemented a workaround for the issue.
esp8266/Arduino@f2fb43c

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.
esp8266/Arduino#1699 (comment)

@ortegafernando
Copy link
Author

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,

@tablatronix
Copy link
Collaborator

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

@ortegafernando
Copy link
Author

ortegafernando commented Jan 6, 2017

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

@ortegafernando
Copy link
Author

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) #280

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

@Defozo
Copy link

Defozo commented May 18, 2017

@ortegafernando Any news on this?

@ortegafernando
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants