reboot after deepsleep #3072
Comments
|
Hmm I was preparing the release as Travis messed up, but reports like these will be a good reason to pause it a bit and test it first tomorrow morning. This is the ZIP I prepared. |
TD-er
added
Category: Build
|
Can you also test a 'beta' labelled build from that zip file? |
|
Can you check what flash chip you're using? |
|
Here the info from flash : |
|
Ok I tested the ESP_Easy_mega_20200516_custom_beta_ESP8266_4M1M Version. It is a little better but still not fine: The reboot loop after waking up breaks after a few reboots, but is still there. In some rarae cases waking up and re-connection works fine. ESP_Easy_mega_20200516_custom_beta_ESP8266_4M1M and ESP_Easy_mega_20200516_custom_ESP8266_4M1M give unfortunately same result :-( My testing config: wake 5s sleep 30s |
|
I rolled back the version to mega-20200305 this is much more stable, However from time to time I also have seen the re-boots during waking up. But maybe one out of 20.... |
|
OK, so it is not really a newly introduced bug, but more like the frequency at which it occurs has increased? Knowing this, I published the last build I made as the 20200515 nightly build.: https://github.com/letscontrolit/ESPEasy/releases/tag/mega-20200515 I will link this topic as a semi-known issue. |
|
Yes, looks like it. sensors are not connected during testing. |
|
Hi Regards |
|
@TD-er OK, thank you |
|
I investigated my situation further: I used several old pre-build images working me back in history.(now I'm at 20191208). I monitored the behaviour of the device after deepsleep: From time to time I see a reboot during connection to WIFI. The early 2020 versions seem more stable than the recent ones. However I see a strange behaviour there as well: The webserver does not start from time to time. What's also really strange: I updated another device with the latest version (causing the reboots as described above) but now after going back to older version I observe that during several wakeup periods no data are reported to database. Before updating the device worked reliably. Any Idea? |
|
I do have the feeling the WiFi radio may not always be turned on in the same way as on a cold boot. If so, then it may be quite hard to draw conclusions from just a few sleep/boot loops when changing firmware versions. |
|
I continued testing... This gives stable restarts. Would it be possible to disable the saving of WIFI registers? |
|
Sure. Another difference your change makes is that it will perform a full scan. |
|
My access point does not use fixed channel, so it is possible that it changed channel. But I do not expect that it changed it every 60s... |
|
OK testing did continue. Obviously the ESP was under water for about 6hrs and is still working! (the led was alight when I rescued it.., Only my SR04 seems to be broken...) |
|
OK, so the flushing of syslog, or maybe more accurately: trying to write before we have a network connection, is causing a crash. Just a note to myself: Maybe the reported "connected" state is incorrect when doing a reconnect after deep sleep. |
|
The issue with syslog is definitely not new. I have one ESP measuring temperature in my cellar. It always had problems to send data on regular base. I thought it was due to bad WIFI. But since I disabled syslog-server it records fine after each deepsleep interval. (firmware is from nov 2018)
|
|
OK, will have a look at it, as I'm currently working in the network-layer part of the code. (for another feature I'm working on) |
|
Hi, I am the starter of this forum thread: https://www.letscontrolit.com/forum/viewtopic.php?f=6&t=7555, seeing the same/similar issues in my Wemos D1 Mini's. I started examining further this morning, having flashed mega-20200608 on one of the devices. Initially I was still seeing the issues I reported on the forum. To summarize:
Searching for similar issues, I found this thread and the Syslog connection. I have the D1's log to the syslog on my home server. Switching the syslog off totally removes the issues on the D1 I was testing on. To me, that confirms the diagnose set here. I will remove syslogging on the other D1's to confirm. I can't help in troubleshooting the code I'm afraid, but I'm happy to help testing where ever I can. Johan |
|
I just merged a commit that may reduce the needed amount of stack memory for sending out syslog log entries. Please let me know if it does fix these issues. |
I'm unable to build from source. If you can provide a binary, I'm happy to test. |
|
Dear @TD-er, |
I made a test build of the current mega branch: As @stefbo27 showed, the reduced stack usage of the add to syslog does not fix this particular issue. |
|
Thanks. Tested anyway and confirm it does not solve the problem. Part of the log, FWIW: `INIT : Booting version: (ESP82xx Core d85ff6ef, NONOS SDK 2.2.2-dev(a58da79), LWIP: 2.1.2 PUYA support) 820 : Info : WIFI : Connecting RommeNet_1 attempt #0 connected with RommeNet_1, channel 5 --------------- CUT HERE FOR EXCEPTION DECODER --------------- Exception (28):
ctx: sys |
|
Could you test with this test build? |
…olit#3147 letscontrolit#3072) It appeared the log handling function was sometimes processing flash strings or progmem strings and thus crashing with an exception. Crashes like these: ``` ets Jan 8 2013,rst cause:4, boot mode:(3,6) 0x40275929 in String::operator=(char const*) at ??:? 0x4022cab9 in process_serialWriteBuffer() at ??:? 0x4023532b in addToSerialBuffer(char const*) at ??:? 0x402756a0 in String::copy(char const*, unsigned int) at ??:? 0x40238bd3 in addToLog(unsigned char, char const*) at ??:? 0x40275cac in String::concat(String const&) at ??:? 0x402b3849 in wifi_station_get_rssi at ??:? 0x402754bd in String::invalidate() at ??:? 0x40238c88 in addToLog(unsigned char, String const&) at ??:? 0x4025be2a in WiFiConnected() at ??:? 0x4025a500 in NetworkConnected() at ??:? 0x402cd8b0 in chip_v6_unset_chanfreq at ??:? 0x40238a9e in syslog(unsigned char, char const*) at ??:? 0x4021ebd3 in getMaxFreeBlock() at ??:? 0x4022cab9 in process_serialWriteBuffer() at ??:? 0x402754bd in String::invalidate() at ??:? 0x40238c25 in addToLog(unsigned12484 : Info : EVENT: Clock#Time=Mon,11:27 ```
|
Sorry, I was not able to test any sooner. In addition, I sometimes see the following in the (serial) log: `1711 : Info : Domoticz: Sensortype: 1 idx: 160 values: 3.00 11684 : Info : WIFI : DHCP IP: 192.168.1.25 (D1Mini) GW: 192.168.1.1 SN: 255.255.255.0 duration: 21 ms This also happens when I use static IP, then "DHCP IP" in the lines is replaced with "Static IP". It does not seem to affect the working. It takes a couple of minutes after cold boot until this happens, but then it occurs repeatedly. I am attaching a longer log file where you can see all this happen. [Com COM13] (2020-07-11_111456).log Conclusion: it's looking much better, but not quite there yet. Johan |
|
I'm still working on the WiFi stuff. It appeared we had several issues here at hand.
Crash when sending the log is now fixed, but the issue with the incorrect state of the WiFi is still a work in progress. |
After waking up from deepsleep I get the following log:
Same happens with fixed IP:
I am using latest version (mega20200515).
Same observation with another device. Both were running before with older version (~1month old) without problems.
The text was updated successfully, but these errors were encountered: