Wemos d1 mini not waking up #6318

flowhl · 2019-07-19T12:18:51Z

Im trying a simple deepsleep sketch to use it in one of my projects but when the deepsleep ends, the led flashes once and nothing happens. how can i fix this?

it sleeps because it doesnt print the deepsleep not working message but when its waking up, the led flashes once and nothing happens
I connected GPIO 16 to rst

i also debuged it with Serial.setDebugOutput(true);

Debug Messages

22:02:17.751 -> ets Jan 8 2013,rst cause:2, boot mode:(3,6)
22:02:17.751 ->
22:02:17.751 -> load 0x4010f000, len 1384, room 16
22:02:17.751 -> tail 8
22:02:17.751 -> chksum 0x2d
22:02:17.751 -> csum 0x2d
22:02:17.785 -> v8b899c12
22:02:17.785 -> ~ld
22:02:51.502 ->
22:02:51.502 -> ets Jan 8 2013,rst cause:2, boot mode:(3,6)
22:02:51.502 ->

my code:

#include <ESP.h>

void setup() {
Serial.begin(2400);
Serial.setDebugOutput(true);
}

void loop() {
// put your main code here, to run repeatedly:
Serial.print("Uaaah. I'm tired. Going back to bed for ");
Serial.println(" minutes. Good night!");
Serial.println("---");
ESP.deepSleep(20 * 1000000);
delay(100);
Serial.println("deepsleep not working");
}

TD-er · 2019-07-19T17:42:53Z

Just curious, why are you using such a slow baudrate for the serial port?
2400 bps is roughly about 240 characters per second.
Also the loop() function does not really run very long.
It is probably only awake for a few msec and then you don't have time to output anything to the serial port.

fsommer1968 · 2019-07-23T13:50:16Z

Set the baud rate to 74400 and test again and post the new logfile if still required.

suculent · 2019-07-25T15:20:14Z

Or maybe use Serial.flush(); after last print?

bjoernbusch · 2019-12-26T20:56:35Z

I'm facing the same issue. I increased the baud rate to 74880, but the log doesn't show anything helpful. Any hints on this?

Tech-TX · 2019-12-29T05:57:22Z

@bjoernbusch Put a 1 to 2 second delay before you hit the ESP.deepSleep() command if you're doing something like the original poster. His code only runs for a few microseconds before it goes back into deep sleep, so the serial port never has a chance to get the first byte of his print statement sent out, and then the serial buffer is wiped when the chip resets and boots again after deep sleep. I ran deep sleep on a 30 minute cycle for a couple of months, so I know it works.

bjoernbusch · 2019-12-29T06:49:03Z

Thanks, @Tech-TX it was actually an issue with the resistor between D0 and RST. Somehow my 560 resistor was too much, I replaced it by a simple wire and now it works.

Tech-TX · 2019-12-29T14:18:07Z

I was wrong about the delay(); I just pulled up my old test program and it works. I'm using a D1 Mini.

  // Deep sleep test for 5 seconds (5E6 microseconds) - the ESP8266 wakes up by itself if
  // GPIO16 (D0) is connected to the RESET pin or you press the RESET switch / ground RST.
  //
  // You'll need to ground GPIO0 (D3) and press the RESET switch to upload again after
  // this is running or the serial won't connect 'cos it's almost always ASLEEP.
  
void setup() {
  Serial.begin(74880);
//  while (!Serial) { } // Wait for serial to initialize (wasn't needed)
  Serial.println("I'm awake, but I'm going into deep sleep for 5 seconds");
}

void loop() {
  // your code goes here
    ESP.deepSleep(5E6); // good night!
    Serial.println("What... I'm not asleep?!?");  // it will never get here
}

Here's the output on the serial monitor:

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3456, room 16
tail 0
chksum 0x84
csum 0x84
v3197d2ac
~ld
I'm awake, but I'm going into deep sleep for 5 seconds

I only get down to about 17mA current draw during Deep Sleep with my D1 Mini due to the horrid linear regulator used on this cheap clone board plus the CH340 UART <> USB chip. A Holtek HT7833 regulator would get lower as the quiescent current is better on their parts.

devyte · 2019-12-29T18:42:43Z

Per @Tech-TX:
Closing due to unable to reproduce.

Erriez · 2020-10-09T20:25:06Z

@Tech-TX, @devyte: Today I received a batch of Wemos D1 mini's and two of them failed to wake-up as well. I tried different resistor values and wires between D1 (GPIO15) and RST, but did not make sense.

After a lot of wasting time, I found this interesting thread:
#6007 (comment)

With this sketch I'm able to wake the Wemos D1 mini:

#include "ESP8266WiFi.h"
extern "C" {
#include <user_interface.h>
}

#define ets_wdt_disable ((void (*)(void))0x400030f0)
#define ets_delay_us ((void (*)(int))0x40002ecc)

#define _R (uint32_t *)0x60000700


void nk_deep_sleep(uint64_t time)
{
    ets_wdt_disable();
    *(_R + 4) = 0;
    *(_R + 17) = 4;
    *(_R + 1) = *(_R + 7) + 5;
    *(_R + 6) = 8;
    *(_R + 2) = 1 << 20;
    ets_delay_us(10);
    *(_R + 39) = 0x11;
    *(_R + 40) = 3;
    *(_R) &= 0xFCF;
    *(_R + 1) = *(_R + 7) + (45*(time >> 8));
    *(_R + 16) = 0x7F;
    *(_R + 2) = 1 << 20;
    __asm volatile ("waiti 0");
}

void setup()
{
    delay(1000);

    nk_deep_sleep(2000000);
}

void loop()
{
}

However, I've no idea about the internals and how to wake with or without RF enabled. According to the thread, it looks like an issue with newer ESP-12F. Do you have more information on this?

devyte · 2020-10-09T22:40:17Z

No new info. The only 2 known workarounds are the code above and the 47K pullup on MISO, and even that doesn't help all cases.

It would be interesting if somebody could reverse engineer the sdk deep sleep calls and figure out the difference vs the above code, especially the wakeup param. We could then implement our own version of deep sleep.

studioant · 2020-10-09T23:23:59Z

@devyte, I agree. And I think the person to do it is @nikolz0. He wrote that function above. Problem is, nk_deep_sleep consumes ~2mA after cutting the LDO and UART 3V3 trace, so it's nowhere near "deep sleep". If anything, nikolz0 has created a working "light sleep'. I'm trying to pick their brain to comment the code so we know whats happening, and if they have time, try and figure out the modification required to make it go "deep"

studioant · 2020-10-09T23:27:00Z

@Erriez , according to the author, the line *(_R + 4) = 0; disables WiFi.
In light of this information the author has provided, we can assume this person is certainly capable of solving this issue once and for all. We need this hero in our lives

devyte · 2020-10-10T01:46:25Z

@studioant that sounds like some pull-up resistor somewhere to me. Or a resistor voltage divider.

studioant · 2020-10-10T05:48:29Z

@devyte You might be right, I found this Mux Register info:

I'm not sure what the hex should be for "Pull-down during sleep" but it looks like somewhere after 0x60000804.

This is on esp8266 wiki: https://github.com/esp8266/esp8266-wiki/wiki/Memory-Map

@nikolz0 defines his register variable _R starting at this hex value, so he's manipulating the RTC config registers, but i can't find the register doc on this... where's the include/eagle_soc.h header file?

Erriez · 2020-10-10T14:03:01Z

Thanks for looking into this. I checked my stock and discovered multiple ESP8266 chips which does not wake up after deep sleep.

@studioant You're right: The current consumption is 2.5mA with the magic workaround sketch. That explains why my batteries are drained quickly... 😢

@devyte

It would be interesting if somebody could reverse engineer the sdk deep sleep calls and figure out the difference vs the above code, especially the wakeup param. We could then implement our own version of deep sleep.

I'd like to summarize some facts about this issue, because I found a lot of wrong assumptions and discussions on other threads:

This problem has been reported on newer ESP12F chips only.
This repository uses the latest Espressif NONOS SDK version "2.2.2-dev(38a443e)", but needs volunteers to port it to the latest NONOS SDK version 3.0.2.

Please correct me if I'm wrong.

Did someone already try the latest NONOS SDK version 3.0.2 to see if deepSleep works?

nikolz0 · 2020-10-10T14:45:16Z

Hi, try downloading this test from the address 0x0000, terminal 74880, deepsleep 12 sec.

testnk.zip

Erriez · 2020-10-10T14:51:33Z

