LIGHT_SLEEP_T causes endless delay

[MikhailNatalenko]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: [ESP-12]
• Core Version: [latest git hash or date]
• Development Env: [Arduino IDE]
• Operating System: [Windows]

Settings in IDE

• Module: [Nodemcu]

Problem Description

LIGHT_SLEEP_T wifi mode brakes sketch. After 10-15 seconds from connection it just stop's without any output (like infinite loop with yield()). No WDT reset or exception.

This bug appers in last commit (170911a) and 2.4.1. 2.4.0 works fine (SDK: 2.1.0 deb1901)

Delay before wifi_set_sleep_type(LIGHT_SLEEP_T); doesn't help (5-10 seconds)

MCVE Sketch

#include <ESP8266WiFi.h>

extern "C" {
#include "user_interface.h"
}

void printStatus();

void setup() {
  wifi_set_sleep_type(LIGHT_SLEEP_T);
  WiFi.begin("my-ssid", "password");
  delay(500);
  
  WiFi.printDiag(Serial);

  Serial.begin(115200);
  Serial.println(F("\xAA\xAA\xAA\xAA\xAA\xAA\xAA\xAA\r\n"));
  delay(100);
  Serial.print(F("Core: "));
  Serial.println(ESP.getCoreVersion());

  Serial.print(F("SDK: "));
  Serial.println(ESP.getSdkVersion());

  WiFi.printDiag(Serial);
  Serial.println(F("Starting Firmware"));

}

void loop(void) { 
  delay(250);
  printStatus();
}

void printStatus() {
  static auto i = 0;
  Serial.print(WiFi.isConnected());
 
  if (i > 20) {
    Serial.println();
    i = 0;
  }
  i++;
}

Core: 00000000
SDK: 2.2.1(cfd48f3)
Mode: STA
PHY mode: N
Channel: 6
AP id: 0
Status: 1
Auto connect: 1
SSID (7): my-ssid
Passphrase (8): password
BSSID set: 0
Starting Firmware
0011111111111111111111
111111111111111111111

It stops here. No any output

[MikhailNatalenko]

it seems problem solved with last commits

[devyte]

Closing as solved.

[openfsguruh]

Have seen exactly the same. Also when connected to WiFI Station mode.
Fix is not yet included in 2.4.1 so fix will be in next release, correct?

[reloxx13]

i still get this with latest git

also:
#4658

[MikhailNatalenko]

@devyte

It looks like i was wrong when i had decided that last commit solves issue, sorry (i am a dumbass)

Issue is not solved, and we still can't use LIGHT_SLEEP_T.

[pfeerick]

@devyte If this has been brought up in another open issue my apologies, but I believe this issue is still present - or more specifically - it seems we don't need to set LIGHT_SLEEP any more as it is the default mode, and setting it actually causes a problem??? Maybe? Possibly?

I have code for a NTP matrix display clock that worked fine with 2.4.0, but has stopped working since up I updated to 2.4.1 and now 2.4.2. The ESP8266 freezes cold turkey 5-6 seconds after connecting to the WiFi in station mode. I was using wifi_set_sleep_type(LIGHT_SLEEP_T); but WiFi.setSleepMode(WIFI_LIGHT_SLEEP); has the same symptoms. When I enabled debug messages to try and work out if it was an issue on my end to setting up a new system or compile related, I got a message from the core indicating the link power management state was changing the instant it was crashing... I'll add that specific message tomorrow when I have that machine up again.

Some quick power consumption testing against my older clock (2.4.0 compiled and using wifi_set_sleep_type(LIGHT_SLEEP_T);) indicates that the one I have breadboaded is also sending the modem to sleep, but I'm not issuing either of the LIGHT_SLEEP commands as doing so would cause the 2.4.2 core compiled code to crash. I'm using https://github.com/tzapu/WiFiManager if this has any bearing on the issue (v0.14)

[d-a-v]

LIGHT_SLEEP behavior has changed in recent nonos-sdk (the part we don't control).
Switching to NONE_SLEEP may work.
Check this comment

[d-a-v]

You could also try the PingAlive workaround and check power consumption.

[pfeerick]

@d-a-v Well, shucks! :(

In my particular case, I want it to sleep, so it seems that the new default behaviour does exactly what I want (so it looks like instances where we'd want the old 'stay on unless you're told otherwise' behaviour will require NONE_SLEEP. Interesting).

The code has been running stable for over half an hour with no lockups now, only change required was to remove the LIGHT_SLEEP command, and seems to be consuming the same amount of power as the 2.4.0 code with LIGHT_SLEEP enabled. At least I can get to work tidying up the code and figuring out how to get this accelerometer to work now! :)

If it starts playing up (i.e. loses connection) I'll try the NONE_SLEEP / PingAlive workarounds... If I think of it I'll program up another ESP8266 up with PingAlive and report my luck with it.

[MikhailNatalenko]

@pfeerick I have a stand with a current monitor, so i will confirm (or refute) this later. Anyway, thank you for your answers!

[EUA]

I experiment LIGHT_SLEEP and found that 2.4.1 and 2.4.2 still has infinite delay issue. So your device simply does NOT wake up from light sleep. I use 2.4.0 code with this command:
WiFi.setSleepMode(WIFI_LIGHT_SLEEP);
I got 1 mA power consumption on 2.4.0 and there are spikes to 16mA (which is MODEM_SLEEP consumption) of course.

I use WIFI_NONE_SLEEP and it consumes 70mA, so @pfeerick observations can not be true on my device.
WIFI_MODEM_SLEEP at the other hand give me 16mA without any networking issue.

PS: For light sleep, also you need to setup your router/AP properly.
For example if a task needs 100ms on your esp8266 code and you use delay for 900ms, than you need to set beacon time to 100ms and DTIM time as 2. Than your device will sleep at least 200ms after delay() code. Because DTIM reach your device at Beacon time x DTIM count.
If you adjust DTIM=1 and Beacon=100, than your device will enter sleep state when each beacon reaches to your device but your device need to wakeup each 100ms to receive beacon/DTIM frame this time.

But If you set beacon time 1000ms, and DTIM=2, than your device probably not gonna sleep so much. Because your device waits beacon/DTIM for 900ms but it delivered each 2000ms.

Depending my observation, I think device enters LIGHT_SLEEP when second DTIM frame delivered.

So please open this bug again.

[devyte]

@EUA this is currently considered to be an issue in the sdk and not in our core. That is why this is closed.
Do you mean that you got light sleep to work reliably with 2.4.2 and those dtim/sleep combinations?

[d-a-v]

Please follow this discussion in #5120 #5210

[pfeerick]

I can't comment as to power consumption at present as I don't have inline power meters setup on the ESP8266/Digistump Oak boards, but as far as stability, it would appear that the 2.4.0 code with wifi_set_sleep_type(LIGHT_SLEEP_T) and the 2.4.2 code omiting that line are still running stably after two week stretches of 24x7 runtime (there were some power interrupts, it wasn't code/lockup related).

Since it needs to reguarly do NTP sync, and it is not only accurate but the two units are not drifting, I would surmise that networking is still functioning properly, and a crude power consumption check (finger to the can, it's cold, instead of the warm to hot when running without sleeping) suggests they are sleeping most of the time.

I have time to start playing with this again soon, so will be able to comment further and provide data for #5210 also. It is curious to note that @EUA had different results, so I'll have to do some more testing there. We probably also need use a common test script for this, so that there is not a difference in behaviour resulting from something else our code is doing.

[EUA]

@devyte , nope. I don't have any luck with v2.4.1and with 2.4.2. Light Sleep causes endless delay in this codes.
But even with 2.4.0, my device cannot drop to LIGHT_SLEEP properly without correct DTIM settings. My device only drop to MODEM_SLEEP (16mA). After setting proper DTIM, the device enters LIGHT_SLEEP (1mA with spikes to 16mA at beacon frame reception.) I just wanted to add my 2 cents.
I wish new 3.0 sdk fix this behavior. Will test it soon.

PS: I understand that this bug is NOT related with this project but marking it "closed" makes me think like there are no such a bug. Might be it's better to leave it open with "SDK's Known Bug" mark. Bests.

[devyte]

Everyone, an SDK update has been merged, along with accompanying logic in our core, in #5210 . It addressed light sleep behavior, which changed in recent SDK updates, probably to "improve" power usage.
The Light sleep issue was actually covered in #1381 , which is now also closed as resolved.
If there are further problems with light sleep, please open a new issue.

[martinhanes]

I can confirm, the issue has been fixed for my case in #5210. Before that, 2.4.2-release had still delay() problem. Thank you, @devyte, for fixing it!

[ghost]

Hi, anyone still having this problem with later versions? I'm having exactly the described problem with version 2.5.2. Tried 2.3.0 (Arduino Board Manager lets you choose versions easily) and didn't have the problem.
Any version past 2.3.0 still hangs some time after calling delay(...) a few times, even 2.4.0 and 2.4.2. Am I missing something, I thought it was merged into the official release, I am using the Arduino Board Manager with the link provided on this github page.

For reference, I designed a custom breakout board with relay some buttons for the ESP-M2 (ESP8285) Module. I will try the same with a WEMOS D1 mini later, as it has the more common ESP-12F built in. Though I'd be surprised if that yielded different results, this shouldn't be a hardware issue.

[martinhanes]

Hi @eikerenners, I didn't investigate this further but I've experienced some difference between version 2.5.2 installed using Boards manager on one Mac, and a version newer than 2.4.2 (using the commit right after the PR [https://github.com//pull/5210]) on other Mac.

The checked out version right from the github works without any problems so far - I recommend starting there - try out that version if it works for you.

I'm unable to help you more this week, but I'm happy to try boards-manager-installed newer versions later. The delay problem was bothering me as well for a long time so I can relate how painful it is to deal with. Please, do let me know if at least the checked-out version works for you.

Martin

[ghost]

Thanks for answering, I checked with the WEMOS and same behavior.

I just found if I check out the github version and manually install the latest tool chain (using the get.py script) I get the right behavior. I'm no expert on how the board manager gets the extensa tools, but that might have been the problem.

[martinhanes]

That sounds about right. I've installed 2.5.2 and then fetched get.py esptool, and it's working.

Also, when the git-version 2.5.2 is matching "boards manager" version 2.5.2 - then even using IDE-managed board, it's working. Not sure how this works - but I see two 'groups' both with esp8266 - v 2.5.2 labels at Tools->Board.

To sum it up - I think IDE is not doing it's job when it comes to hadling version of library + version of esptool. In my case - both macs - the problem was solved by git-cloning the library and (after checkout and after every different commit checkout) running all of the following:

cd esp8266
git submodule update --init
cd esp8266/tools
python get.py

Then, it worked as a charm. My biggest mistake was to not fetch the esptool and just checking-out different commit on the repo. And it's not always matching and compiling the code. Hope some of my notes helped. Martin