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.