@nikolz0 The output is:


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

load 0x40100000, len 580, room 16 
tail 4
chksum 0x62
load 0x3ffe8004, len 268, room 4 
tail 8
chksum 0x2e
csum 0x2e

testnk deepsleep

...
Same output after 12 seconds reset

It resets every ~12 seconds and the power consumption is 170uA (same to other WeMos D1 Mini's)... Eh... this sounds promising. Can you share the contents of this bin?

nikolz0 · 2020-10-10T15:49:33Z

Hi,
This is code without the SDK, only the deepsleep function . Made for checking ESP.
You can do the same in your program using the SDK function
system_deep_sleep_instant(12000000);
In the user_init function, call
system_deep_sleep_set_option(2);

fsommer1968 · 2020-10-10T17:28:30Z

* This repository uses the latest Espressif NONOS SDK version "2.2.2-dev(38a443e)", but needs volunteers to port it to the latest NONOS SDK version 3.0.2.

Arduino for 8266 does not support NONOSSDK 3.x, there is a long thread in the issues section about this.

devyte · 2020-10-10T17:56:26Z

@Erriez you are correct: we're still on NONOS sdk 2.x, and we want to migrate to 3.x. We've had a few attempts, but walls have been hit. Volunteers in this case means either someone who has a deeper understanding of how our core interfaces with the sdk, or someone who is willing to stick around long term and aquire that understanding in time.
I outlined somewhere what I think needs to be done at high level.

Erriez · 2020-10-10T19:06:51Z

@nikolz0

This is code without the SDK, only the deepsleep function .

I don't know how to build it without SDK. In my understanding include file user_interface.h is always required to access the Espressif SDK, right?

In the user_init function, call system_deep_sleep_set_option(2);

For this repository, I found a preinit() function which is called from user_init() and added the system_deep_sleep_instant(12000000); to setup().

It wakes up twice as I encountered before:

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

void preinit() {
    system_deep_sleep_set_option(2);
}
}

void setup() {
    // Does not wake:
    system_deep_sleep_instant(12000000);
}

void loop() {
}

Output:

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3584, room 16 
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
~ld

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

No further resets...

The load ... is missing in the serial output and looks like not starting the sketch.

Any Idea?

Tech-TX · 2020-10-10T23:47:37Z

@Tech-TX, @devyte: Today I received a batch of Wemos D1 mini's and two of them failed to wake-up as well. I tried different resistor values and wires between D1 (GPIO15) and RST, but did not make sense.

After a lot of wasting time, I found this interesting thread:
#6007 (comment)

...

However, I've no idea about the internals and how to wake with or without RF enabled. According to the thread, it looks like an issue with newer ESP-12F. Do you have more information on this?

@Erriez I read reports over on esp8266.com about Deep Sleep 'zombie mode', but never saw it here at home. Where did you get the D1 Mini boards from? I'd like to be able to duplicate your results here.

For the GPIO16 > RST connection I use either a Schottky or germanium diode. The cathode of the diode (the stripe) goes to GPIO16, and the anode goes to RST. Using a resistor could effect the pulse getting to the RST line of the CPU, and exactly what it does depends on what they've done underneath the can on the ESP-12F. I've seen 4 different RF shields from different companies in China, including one that has copied the Lolin logo (although I doubt Lolin made them.) In one thread I read someone removed the RF shield and found a resistor in series between the RST pin on the module and the RST pin on the CPU. Doing that can cause problems, especially if you're using a resistor to connect GPIO16 to RST. The actual reset pulse might get attenuated to the point where the chip won't see it.

studioant · 2020-10-11T01:53:32Z

@Tech-TX , The issue is clearly deeper than this, you even commented in February in the original thread.

In one thread I read someone removed the RF shield and found a resistor in series between the RST pin on the module and the RST pin on the CPU.

Yeah, the thread you literally included in this comment? There are even recorded attempts (in said thread) to remove the resistor, bypass it, etc to no avail. Obviously, not gonna help.

@nikolz0 explained it in that thread, plus he created a (almost spot-on) solution. It just needs further enhancement, atm it's allowing the ESP to draw too much current during deep sleep (I understand you have recorded lower current draw, but I have now recorded 2mA consistently across several bare-bone ESP's )

@nikolz0 - Do you have a copy of the RTC register manual? I can't seem to find it anywhere. It would be great to understand better what your function is doing. TIA

nikolz0 · 2020-10-11T04:28:03Z

Hi,
I connect the GPIO16 and RST using a Schottky diode.
So I have no problem with the versions of the ESP-12.

nikolz0 · 2020-10-11T05:01:38Z

Hi,
Are you using Wemos or ESP-12?
is testnk working correctly?
testnk.zip
There is an automatic mode "vemos" control. I believe that it interferes with deep sleep mode.
I write in C, but I'll try to tell you something.
try this:
`
#include <ESP8266WiFi.h>
void setup() {
Serial.begin(115200);
Serial.setTimeout(1000);
while(!Serial) { }
}

void loop() {
Serial.println("Test");
delay(1000);
ESP.deepSleep(12000000);
}
`

nikolz0 · 2020-10-11T05:21:49Z

#3408

Tech-TX · 2020-10-11T15:12:04Z

I'm not sure what you're linking to @nikolz0 as I think that thread has been resolved.

If there's a specific post that's relevant, you can pick it with the three dots to the right of the post title bar,

Tech-TX · 2020-10-11T18:15:11Z

FWIW if I run nicolz0's test binary it works as expected, and I get around 15uA sleep current.

If I run that test code that Erriez linked above it only sleeps for 1.4ms, no matter what I set 'time' to in the nk_deep_sleep(time) call. It's sleeping so briefly that I can'[t measure the current, but it looks like it's on the order of 2 to 4mA.

Erriez · 2020-10-11T18:53:37Z

@Tech-TX

@Erriez I read reports over on esp8266.com about Deep Sleep 'zombie mode', but never saw it here at home. here did you get the D1 Mini boards from? I'd like to be able to duplicate your results here.

I've purchased multiple batches from different shops and I did not mark them. My last batch came from Aliexpress Sincere Company Store Wemos D1 Mini.
Only one of them cannot wake after deepsleep, others work as expected. I cannot find any differences in PCB, so it is concerning that nobody knows which version will be shipped.

The cathode of the diode (the stripe) goes to GPIO16, and the anode goes to RST

I could not get it stable with different resistors and germanium diode as you suggested. A software solution would be appreciated and testnk.bin is the evidence that this is not hardware related, just by using a simple wire between GPIO15 and RST.

@studioant There are different deepsleep issues, but I could not find a solution for this problem.

@nikolz0

Are you using Wemos or ESP-12?

Yes, this is a Wemos ESP12F D1 Mini (lite) with 4MB flash. That's the reason why I posted on this thread, but seems more related to newest ESP12F batches.

is testnk working correctly? testnk.zip

Yes, the testnk is the only binary which works on my device with a simple 0 Ohm wire between RST and GPIO16 ~~(D1)~~ Update: (D0): Wake works and 170uA in deep sleep. So now I'd like to know how to port this to my application by using this repository.

There is a magic difference between your binary which works and ESP.deepSleep(12000000); in this repository which does not work on several of my devices:

SDK version: 2.2.2-dev(a58da79)
Wake

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

=> Does not start the sketch.

I'll hookup my scope to measure the RST pulse and measure the current...

Erriez · 2020-12-07T20:56:08Z

@Tech-TX

if you still have any modules that don't wake properly

Yes, I've several unstable ESP8266 devices which cost me too much time now. Even in the field some devices can hang forever unexpectedly and draining the battery. My fallback is the old good ATMega328 with STX882 433MHz transmitter to send sensor data to a base station connected to Ethernet. This works reliable for years and the lifetime of a 18650 battery is much higher. The price does not matter, so I try to revive my old projects.

This thread has gotten so ridiculously long that I can't tell if you've already attempted this.

Correct. In the mean time Travis CI dropped free support, so I've a headache to move my Arduino Github projects away to another free continues integration build server. To be honest, I'd like to continue with my projects and stop this investigation. I hope you understand.

doharadam · 2020-12-08T13:23:08Z

Thank you all for the hard work put into this investigation. It took me many days to struggle with this deep sleep issue until I found this thread.
I use Wemos D1 mini (copys maybe) for my project. Same batches different behaviours with the deep sleep.
The workaround code bí @nikolz0 mentioned above works perfectly for me too.

A picture I wanted to share. I found that I seem to have 3 types of boards and the one on the top works with the original deep sleep function, the below 2 don't. Not sure what those pieces do, but at least I differentiate them by looking at it.

nikolz0 · 2020-12-08T13:42:24Z

I recommend using nodemcu only for debugging programs without sleep mode.
It is better to put ESP-12 in working projects.
The nodemcu module (Wemos ) can be easily replaced with an ESP-12, three resistors, one Schottky diode, two buttons, and any USB-UART adapter. In this case, only one adapter is needed for any number of ESP-12.

Tech-TX · 2020-12-10T03:19:24Z

@doharadam the top of the boards would tell more. The differences on the bottom don't matter. The middle module for instance is using the CH340C USB chip which has an internal crystal, so they left off the external crystal. The only real difference I see is that the bottom two boards have more greyish silkscreen, so likely came from the same low-quality PCB fab. I'll bet the ESP-12F modules on the bottom two are identical, and the RF shield is slightly different on the top one. It's possible it's all the same no-name clone ESP-12F module. In Erriez' case, some of his boards work, some don't, and they all appear to be from the same batch. It's something that's right on the edge of working properly.

TD-er · 2020-12-10T09:25:35Z

And what may be the parameter to tip them over the edge (either way)?
shape/timing of the wake pulse? Delay on the enable pin? Max current of the voltage regulator? Or something else (or all of them :) ) ?

Tech-TX · 2020-12-12T16:48:20Z

Don't know, as I don't have anything here that goes zombie. If I knew for sure what was breaking with those cheap clone ESP-12F modules I'd mark this zombie mode thread as 'solved' and move on. I've asked a couple of the eBay suppliers if they had any returned boards that the buyer complained wouldn't come out of Deep Sleep, but they didn't get them back, only sent replacements. I don't want to buy a boatload of cheap junk merely to see if I can get one or two that don't work for troubleshooting purposes.

So far we've had:

replace the flash and it works (might be the default 75% pin drive in the XTX chips)
add a 47K pull-up on MISO (GPIO12) and it works (debatable... doesn't make any sense)
use a better power supply (could also be a dropout across the Schottky diode on the USB input)
use a wire / Schottky / low value resistor for the GPIO16 > RST pin

The only time I had problems was when I used a resistor to connect GPIO16 > RST. Most likely the EXT_RSTB pin wasn't going low enough to be detected due to the series 470 ohm resistor inside the module. With a wire or a Schottky / germanium diode, it always works for me.

I've tested on the following boards and modules, 2 to 3 of each type:
AI Thinker ESP-12F modules
AI Thinker ESP-12S modules
AI Thinker ESP-07S modules
DOIT ESP-12F module on a clone D1 Mini (several different boards, as I have > 30 of them)
clone NodeMCU DevKit v0.9 with a DOIT ESP-12F module onboard (have 2)
clone D1 Mini Pro (have 1)
WeMos NodeMCU LUA (have 1, possibly authentic and not a clone)
DOIT ESP-M3 (ESP8285) (have 10)
clone ESP-01S (that was a pain in the @ss....) (have 1)

Elsewhere people have complained of Deep Sleep issues with ESP-12F modules on D1 Mini boards that have DOITING on the RF shield. I don't have any of these and can't confirm. It should be the same as the DOIT modules (same company) but possibly they used a different Flash manufacturer on these newer modules. Could also be user error.

nikolz0 · 2020-12-13T04:36:19Z

You can put a monovibrator between GPIO16 and RST and significantly increase the pulse duration.
You can set the tpl51xx timer and forget about this problem, get a sleep current of 3 ua instead of 20 ua.

Tech-TX · 2020-12-13T12:08:00Z

I don't believe zombie mode relates to the pulse at EXT_RSTB. When my modules have a poor pulse, they display the 'ets_main.c' message, not zombie mode. If the RST pulse doesn't go low enough to be detected as LOW, arrives too late or is too brief, you should get the 'ets_main.c' as the boot code can't determine which bin to load.

3gyptian · 2021-02-17T23:09:59Z

So I've got 5 zombies that arrived this week from the Amazon. And it's from the same seller that provided me 10 of the same wemos clones earlier this year .. and that continue to work fine when driving the deep sleep.

I've tried various diode's, resistors these new ones I get the same message as others right after the first boot:

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

It's been a couple months since the last post on this. Anyone had any luck or ideas on a workaround? If someone wants to dig still deeper I'm happy to mail you a couple.

Here's what I ordered:
https://www.amazon.ca/gp/product/B076F52NQD/ref=ox_sc_act_title_1?smid=AIE2SCY0RQX6M&psc=1

I thought I had a win with nk_deep_sleep() but alas only light sleep as many milliamps of current draw. The testnk.bin as supplied by @nikolz0 worked perfectly. How can I compile with that in a way that system_deep_sleep_instant() acutally works??

nikolz0 · 2021-02-18T03:56:34Z

Hi,
As a working hypothesis, I will assume the following.
This problem does not exist in ESP12. Only the ESP12x has a problem.
The problem is independent of GPIO16 and is related to SPI control signals.
The problem depends on the size of the code being loaded when waking up.

Tech-TX · 2022-08-05T00:04:22Z

For the final analysis and explanation of what Deep Sleep Zombie mode is, please see this:
#6007 (comment)

In short: if you have boards that go Zombie and adding a resistor (that I never understood doing anything) doesn't help, then you need to toss those boards and buy from a different vendor. DO try to make sure that the top of the RF shield doesn't look identical to bad boards you already have.

cc13com · 2024-07-19T08:33:50Z

@Tech-TX, @devyte: Today I received a batch of Wemos D1 mini's and two of them failed to wake-up as well. I tried different resistor values and wires between D1 (GPIO15) and RST, but did not make sense.

After a lot of wasting time, I found this interesting thread: #6007 (comment)

With this sketch I'm able to wake the Wemos D1 mini:
#include "ESP8266WiFi.h"
extern "C" {
#include <user_interface.h>
}

#define ets_wdt_disable ((void (*)(void))0x400030f0)
#define ets_delay_us ((void (*)(int))0x40002ecc)

#define _R (uint32_t *)0x60000700


void nk_deep_sleep(uint64_t time)
{
    ets_wdt_disable();
    *(_R + 4) = 0;
    *(_R + 17) = 4;
    *(_R + 1) = *(_R + 7) + 5;
    *(_R + 6) = 8;
    *(_R + 2) = 1 << 20;
    ets_delay_us(10);
    *(_R + 39) = 0x11;
    *(_R + 40) = 3;
    *(_R) &= 0xFCF;
    *(_R + 1) = *(_R + 7) + (45*(time >> 8));
    *(_R + 16) = 0x7F;
    *(_R + 2) = 1 << 20;
    __asm volatile ("waiti 0");
}

void setup()
{
    delay(1000);

    nk_deep_sleep(2000000);
}

void loop()
{
}
However, I've no idea about the internals and how to wake with or without RF enabled. According to the thread, it looks like an issue with newer ESP-12F. Do you have more information on this?

Hi, I have an ESP8266 with the issue not waking up from sleep mode. With the code above it works. The ESP is sleeping for 26-32 seconds.

How can I increase this time to 15 or 30 minutes? I tried to increase the number in nk_deep_sleep(2000000); but is the same short sleeping time. Any idea please?

TD-er · 2024-07-19T09:15:00Z

No idea what value is stored at address (_R + 7).
Maybe you're running into some 32-bit overflow when changing this 2 million into 120 million? (this 120 mln value should still fit perfectly fine in a 32-bit int)
Does the sleep time change if you only make small(er) changes to this 2 million value?
For example if you set it to 1 million, or 4 million?

nikolz0 · 2024-07-19T09:59:01Z

static uint32 *rtc= (uint32 )0x60000700;
void nk_deepsleep(uint32 time_us)
{ rtc[0]= 0x30;
rtc[1]= rtc[7] + 5;
rtc[3]= 0x10010;
rtc[4]=0;
rtc[6]= 8;
rtc[17]= 4;
rtc[2]=1<<20;
ets_delay_us(10);
rtc[0]&=0xFCF;
rtc[0]=0;
rtc[1]=rtc[7] + (45(time_us>>8));
rtc[3]=0x640C8;
rtc[6]=0x18;
rtc[16]=0x7F;
rtc[17]=0x20;
rtc[39]=0x11;
rtc_[40]=0x03;
rtc[2]=1<<20;
__asm volatile ("waiti 0");
}

// nk_deepsleep(300*1000000); //300 sec

TD-er · 2024-07-19T10:33:07Z

OK, so the time is in usec?
If so, then you should for sure add ull to the value you use as an argument.
I think the value will overflow at around 24433 seconds. (depending on what is stored in rtc[7])
That's about 6.7 hours

nk_deepsleep(24433ull*1000000ull);

This will probably overflow, but you get the idea.

Found value by calculating this:
((2^32 / 45) * 256) / 1000000 = overflow value in seconds

nikolz0 · 2024-07-19T15:11:26Z

Hi,
The sleep time for the module is set in microseconds. According to the ESP8266 SDK, the maximum time you can put the module to sleep is 4,294,967,295 µs, which is approximately 71 minutes.

nikolz0 · 2024-07-19T15:13:50Z

If you need more, use an external timer TPL511X or C005

nikolz0 · 2024-07-19T15:43:16Z

You can also run the nk_deepsleep function in a loop and save the loop variable to RTC RAM.

jeskata · 2024-12-30T18:02:13Z

Joining this thread also, I have two zombie ESP-07S, ordered in the autumn from Aliexpress. Same strip of modules so obviously they were both flawed. Also got 26MHz on GPIO0.
Tinkering around with connecting another ESP8266 inbetween GPIO16 and Reset, I made it pull the output to the zombie Reset when GPIO16 goes low. But it takes two dips of 1ms, and atleast 45ms inbetween, I set it to 50ms to be sure.

miceno · 2025-01-05T00:45:14Z

static uint32 *rtc= (uint32 )0x60000700; void nk_deepsleep(uint32 time_us) { rtc[0]= 0x30; rtc[1]= rtc[7] + 5; rtc[3]= 0x10010; rtc[4]=0; rtc[6]= 8; rtc[17]= 4; rtc[2]=1<<20; ets_delay_us(10); rtc[0]&=0xFCF; rtc[0]=0; rtc[1]=rtc[7] + (45(time_us>>8)); rtc[3]=0x640C8; rtc[6]=0x18; rtc[16]=0x7F; rtc[17]=0x20; rtc[39]=0x11; rtc_[40]=0x03; rtc[2]=1<<20; __asm volatile ("waiti 0"); }

// nk_deepsleep(300*1000000); //300 sec

I have several Wemos D1 mini (clone), bought at different times and providers. All of them are unable to wake up from deep sleep with the ESP8266 library. But @nikolz0 code works on them!!! So thank you very much for all of you that created this code.

I found some typos and I think I solved them, will you @nikolz0 please check if this code is right?


static uint32 *rtc = (uint32 *)0x60000700;

void nk_deepsleep(uint32 time_us) {
  rtc[0] = 0x30;
  rtc[1] = rtc[7] + 5;
  rtc[3] = 0x10010;
  rtc[4] = 0;
  rtc[6] = 8;
  rtc[17] = 4;
  rtc[2] = 1 << 20;
  ets_delay_us(10);
  rtc[0] &= 0xFCF;
  rtc[0] = 0;
  rtc[1] = rtc[7] + (45 * (time_us >> 8));
  rtc[3] = 0x640C8;
  rtc[6] = 0x18;
  rtc[16] = 0x7F;
  rtc[17] = 0x20;
  rtc[39] = 0x11;
  rtc[40] = 0x03;
  rtc[2] = 1 << 20;
  __asm volatile("waiti 0");
}

// nk_deepsleep(300*1000000); //300 sec

miceno · 2025-01-06T00:21:48Z

I also realized that the code posted by @nikolz0 is not accurate on the way the deep sleep delay is calculated. If I configure a 10 seconds delay, it takes 9.18-9.2 seconds. I think there is some kind of accuracy related to the conversion of the time_us to the binary values.

TD-er · 2025-01-06T00:34:04Z

Is it a constant offset or a factor?

miceno · 2025-01-07T00:48:58Z

Not sure about it... it is around 8% of the setup delay for a 10 seconds delay, I have not tested it thoroughly for other delays. I will check with other delays (30s, 60s) and I will provide the details when I have the data.

jeskata · 2025-01-07T13:44:47Z

Think I have found an issue with nk_deepsleep. If not activating wifi, it only wakes up three or four times, and then fails. Can somebody try and verify?
Also when activating wifi, it failed after 15 wakeups.

nikolz0 · 2025-01-07T15:39:24Z