Locked after configuration

[fmgomes]

In order to test if the WiFi configuration is working, I call WiFi.disconnect(); and reboot the node. It enters in configuration, using the following code:

Serial.println("WiFi Init...");
wifiManager.setAPCallback(configAPCallback);
wifiManager.setTimeout(180);
if (!wifiManager.autoConnect("xpto")) {
// Connection timeout - go to sleep
Serial.println("WiFi configuration timeout! Shutting down");
delay(5000);
digitalWrite(15, LOW);
}
Serial.println("Connected");

I am able to scan and select the network using a browser, but then it 'freezes' when trying to connect to the selected network. Since I'm using the timeout feature I was expecting that it will go again into configuration mode if it wasn't able to connect during a certain time.

Any idea about this problem? Is there any additional test that I can do that can help?

Fernando

[kentaylor]

There are a few issues here.

First, the timeout feature controls how long the configuration portal will remain open before closing automatically not whether it "will go again into configuration mode if it wasn't able to connect during a certain time"

Second, do not use wifiManager.autoConnect . See https://github.com/kentaylor/WiFiManager/#evidence-the-premise-is-wrong-and-the-problems-it-causes for reasons. Try this example https://github.com/kentaylor/WiFiManager/tree/master/examples/ConfigOnSwitch .

Third it probably didn't freeze. I found a lot of users thought it was failing when it wasn't. This version https://github.com/kentaylor/WiFiManager/ has a different workflow that tested better in my user tests.

[fmgomes]

Thanks for pointing me to these issues. Since I have no switch in order to force it to enter in config mode, I think that it could be possible to start the configuration portal when it has no SSID configured or if it has a configured SSID but the waitForConnectResult() returns as 'not connected', do you agree? Or will it be preferable to do a timed wait on wifi.status()? In a quick look to the waitForConnectResult() method, it wasn't clear to me that the function exits if it can't connect, so it can be preferable to read status periodically and exit after a few retries if it still isn't connected.

[kentaylor]

@fmgomes asks "do you agree?" Yes I do. waitForConnectResult() will exit if it can't connect.

If you look at https://github.com/kentaylor/WiFiManager/tree/master/examples/ConfigOnSwitch you will see as well as going into configuration mode when a button is pushed it implements the logic you suggest. .

[fmgomes]

@kentaylor thanks for your feedback, I tried to call the startConfigPortal(), it worked for the configuration part (network scan, etc.), but unfortunately ended with a crash after saving parameters:

*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting wifi with new parameters...
*WM: previous settings invalidated
*WM: After waiting...

Exception (9):
epc1=0x40240d08 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000055 depc=0x00000000

ctx: sys
sp: 3ffffd90 end: 3fffffb0 offset: 01a0

stack>>>
3fffff30: 00000000 3fff6b34 0000001c 4021d2d9
3fffff40: 00000000 000000f0 f703a8c0 3ffedd9c
3fffff50: 4023cc09 3fff6b34 3fff6674 3ffedd9c
3fffff60: 3fff1980 3ffeddb0 3ffedd94 4023b97f
3fffff70: 3fff464c 00000014 4023bf2a 3fff6b34
3fffff80: 3fff6674 3fffdc80 3fff7e3c 00000000
3fffff90: 4022a9a7 3fff6b34 00000000 40213393
3fffffa0: 40000f49 3fffdab0 3fffdab0 40000f49
<<<stack<<<

ets Jan 8 2013,rst cause:1, boot mode:(1,7)

Any idea why?

Fernando

[kentaylor]

Interesting. Can you reproduce it or did it just happen once?

You got to here https://github.com/kentaylor/WiFiManager/blob/master/WiFiManager.cpp#L311 but didn't get to here https://github.com/kentaylor/WiFiManager/blob/master/WiFiManager.cpp#L314 . It probably failed in the call to EspresifSDK function wifi_get_opmode here
https://github.com/esp8266/Arduino/blob/e82b74eab2f04a065ac97b678669bb81a2cdd79f/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L321

Exception (9): as described in Table 4–64. Exception Causes at http://0x04.net/~mwk/doc/xtensa.pdf is "9 LoadStoreAlignmentCause Load or store to an unaligned address" . That makes this seem relevant to esp8266/Arduino/issues/1997 .

There are some things I don't understand though:-

1. rst cause:1 usually means reset during power up but it doesn't look like this was power cycled. Was this reset caused by power cycling?
2. The 1 in "boot mode:(1,7)" should be 3. It will freeze if it is 1. It usually means the pins are connected wrongly but it could mean this it has not been power cycled since it was last programmed through the serial port according to @igrr in the last post at https://www.bountysource.com/issues/28242978-automatic-reboot-after-wdt-reset . So which development board are you using, are the pin pull ups correct or did this occur after programming and before power cycling?

[fmgomes]

@kentaylor, thanks again for your reply. I will try in a more conventional node. I'm using an esp12 but with custom hardware to trigger the power down mode by software, so other things might happen and make it more difficult to analyze the results, specially the reset cause and boot mode. I'll try with a conventional nodeMCU, and post here the results.

[kentaylor]

Trying another device is good because it occurred to me that non volatile memory can be corrupted when WiFiManager fails. I'm not sure what effect this will have but rebooting or loading a new sketch doesn't fix the corrupted non volatile memory.

A few hours ago a fix was added to the Arduino core to avoid the memory corruption. See esp8266/Arduino@f2fb43c . You should add this Arduino code.