Wemos d1 mini not waking up #6318
Comments
|
Just curious, why are you using such a slow baudrate for the serial port? |
|
Set the baud rate to 74400 and test again and post the new logfile if still required. |
|
Or maybe use |
|
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? |
|
@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. |
|
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. |
|
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:
<repeats every 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.
|
|
Per @Tech-TX: |
|
@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: 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? |
|
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. |
|
@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" |
|
@Erriez , according to the author, the line *(_R + 4) = 0; disables WiFi. |
|
@studioant that sounds like some pull-up resistor somewhere to me. Or a resistor voltage divider. |
|
@devyte You might be right, I found this Mux Register info: 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? |
|
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... 😢
I'd like to summarize some facts about this issue, because I found a lot of wrong assumptions and discussions on other threads:
Please correct me if I'm wrong. Did someone already try the latest NONOS SDK version 3.0.2 to see if deepSleep works? |
|
Hi, try downloading this test from the address 0x0000, terminal 74880, deepsleep 12 sec. |
|
@nikolz0 The output is: 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? |
|
Hi, |
Arduino for 8266 does not support NONOSSDK 3.x, there is a long thread in the issues section about this. |
|
@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 don't know how to build it without SDK. In my understanding include file
For this repository, I found a 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: The Any Idea? |
...
@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. |
|
@Tech-TX , The issue is clearly deeper than this, you even commented in February in the original thread.
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 |
|
Hi, |
|
Hi, void loop() { |
|
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, |
|
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. |
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.
I could not get it stable with different resistors and germanium diode as you suggested. A software solution would be appreciated and @studioant There are different deepsleep issues, but I could not find a solution for this problem.
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.
Yes, the testnk is the only binary which works on my device with a simple 0 Ohm wire between RST and GPIO16 There is a magic difference between your binary which works and I'll hookup my scope to measure the RST pulse and measure the current... |
I will agree that 5.6K for the pull-up on Erriez' board is too strong. I would have used a 12K. The datasheet says that there is an internal pull-up resistor on EXT_RSTB, but it doesn't specify the value. I assume it is a weak PFET and cannot be measured externally easily. The other weak PFETs are around 50K, from measurements I made.
@nikolz0 I'm not sure what schematic you are looking at... the one I posted has C5 on EXT_RSTB, with a 470 ohm resistor going out to the RST pad on the ESP-12F module. Connecting GPIO16 to that RST pad works fine, either with a wire or a Schottky diode. |
|
In the above diagram, C5, R5, and R4 at the RTC input create a pulse delay at the RTC input. |
|
@Erriez I may finally have an answer for your problem, if you still have any modules that won't wake up properly. During /EXT_RSTB and for ~35ms after EXT_RSTB rises, GPIO15 is being driven to a weird level: 0.70V on my board. That's uncomfortably close to the 'undefined' input range for the pins (0.25xVIO to 0.75xVIO). If GPIO15 is seen as HIGH during the boot mode detection, then the chip goes into SDIO/SPI mode instead of Flash boot. I've verified that two different modules are doing the same thing (0.7V output on GPIO15). What I think may be happening is that your modules are a little bit above that, and the chip sees it as SDIO mode. SDIO could be your 'zombie mode' after Deep Sleep. I'd like to recommend that you try a stronger pull-down resistor on GPIO15 to see if your modules wake properly. 5K or so should be sufficient. On my gutted D1 Mini, I verified the pull-down on GPIO15 is 10K (9.9K measured). I wrote a quick little test, setting all GPIOs to OUTPUT, HIGH, then ran Deep Sleep and woke the chip up again. The test ONLY sets the outputs on power-up reset or external reset; they're unchanged after Deep Sleep Wake. This first capture is with ESP.deepsleep(0), woken by an external reset: This second capture is with ESP.deepsleep(5e6), woken by GPIO16 with a Schottky diode connection: For both captures, the scope has a 1meg pull-up & 1meg pull-down so I can see if the pin tristates. The 1meg resistors plus the load of the scope will be somewhere around 0.83V if it's tri-stated. Since the pins are in 2uA drive (550K equivalent) during Deep Sleep, that pull-up/pull-down arrangement results in ~ 2.67V measured on the pins. When it comes out of Sleep it's 3.3V, as the 12mA OUTPUT HIGH drive predominates. One other interesting item: the CPU is waking up ~2ms before GPIO16 drops low at the end of Deep Sleep. You can see it in the other pin states below, all done with ESP.deepsleep(5e6) and the same 1meg pull-up/pull-down: I haven't seen this described in the Espressif docs, or in posts by anyone else. Deep Sleep Wake actually begins BEFORE GPIO16 drops. GPIO16 is not the trigger, it's being done internally by the RTC. GPIO16 seems to be letting the chip know that it's returned from Deep Sleep by briefly holding the EXT-RSTB pin low while it's already coming awake.
|
Hmm that's interesting. The use case I'm thinking off is to have GPIO-16 and RST connected via an external switch to allow/prevent the unit to wake up from deep sleep. But if the ESP then may somehow enter the flash mode and remain in that mode for a while draining the battery. |
|
That's easy: you get the ets_main.c message, because it doesn't know what woke it up or where to go next. You'll get the same message if you use a resistor to connect GPIO16 to EXT_RSTB and the value is too high, as the EXT_RSTB pin never goes low enough to be recognized as a Deep Sleep Wake; the chip is awake, but can't figure out why.
|
|
@Tech-TX Thanks for your deep investigation.
I remember that I tried a pull-down resistor before on GPIO15. I've built it up on a breadboard and tried different pull-down resistors, including a 2k2, 4k7 and 10k, but all with the same result: 17:55:20.421 -> ets Jan 8 2013,rst cause:2, boot mode:(3,6)
17:55:20.421 ->
17:55:20.421 -> load 0x4010f000, len 3584, room 16
17:55:20.421 -> tail 0
17:55:20.421 -> chksum 0xb0
17:55:20.421 -> csum 0xb0
17:55:20.421 -> v2843a5ac
17:55:20.421 -> ~ld
17:55:21.650 ->
17:55:21.650 -> ets Jan 8 2013,rst cause:2, boot mode:(3,6)
17:55:21.650 ->
No further outputFor my specific device, I think the flash can be a problem. I wish I had better news. |
|
@Erriez I may have something else for you. I've been going back and forth between different designs, old Espressif docs and demonstrator boards, and current Espressif docs. Their oldest demo board ESP-LAUNCHER has a 5K pull-up on RST and a 100pF cap to ground, with a jumper block to GPIO16 for Deep Sleep (a wire). Currently they recommend a 0.1uF cap to ground on RST with a 10K pull-up. They also suggest a .1uF cap on the CH_PD pin. However, that violates their sequencing of power, then CH_PD, then RST rising. I'd boost the RST resistor to 20K with a .1uF cap, which is well above the 5.6K you have. It also means that series 470 ohm resistor in the RST line will allow the signal at the EXT_RSTB pin to more closely approach ground. Old modules didn't have the 470 ohm series resistor on the reset logic going to the RST pin on the module, that came in with the ESP-12F. AI Thinker and Doit.am seem to both be using a 1uF cap on the RST line, which doesn't make sense as that adds a reel of 1uF caps when they're placing the board (they already have a 0.1uF cap on VCC). The only mention of timing of RST that I've found is a minimum of 200us for an external reset to be recognized. Gee, that's an eternity for a chip running at 80MHz. That 200uS is likely because the CPU slows way down in Light Sleep, but I haven't tried to gauge it's speed in Light Sleep yet. Reading everything, I think someone effed up a few years ago and didn't notice the leading period on the reset cap value, and it's stuck ever since, and everyone else copied it. That doesn't explain why my modules work and yours don't, but it's something where everyone has gone awry. I'll draw up a quick schematic tomorrow. It's late and I'm tired tonight. |
Is it somewhere documented that the clock speed is lowered in light sleep? |
|
Espressif says the CPU clock is off during Light Sleep and Deep Sleep both, but I measured a variable difference of a few thousand micros() ticks across Light Sleep. |
|
Say @Erriez ? I have something else to try, if you still have any modules that don't wake properly. It's not a 'fix', more a work-around. Connect the CH_PD (EN) pin on the module to the RST pin (not the GPIO16 side) on the module. On my D1 Mini boards there's a pull-up resistor for CH_PD on the bottom near the pull-up resistor for RST that's convenient to solder to, unknown how your boards are laid out but I presume something similar as the pins on the ESP-12F are near neighbors. I ran it here with a Deep Sleep loop, and although it's showing rst cause:1 boot mode(3,6) instead of rst cause:2 boot mode(3,6) it seems to be working OK. That's not as comforting as it may seem since mine have never emulated The Walking Dead, but it appears to work in a modified Deep Sleep that way. It won't help you if you're planning on using the RTC RAM to store things during Deep Sleep, as dropping CH_PD should wipe the RAM. This thread has gotten so ridiculously long that I can't tell if you've already attempted this. By the way, I tried putting my D1 Mini in 'self test' by booting with GPIO15 high, and all I get is a "Waiting for host" message. I haven't seen anyone mention that, so zombie mode isn't self test. |
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.
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. |
|
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. 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. |
|
I recommend using nodemcu only for debugging programs without sleep mode. |
|
@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. |
|
And what may be the parameter to tip them over the edge (either way)? |
|
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:
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: 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. |
|
You can put a monovibrator between GPIO16 and RST and significantly increase the pulse duration. |
|
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. |
|
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: 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?? |
|
Hi, |
|
For the final analysis and explanation of what Deep Sleep Zombie mode is, please see this: 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. |
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 |
|
No idea what value is stored at address |
|
static uint32 *rtc= (uint32 )0x60000700; // nk_deepsleep(300*1000000); //300 sec |
|
OK, so the time is in usec? This will probably overflow, but you get the idea. Found value by calculating this: |
|
Hi, |
|
If you need more, use an external timer TPL511X or C005 |
|
You can also run the nk_deepsleep function in a loop and save the loop variable to RTC RAM. |
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");
}
The text was updated successfully, but these errors were encountered: