Arduino: ESP.deepSleep hangs after wakeup - ESP12F (Working on older chips)

[petrilloa]

Basic Infos

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

Platform

• Hardware: ESP-12F - ESP8266MOD
• Core Version: SDK:3.0.0-dev(c0f7b44)/Core:2.5.0
• Development Env: Arduino IDE 1.8.5
• Operating System: Windows 10

Settings in IDE

• Module: Generic ESP8266 Module
• Flash Mode: QIO (try DIO also)
• Flash Size: 4MB
• lwip Variant: v1.4|v2 Lower Memory|Higher Bandwidth (try all)
• Reset Method: none
• Flash Frequency: 40Mhz
• CPU Frequency: 80Mhz
• Upload Using: SERIAL
• Upload Speed: 115200

Problem Description

A few months ago, we start developing a custom PCB using ESP8266, ESP12F from AI.

esptool.py --port COM14 flash_id
esptool.py v2.6
Serial port COM14
Connecting...
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: cc:50:e3:04:37:7e
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

After successfully deploy 100 boards, we receive a new batch from a distributor on China. The new chip, looks the same as the old one, except it has an Expressif logo instead of AI logo.

Then, using esptool, we check that was manufactured by other factory

esptool.py --port COM14 flash_id
esptool.py v2.6
Serial port COM14
Connecting...
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: dc:4f:22:5e:93:23
Uploading stub...
Running stub...
Stub running...
Manufacturer: 0e
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

The PCB was build using all the following design rules and experiences from Espressif, blogs, etc.
Example:
https://www.instructables.com/id/ESP-12F-ESP8266-Module-Minimal-Breadboard-for-Flas/

Also, we using several recomendations from videos of Andreas Spiess. @SensorsIOT and read post by @igrr.

• Power: 3 x AA Batteries (4,5v)
• MCP1700 LDO for 3,3v

• Capacitor filters: 1000uF and .1uf - VCC to GND

• GPIO0 - pull up 10k resistor - VCC

• GPIO2 - pull up 10k resistor - VCC

• GPIO15 - pull down 10k resistor - GND

• EN - pull up 10k resistor - VCC

• RESET - pull up 10k resistor - VCC

• HARD WIRED GPIO16 to RESET pin.

The sensor, reads a value, then enter a deepSleep cycle until wakeups.
All was working fine in more than 100 pcb!!!

_After receiving the new batch, with the same PCB and CODE, the ESP hangs after wake up._

We already try 10 chips off the new bach, all have the same issue.

Trying this simple sketch:

MCVE Sketch

/**
 * An example showing how to put ESP8266 into Deep-sleep mode
 */

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

#define STATUS_LED  2   

void setup() {


  pinMode(STATUS_LED, OUTPUT);

  Serial.begin(74880);
  Serial.setTimeout(2000);

  digitalWrite(STATUS_LED, false);

  // Wait for serial to initialize.
  while(!Serial) { }

  Serial.print("Chip ID: ");
  Serial.println(ESP.getChipId());

  rst_info *rinfo = ESP.getResetInfoPtr();

  Serial.print(String("\nResetInfo.reason = ") + (*rinfo).reason + ": " + ESP.getResetReason() + "\n");

  Serial.println(".");  
  Serial.println("I'm awake.");

  delay(1000);

  Serial.println("Going into deep sleep for 3 seconds");
  ESP.deepSleep(3e6);    

  delay(5000);
}

void loop() {
}

Debug Messages ON WORKING CHIP

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld
Chip ID: 276350

ResetInfo.reason = 5: Deep-Sleep Wake
.
I'm awake.
Going into deep sleep for 3 seconds

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld
Chip ID: 276350

ResetInfo.reason = 5: Deep-Sleep Wake
.
I'm awake.
Going into deep sleep for 3 seconds

Debug Messages ON NOT WORKING CHIP

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld
Chip ID: 6198051

ResetInfo.reason = 5: Deep-Sleep Wake
.
I'm awake.
Going into deep sleep for 3 seconds

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

Hangs/Freeze until power down, or hard reset (button from RESET to GND).

Things we already try

• Erase all flash memory using esptool.py
• Changing firmware version from ESP CORE (2.0.0, 2.1.0, 2.4.0, 2.5.0)
• Changing values of pullup resistors (10k, 4k7, 1k)
• Using a stable protoboard 5v power bank
• Connection from RESET to GPIO16
  -Hardwire
  -RESISTOR 470, 1k, 10
  -Using a diode, schottky
  -Adding aditional 10pF capacitor from RESET to GND

Similar ISSUES

5892

2768

https://github.com/universam1/iSpindel/issues/59

Please HELP US!!! Can be a faulty batch?

[fsommer1968]

Hi,
although it would not solve right you problem, I recommend to set always the correct pinmode for GPIO16 during setup() which is in my opinion (D0 refers to GPIO16):
pinMode(D0, WAKEUP_PULLUP);
Since I have no bad experience with deep_sleep (I´m using it exensively with battery powered applications) I don´t know if a deeper look into the pinmoode for GPIO16 helps. In your sketch there is no configuration for GPIO16.

[petrilloa]

Hi @fsommer1968. Thanks for the suggestion.
We also try pinMode(D0, WAKEUP_PULLUP); isn't working.

[fsommer1968]

In addition check the correct SPI flash mode for the flash rom!

[petrilloa]

Hi @fsommer1968, we already try QIO and DIO, and check with esptool.
No changes, still hangs on wake up.

[devyte]

@petrilloa the fact that the same pcb and code work ok with one batch and not with another is a strong hint that the second batch is likely bad somehow.
I am closing this, because I see from the posted logs that the code actually goes through the first execution sequence, which I think rules out an issue from the different manufacturer code, and hence our core code.

Some hints for you:

1. What happens if you sleep with different sleep times? (don't go over the max)

Consider this:

void deepSleep(uint64_t time_us, RFMode mode = RF_DEFAULT);
void deepSleepInstant(uint64_t time_us, RFMode mode = RF_DEFAULT);

1. What happens if you use the instant version?
2. What happens if you sleep with a mode other than the default?
3. What happens if you WiFi.disconnect() before deepSleep()? before seepSleepInstant()? If you e.g.: delay(5) in between those two calls?

Also:
-Are you _sure_ that the new batch has the exact same pin definitions as the previous working ones? I have seen gpio misnumbering and changes between factories. I suggest testing that what you think is gpio16 actually is gpio16.
-I suggest looking at the pulse coming out of gpio16 (connected to RST) with an osc, and compare the signal from the good batch vs. the new bad batch.
-I seem to remember reading somewhere that the pulse coming out of gpio16 on sleep expiration sometimes required some delay or some timing or something. I don't remember the details, and I didn't find the reference after a quick search. I mention this because you said you are resetting by RST, which is the same thing the gpio16 pulse is supposed to be doing, which would make me suspect either timing or signal strength.

Closing as not a core issue.

[petrilloa]

@devyte, I understand that you close it for apparently not being a specific problem of CORE, however I will continue to add information, since in different posts, on different platforms (not only GITHUB) I have seen this error, and never with a specific resolution ( taking out cases where there was a clear problem in the hardware connection)

1. What happens if you sleep with different sleep times? (don't go over the max)
   _Checked, same result_

void deepSleep(uint64_t time_us, RFMode mode = RF_DEFAULT);
void deepSleepInstant(uint64_t time_us, RFMode mode = RF_DEFAULT);

1. What happens if you use the instant version?
   _Checked, same result_

2. What happens if you sleep with a mode other than the default?
   _Checked, same result_

3. What happens if you WiFi.disconnect() before deepSleep()? before seepSleepInstant()? If you e.g.: delay(5) in between those two calls?
   _Checked, same result_

Also:
-Are you sure that the new batch has the exact same pin definitions as the previous working ones? I have seen gpio misnumbering and changes between factories. I suggest testing that what you think is gpio16 actually is gpio16.
_Checked, is physically the same_

-I suggest looking at the pulse coming out of gpio16 (connected to RST) with an osc, and compare the signal from the good batch vs. the new bad batch.
_Checked, i was getting some trouble using and old osc but can manage to see the reset pulse:

-I seem to remember reading somewhere that the pulse coming out of gpio16 on sleep expiration sometimes required some delay or some timing or something. I don't remember the details, and I didn't find the reference after a quick search. I mention this because you said you are resetting by RST, which is the same thing the gpio16 pulse is supposed to be doing, which would make me suspect either timing or signal strength.

_I read the same_

https://www.esp8266.com/viewtopic.php?f=6&t=17975

But, i it seems to be a different board ESP12S... maybe the same problem?

[devyte]

That sounds like the same problem i remember, but I'm pretty sure it's not the post i saw, and it wasn't a 12s but rather a clone board of a 12F.
If i were you i would do something similar as explained in that pist: rip open one of the shields and measure the pulse directly at the rst pin of the EX chip.

[WillowBeard]

I'm having the same issue with my newly arrived ESP12-F (ESP12MOD, containing ESP8266EX) boards. The chip does not wake up from deepsleep properly. Also, even when resetting by shorting rst to gnd there is no proper reset. Reset consistently works when "pressing the rst button" twice. Therefore I'd assume this is not a problem of the signal given by GPIO16 but something else?

[petrilloa]

Hi @WillowBeard, i think so. I also noticed that some times the bad chips needs pressing the reset button twice. I'm waiting for the factory for a replacement (we bought 150 pcs of them... So we are very worry about this). We are thinking that maybe are a cheaper clone of the original ones. I will have news soon.

[WillowBeard]

Hi @petrilloa, thanks for the quick reply. I also bought 15 of these. Really hoping to find a solution to this since the deep sleep functionality is crucial to most of my projects. Would you care to compare the exact labelling of the chips? Mine says "ESP8266EX, 492018, UB00PK7F11. The chip is marked with the espressif logo.
Addition: I had some NOdeMCU developement boards lying around. I tested two of them, one is working properly with deep sleep/wakeup, the other one does not. I opened both of them up to check for the data given on the chips. The faulty one says "ESP8266EX, 502018, UB00PK7F17". The other one (working) says "ESP8266EX, 222018, TUBOTWTF10". I guess, the second line has something to do with the time they were manufactured. Probably week/year.
The faulty ones are both manufactured end of 2018, while the working one seems to be much older (222018). This fits the pattern you observed. It would be interesting to find out from when to when this problem started. I will now go on and contact the seller (on AliExpress) but I'm not too optimistic about that. Did you contact Espressif about this? Sorry if I missed that.
Cheers,
WillowBeard

[petrilloa]

Hi @WillowBeard,
Where are you checking the exact labelling? You need to unsolder the RF Shield to see the actual ESP8266? I can't do that, because i need to send back the chips to the provider.
I didn't contact Espressif itself, maybe i will try with them also.
Regards

[WillowBeard]

Yes, I removed the shielding. I see, if you need to send them back you obviously can't do that... Do you think they will notice if one is missing? (Just kidding...)

[petrilloa]

@WillowBeard, can you check the ESP12 circuit (not the ESP8266) for this:

I ended up removing the shields on both the ESP-12S and ESP-12E to try to track down the differences. There is one major difference that, so far, has not been documented anywhere (even by AI-Thinker).

The schematics of the modules that have been floating around are not 100% correct. Even the schematic from the AI-Thinker documentation for the ESP-12E is incorrect.

In the ESP-12E module, there is a series resistor (about a 450 Ohm) in series between the RST pad and the EXT_RSTB of the ESP8266. There is also a 12k pull-up and some value capacitor. Seems like the RC circuit slows the rise time for the reset. This 450 Ohm resistor doesn't exist in the ESP-12S module which isn't documented anywhere.

Image from this post:
https://www.esp8266.com/viewtopic.php?f=6&t=17975

Also, do you have an osciloscope? According to the same post, there is a difference on the RESET pulse. I can´t check that in my batch.

[WillowBeard]

Hi @petrilloa, I am definitely going to do this. I have access to a scope, but it's a pretty old model. I will attempt to measure it and let you know when I got the result (likely on Wednesday). I will also try and short the series resistor (if present) to check if this is the reason for the trouble.

[WillowBeard]

Short update: I didn't manage to look at the signal on the rst pin yet. However I measured there is a 470 kΩ resistor between the rst pad and the rast pin. I tried putting a 470 Ω in parallel, which had no effect. There is also a 12 kΩ pull-up resistor on the rst pin and some capacitor. So the circuit looks ver much like in the post linked above. Since the capacitor should be responsible for slowing the voltage change down, I tried to remove the capacitor. This didn't lead to any change. I contacted the seller (on aliexpress) and was granted a refund without further ado. This looks to me like they know about this problem...
I'm still trying to measure the actual wakeup signal and will give an update when successful.
@petrilloa did you hear anything new from your supplier?
cheers

[torntrousers]

I've used a bunch of ESP-12S's with deep sleep and they've worked ok, though they were all bought at least a year ago so its possible something has been changed.

Would you try adding WAKE_NO_RFCAL to the deepSleep call - ESP.deepSleep(3e6, WAKE_NO_RFCAL) ?

[WillowBeard]

hi @torntrousers,
thanks for your suggestion. I tried it, but it doesn't seem to change anything. By the way, I also observed a wild voltage oscillation on GPIO00 when in "zombie mode". I tried to put a capacitor between I/O00 and GND with no effect. A 10k pullup resistor on GPIO00 gives 2.7 V on the pin. I suspect there is something wrong with the chip itself, but I am thankful for other suggestions.
cheers

[petrilloa]

Hi @WillowBeard,

I also detect the voltage oscillation on GPIO0 when is in "zombie mode". Somewhere i read about the internal clock signal from the ESP.

https://www.esp8266.com/viewtopic.php?f=160&t=16248
https://bbs.espressif.com/viewtopic.php?t=1485

The older ones, don't have this issue neithe

Our supplier is sending a new batch of ESP12F (from AI as the said). I´m going to post news when them arrive.

My biggest concern is how to identify devices with this behavior in advance. If it is a problem of the different factories that produce the ESP8266, and save money on a couple of simple components, it is an unreliable chip to make products using deepSleep (and not because of Espressif directly, but by those who end up making the ESPXX using his chip).
In principle, the only alternative is to make sure with the supplier that the chips are NOT clones (they have been offered to me) but, from some of the most important factories. There are differences of a few cents between the "original" chips and the "clones" (as they call them), which do not justify all these headaches in any way.

[devyte]

Has anyone measured that the capacitor is good? Has anyone tried increasing the 470R a bit or increasing the capacitor to have a bigger delay time to RST? Decreasing to have a shorter delay time? I would use a pot to play with the values.
Has anyone tried a different delay method, e.g. a 555? Again, different values to adjust the delay might give insight.

[WillowBeard]

hi everyone,
I finally found the time to measure the signal on the rst pin.

The reset pin is pulled down to approx. 0.4 V. The pull down pulse has a duration of about 35 us (from start of pull down to the lowest voltage). From start of the pull down until it is back to 3v3 it's 45 us. This is about twice as fast compared to the post @petrilloa quoted above.

Has anyone measured that the capacitor is good?

I didn't measure the capacitor directly, however I think the waveform indicates, that it is ok (please correct me if I'm wrong).
Since I get the same result when triying to wake up from reset by manually pulling rst to gnd, I don't think the short pull down signal is the problem. However, the rising part of the voltage curve might be related to the problem. But I really don't think so... Is it possible, that the RST is not pulled _low enough_? Could the "remaining" 0.4 V cause a problem like this?

Another observation I made: The gibberish in the serial monitor, that appears when waking up appears even when GPIO16 is not connected to RST and the board goes into the zombie-like state as well. Might this indicate that the actuall error happens _before_ the reset pulse is performed by GPIO16?
Also, I received three Wemos D1 mini boards today. They show the same error pattern.

[petrilloa]

Hi @WillowBeard .

First of all, to get ride of the gibberish in the serial monitor, you can set the serial monitor speed on 74880 bauds. In that way, yo can get the messages that the ESP is sending

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

The time of the pulse, seems WRONG, according to this https://bbs.espressif.com/viewtopic.php?p=5027#p5027

RESET is level trigged and the hold time of low voltage needs to be at least 100us.

Also, the level of LOGICAL LOW must be between like this

http://henrysbench.capnfatz.com/henrys-bench/arduino-projects-tips-and-more/esp8266ex-gpio-high-and-low-input-thresholds/

So, i think the issue is with the DURATION of the pulse.

Can you check the pulse, with one of the GOOD chips?

[WillowBeard]

I will check this, however I excluded this explanation (that the pulse is too short) since grounding RST even for seconds also leads to a false start into "zombi mode".

[girtskagis]

I have ESP-01 which works perfectly with deep sleep. Recently I got Lolin V0.1(ESP-12E) and it did not wake up. I removed metalic shield from Lolin and found that it has 460ohm in series of rst before filter. This is how the reset pulse looks on oscillator on EXT_RSTB pin(RESET). Yellow shorter one is on ESP-01. White on Lolin.
Then I bypassed the resistor and got the same shorter pulse. Unfortunately it did not solve this problem.
I have no idea what could be the solution...

[petrilloa]

Hi @girtskagis can you tell us what picture/logo has the esp12E shield? (Espressif, AI).
Also, can you send the LOG of serial monitor on wake up?

Thanks!
PD: Great that you can reproduce the pulse on the LOLIN one!

[WillowBeard]

This is what I get on first, normally working boot:

ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld

Then, when the deepsleep timer expires, I only get this:

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

If i remove the connections from GPIO16 to RST, I get this instead:

ets Jan  8 2013,rst cause:5, boot mode:(3,6)
ets_main.c 

I am wondering, if this could have something to do with faulty flash memory or something like that?

[mhightower83]

FWIW Here is a schematic for the ESP-12S that shows no 470 Ohm resistor in series with JP1 to EXT_RSTB. I also noticed that CHIP_EN now has a 12K Ohm pull-up.
Then, the schematic for the ESP-12F with the 470 Ohm resistor.

[petrilloa]

The new ESP12F from AI arrived... and they WORK!

The only thing I have left to think is that the other chips were clones and they did not have the internal components necessary to handle wakeup pulse correctly.

However, in the post of @girtskagis, we see that he could reproduce the problem with a LOLIN board (within a recognized manufacturer). It is strange that LOLIN uses ESP12 generics or clones. Hopefully you answer to identify if it is ESP of AI or ESPRESSIF.

Can you get in touch with LOLIN to talk about the issue?

[ximik666]

There is Wemos D1 mini . Does not come out of deep sleep. Contacts are connected as it should. After some time, the garbage comes out to the console and that's it.Did you find any solution?

[girtskagis]

@petrilloa This is the shield on Lolin V0.1

The log when it works before deep sleep:

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v21db8fc9
~ld

Then after wakeup in zombie mode:
ets Jan 8 2013,rst cause:2, boot mode:(3,6)

Will have to wait when ESP-12F arrive!

[girtskagis]

Also this isn't genuine Lolin board, it is cheap ALiexpress board.

[WillowBeard]

@petrilloa that's great news! I stillt hope to find a solution to the problem, but I'm not very optimistic anymore. Could you let me know, where you got the working modules from?

[petrilloa]

@WillowBeard, worry for the delay.
https://www.kuongshun-ks.com/

The contact is Darren.
[email protected]

[docm64]

@WillowBeard , I have exactly the same issue on a D1 mini clone I baught recently. Did you find a solution?
I observed the following: Once the module is in deep sleep, a pulse on RST will not properly reset the chip. I get the same messages as you reported, including the strange "ets_main.c" in case of missing D0-RST link. A second pulse is needed to reboot properly.
I am wondering what is happening here. The fact that there are messages from the boot loader would indicate to me that the ESP8266 is starting but then something goes wrong and the program is not loaded. Any suggestions?

[girtskagis]

Got mine ESP-12F from Aliexpress and they work. Wake up and everything!

[docm64]

Great for you, but doesn't solve my problem. I want to understand what is going wrong, if there is a workaround in software or hardware. Otherwise it is just a matter of luck (production batch, tolerances, environmental conditions?) whether it works or not.

[WillowBeard]

hi everyone,
first of all thanks for the info @petrilloa. I baught all my boards off aliexpress too, but that doesn't contain any information really, since aliexpress is just the platform. I got my bugged modules from a shop called "advanced tech" on ali. I have now ordered new modules from XM (ShenZhen) Electronic Trade Co. (also Aliexpress). They state that "authenticity [is] guarateed". We'll see about that... I will give an update, when I learn anything new.
@docm64: Is there an AI logo on the shielding of your boards? Unfortunately I don't have any other idea but that the problem is an internal hardware issue. The malfunctioning boards all have chips from batch 50/2018 and similar. Did you by any chance remove the shielding and have a look at the numbers on the chip itself?
@girtskagis From what shop did you buy exactly?
cheers
WB

[devyte]

has anyone tried exaggerating the rc constant to get a longer length pulse on RST?
has anyone tried a real pulse delay circuit, like with a 555, to play with the width of the low pulse?
I'm thinking of the minimum time the RST must be held low.

[girtskagis]

@WillowBeard Here is the link to Ali ESP-12F that worked for me:

https://www.aliexpress.com/item/5PCS-2015-New-version-ESP-12F-ESP-12E-upgrade-ESP8266-remote-serial-Port-WIFI-wireless-module/32695678523.html?spm=a2g0s.9042311.0.0.4f3d4c4dPF7hNm

@devyte I only shortened the RST pulse on faulty ESP to recreate RST pulse width from working one. (I probed it at the QFN packages RST pin.) Did not change anything. I also tested the RST filter/pullup , but it seems close to the working one. May be the PCB design is bad(some bypass cap not connected or smt else.)

[devyte]

I'm not thinking of getting the waveform of the bad modules close to the good ones, but rather of doing a better job of emulating a pressing of the reset button in different ways, because that obviously works.
My reasoning is that, if there is some requirement fir holding RST low for some time, abd nobody is adhering to it, then maybe the good modules have a looser time due to e. g. internal component quality, while the bad modules need a longer or cleaner pulse to accomplish the same thing.

[docm64]

I tried this approach, but when I press the reset button while the module is in deep sleep, the module will not reboot but change to Zombie state in exactly the same way as it does when GPIO16 tries to reboot it after the deep sleep period. The result is exactly the same, irrespective how long I press reset. I read about many attempts to change the timing of the reset pulse but none of them has been reported successful.
However I made the following observation: Pressing the reset button twice during deep sleep let the module boot the application again. Now I try to build some simple circut that shall double the GPIO16 pulse. Two pulses insetead of one. Will keep you posted if that brings success.

[liebman]

@docm64 my only question with that is if it will still preserve RTC memory as deep sleep does.

[JensMunkHansen]

I have made some experiences, which may be related to this. Perhaps someone in this thread could help me out.

I use a DFRobot WiFi Bee v1.0 and according to their diagrams, they have connected both GPIO16 and RST, so I have short-circuited them.

With GPIO16 and RST short-circuited, I get

19:05:51.477 -> Going to sleep.
19:06:20.344 ->
19:06:20.344 -> ets Jan 8 2013,rst cause:5, boot mode:(3,0)
19:06:20.344 ->
19:06:20.344 -> ets_main.c

Without short-circuiting, I get almost the same except for

19:06:20.344 -> ets Jan 8 2013,rst cause:5, boot mode:(3,7)

I read somewhere that 7 means UART1 boot and 0 means Remapping.

Question: Why rst cause:5. Could this be that DFRobot has forgotten to connect the RST or the GPIO16 signals? The funny is that I get a different answer depending on whether I short-circuit the signals.

Thanks in advance
Jens

[monanto]

Having same issue with d1 mini
https://www.aliexpress.com/item/32643142716.html

[fsommer1968]

Hi monato,

this is not a genuine Wemos D1 mini! It´s a fake.

[monanto]

Hi monato,

this is not a genuine Wemos D1 mini! It´s a fake.

Yes but the clones i bought few months back work fine and support deep sleep

[JensMunkHansen]

Hi Monato

I just bought a cheap wemos clone. Looks exactly like yours, 2.5USD and it
works as anticipated. I will try to power my dfrobot bee using a battery
instead of the FDTI adapter to see if it works. Thanks for sharing

On Mon, May 27, 2019, 07:37 monanto [e-mail] wrote:

Hi monato,

this is not a genuine Wemos D1 mini! It´s a fake.

Yes but the clones i bought few months back work fine and support deep
sleep

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/esp8266/Arduino/issues/6007?email_source=notifications&email_token=ABQJKYSZBRXSRZNZWJZAJZDPXNXRZA5CNFSM4HHT54AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWI2EDY#issuecomment-496083471,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABQJKYTT3ICUMIABNUGVZ6TPXNXRZANCNFSM4HHT54AA
.

[monanto]

From which store
can you send link ?

[JensMunkHansen]

https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.6.2.69004c4dQ6aWtc&orderId=101997752945128&productId=32963167122

[JensMunkHansen]

I have only verified the deep sleep functionality since this was the issue on my DFRobot bee

[monanto]

this product and store right ?
https://www.aliexpress.com/item/32963167122.html

[monanto]

How much is deep sleep current draw can you measure it ?

[JensMunkHansen]

Yes

[JensMunkHansen]

I could measure it but I am away for the next two weeks.

[monanto]

Nope
Thanks For help
I will order some from there and hope they works
Regards

[javiercuellar73]

Hi,

Basically, this is a hardware problem, isn't it?
Any solution besides buying new one?

[JensMunkHansen]

One could try short-circuiting GPIO0 and reset directly on the chip... But, yes a hardware problem... Could be systematic

[javiercuellar73]

I short-circuiting GPIO0 and reset but didn't work.

I attach 2 images showing the reset pulse on both a working and non-working ESP-12S .
The images look the same. This means the pulse is correct... I will take out metallic part and see if there is any difference.

[rdelcorro]

I also got scammed with my latest batch of ESP modules from Aliexpress. What I have found is that the broken ones have a "DOIT.AM" string in the module shield and the others do not have it. I am hoping to find an answer to this issue and I will be opening and playing with one

[tiagobortolini]

Hi,
Same here, and also have doit.am in de module.

[hpflatorre]

@devyte I am pretty sure this issue is related to the core library stack.

I've got a batch with more than a hundred clone ESP-12F modules with this odd behaviour. It doesn't matter how long or how close to 0V the pulse is, it only comes out of deep sleep after a second reset. If reset before entering deep sleep it runs fine with just one pulse. After entering deep sleep it always requires two reset pulses to properly wake up. The same binary works fine with other batches.

The new clue I'm adding to this thread is that if I flash the modules with this deep sleep example from Espressif (https://github.com/EspressifSystems/low_power_voltage_measurement) the modules will wake up from deep sleep properly!

So, it seems like this library may have some responsibility. I already tried the following:

1. sleep with different sleep times;
2. use the instant version;
3. sleep with a mode other than the default;
4. WiFi.disconnect() before deepSleep(), before seepSleepInstant() and even delay(5) in between those two calls;
5. Perform Full Flash erase before flashing;

Now I will investigate differences between this core and Espressif's native SKD example.

[d-a-v]

@hpflatorre What version of this core are you using for your tests ?

In git version there is an example esp8266>WiFiShutdown.ino.
Can you try it and report whether reset after deepSleep is still not working with your boards ?
There is also #6484 that has fixed a number of incoherent behaviours, merged in current git version.

Are you already using git, or are you able to test with it ?

[hpflatorre]

@hpflatorre What version of this core are you using for your tests ?

In git version there is an example esp8266>WiFiShutdown.ino.
Can you try it and report whether reset after deepSleep is still not working with your boards ?
There is also #6484 that has fixed a number of incoherent behaviours, merged in current git version.

Are you already using git, or are you able to test with it ?

@d-a-v I was using stable releases and tested with 2.0.0, 2.4.2 and 2.5.2. Now I installed the latest git master version (#6625) and used this example 'esp8266>WiFiShutdown.ino'. I observed the same in three different cases:

1. It won't boot properly after entering deep sleep and receiving the reset pulse from RTC. It will display the boot message "ets Jan 8 2013,rst cause:2, boot mode:(3,6)" and the program won't run until I make a second reset pulse manually;
2. If I make the manual reset pulse soon after it enters deep sleep and before the programmed wake-up time (before 5s), the same will happen: it will give the boot message and do nothing until I pulse reset again;
3. If I make a manual reset pulse during the program execution, before it enters deep sleep, it will always boot properly.

In the attached file there is the serial output of these three cases, where >>>>>> indicates my comments.
ESP8266_WiFiShutdown_log_fail_to_wake_up.txt

Also, here is the chip info:
esptool.py v2.6
Chip is ESP8266EX
Features: WiFi
MAC: dc:4f:22:5f:66:4e
Auto-detected Flash size: 4MB
Flash params set to 0x0340

[d-a-v]

And you have no issue with boards not from this batch of more than 100 ?
Did you try to add a capacitor, another power supply, cable, capacitor, to read this story, to play with system_deep_sleep_set_option(0 or 4) => Esp.deepSleep(n, RF_DEFAULT or RF_DISABLED) (<= that one is done in the low power voltage espressif example) ?

[nikolz0]

Hi,
propose a simple test for deep-sleep.
the test will exclude the SDK from the possible list.
I have all modules work without problems.
test_0x00000.zip

[devyte]

@nikolz0 thanks, but the bin by itself isn't very helpful. Could you please add the source files?

[DamirKh]

@nikolz0 thanks, it works! Sources, pls!

[hpflatorre]

And you have no issue with boards not from this batch of more than 100 ?
Did you try to add a capacitor, another power supply, cable, capacitor, to read this story, to play with system_deep_sleep_set_option(0 or 4) => Esp.deepSleep(n, RF_DEFAULT or RF_DISABLED) (<= that one is done in the low power voltage espressif example) ?

@d-a-v The problem only manifests with the latest batch. It runs fine with other apparently identical boards.
I've played with several large and small capacitors on the input and a different power supplies and batteries. Voltage levels are within recommended ranges and there are no voltage drops during boot. I am monitoring with a scope.

The Espressif's example I mentioned (https://github.com/EspressifSystems/low_power_voltage_measurement) is quite old and seems to use Espressif's SDK version 1.0.1b. The example uses the equivalents from this SDK:

• system_deep_sleep_set_option(4);
• system_deep_sleep_set_option(1);
• system_deep_sleep(100000);

@nikolz0 Your deep_sleep example also works perfectly fine on all the boards I have. I hope you provide some useful source code for us.

So, does this suggest an SDK issue?

[nikolz0]

Hi,
this test is written without SDK.

The problem is most likely in the Deep Sleep function

I'm using my version of deep sleep function, which I'll post a bit later.

[nikolz0]

Hi,
I have to admit that the problem remains.
On Wemos, my test stops working after a while.
the reason has not yet found out.

[nikolz0]

Hi,
the problem occurs on boards that have an ESP mode control circuit.
And there is no problem on the very first version of NODEMCU.
The problem is on WEMOS.
Note that the use of deepsleep mode on such boards does not make sense because
the adapter consumes a lot.

Therefore, the elimination of this problem makes only theoretical sense.

The problem is that the ESP mode control circuit is set to program mode at a random point in time.
After that, it can be reset only by disconnecting the power from the module.

[BotovNikita]

Hi nikolz0
I have same problem, and your test.bin works fine! Can you give source code?

[nikolz0]

Hi,
it is my function deep_sleep.

written in C:

void ets_wdt_disable();
void ets_delay_us(int);

define _R (uint32 *)0x60000700

void nk_deep_sleep(uint32 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");
}

[hpflatorre]

Nice @nikolz0. It works well within my application with all modules. Thanks a lot! I've let it run for an hour now waking up every 5 seconds. I'll leave it running on the problematic modules and confirm if it is stable soon.

The only problem though is that it always wakes up with WiFi enabled (RF_CAL option) and I need it to be able to exit deep sleep without WiFi also. t seems to ignore any previous calls to system_deep_sleep_set_option(RF_DISABLED); Could you please provide some insight on which register may control fr calibration at wake up? or at least point to the register reference you used? I can't decipher this function since I wasn't able to find any detailed register map for this address range.

Here is my C port of @nikolz0 deep_sleep function correcting a few typos and embedding the ets_ functions:

#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");
}

[nikolz0]

Hi,
operator
*(_R+4)=0;
turns off WiFi.
if you write in C then it can be inserted into the body of the function
user_rf_pre_init().

[theshadowsvk]

@hpflatorre I tried your NK sleep but no matter what time I insert in your function, the esp sleeps and wakes immediately :-/ Can you help please ?

[mfacen]

This is really weird, I had a test module working with Deep Sleep for a month as I was developing on it, was a generic Wemos D1 Mini, no problems with waking up from deep sleep, D0/Reset connection just a short, no resistor or diode.
I received new modules, also generic and when tried to flash the same source it started presenting the same symptoms as described in this thread.
Then I try on the original module where it was working before with the old firmware: working... When I flash the new version of my firmware: not working, try to revert to my last commit when I knew the module was working and it doesnt anymore. What ???
Now none of the modules works. The difference I see is that in my case if I set the serial monitor to 74880 bauds when the module tries to wake up I just see garbage, not the normal ets Jan 8 2013,rst cause:2, boot mode:(3,6) or something of the sort.
nikolz0 code doesn't change anything for me, the module seems to enter sleep fine but can't wake up properly.
I find it so weird that my module that I used for a month while working on the software was working fine and then doesn't work anymore, I thought it might have been a espressif issue but tried to revert to 2.1.0 , 2.0.0, 1.8.0 as suggested on this thread and the module still can't wake up .
What gives ? It is hardware then ? Was I just lucky with my test module working for a while ?

[nikolz0]

Hi,
I believe that the modules Wemos and Nodemcu worked in deep sleep, you need to disable the adapter and two transistors on the Board.

[nikolz0]

Hi,
rather, disable the control circuit mode, consisting of two transistors.

[nikolz0]

To understand why the module stopped working, it is necessary to measure the voltage on GPIO0.

[mfacen]

Hi Nikolz0 thanks for the reply, and for posting the deep sleep function.
I'll try to take out the transistors without damaging the board but my tools/eyesight are not the best for this kind of work. I took out the shield form one of the non working wemos but even with 25x magnification cant make out the numbers of the date on the ESP8266 chip, I can see it has a expressif logo but it looks pretty faint marking, I'm using 25x magnification.
I dont have a digital osciloscope, just an old analog one so I can't record the reset signal but obviously there is something weird about this whole situation and that is:

 If the module is in normal operation  and i press reset it resets.
 If the module is in deep sleep and I press the reset button it doesn't wake up but goes into zombie mode.

Doesn't that indicate that is has to be a software related issue ?
I hope someone can figure this out, if there is a way to fix it. Just received 20 LOLIN V3 modules I was really nervous about those as I was not sure they were going to work as in my case without deep sleep they are useless, I just got them and tried out one and it worked, left it running for a while in a wake up cycle and now its not working anymore. They are marked LOLIN wemos.cc D1 Mini v3.1.0. I'm so frustrated I spent so many months working on this project and now that I was ready to deliver the circuits nothing is working and I got 20 useless boards ( plus the other 5 that aren't working either).

[nikolz0]

Hi,
Wemos is convenient to use for program development and debugging.
But if you want to use deepsleep in your devices, you need to take ESP-12 modules (ESP8266) or modules ESP-M2 (ESP8285).
Тo program them, use any USB-UART adapter, two resistors and two buttons.

[mfacen]

I know, the plan was to do a proof of concept with the 20 devices on our farms ( the application is temperature monitoring for a shrimp farm ) to work out all the software related issues, once they were tried we'd design a new board with the esp8266 for them.
I'm going to try to lift the transistors of the control circuit and see if it makes a difference.

[nikolz0]

Hi,
I recommend paying attention to the ESP-NOW Protocol.
If you use it instead of WiFi, the active time of the ESP when you Wake up from sleep can be reduced to 0.15 sec instead of 0.5-4 sec when WiFi.

[nikolz0]

in my projects, the time of active work on the Wifi Protocol is about 0.25 sec, and on the ESP-Now Protocol 0.15 sec. The module operates from a solar panel without a battery at all.

[nikolz0]

If you poll the sensor inside the boot, the current consumption can be reduced to 3-15 mA instead of 70 mA.

[mfacen]

The ESP-NOW protocol looks really interesting for creating a mesh of sensors but in my application each unit is independent of the others, I have in mind some sensors for a hatchery lab for shrimp where I was planning to use it but have not gone around to experimenting with it yet.
From what I understand it is possible to use ESP-Now and regular TCP at the same time, is that correct ? My specific question is can a module communicate with another by esp-now while running an HTTP server for the user interface ?

[nikolz0]

Yes, it is possible.
The module can simultaneously work with Wi-Fi and ESP-NOW.

[fsommer1968]

in my projects, the time of active work on the Wifi Protocol is about 0.25 sec, and on the ESP-Now Protocol 0.15 sec. The module operates from a solar panel without a battery at all.

How did you manage it to have only 250ms for WIFI operation after deep sleep? In my opinion it takes >500ms for WiFi calibration and AP assignment. Or how long is the time when the ESP is in deep sleep?

[nikolz0]

Hi,
Usually the connection time is from 540ms to 4 seconds.
To get 0.25 sec you need to save the connection settings in RAM RTC and disable DHCP.

[mfacen]

Hey guys just popped back in to inform that after trying one of the 20 boards I received I got so frustrated that just put them aside for a while, today I tried other boards from the same batch and they did work as expected, I didnt try all 20 of them just about half and they all work, the one I tried first is still not waking up... This issue is quite annoying and would be great if someone gets to the bottom of it so we can identify the faulty modules somehow. From now on every time I order them Iḿ going to be wondering what I get...

[hpflatorre]

I don't know if this helps much to identify the faulty ones, but all modules I have with this issue have MAC addresses starting with dc:4f:22. All with this prefix have the problem. Modules with other prefix cc:50:e3 84:0D:8E 84:f3:eb 24:62:ab all work fine.

[mfacen]

Thats very interesting about the mac addresses, I checked and yes all the faulty ones start with dc:4f:22, the LOLIN that was not working starts with 84:f3:eb but I think its a fluke as now I tried the other 19 and they all work. The date marking on the ESP8266 indicate early 2018 : 072018, that would be week 7 of 2018.
Well, considering the mac address and the dates I guess we can start figuring out the troublesome modules.

[nikolz0]

Hi,
Write in detail that does not work at ESP12.
Show the circuit diagram and the terminal screen.

[nikolz0]

Hi,
Try flashing ESP12 with the DIO parameter instead of QIO.
For firmware recommend NODEMCU FIRMWARE PROGRAMMER.

[devluz]

I have two D1 mini clones with this defect. Both have a mac starting with EC:FA:BC though. So far I can identify my broken modules by "DOIT.AM" printed on the shield over the ESP8266 chip.

Thanks a lot to @nikolz0 for the workaround and @hpflatorre for the C port. This is all way beyond my skills but at least I can use my modules for some experiments with the arduino IDE now :)

[nikolz0]

I assume that in non-working ESP12 slow flash chips are installed, which do not have a Quad mode. Therefore, they must be programmed in double mode. I recommend for such modules to try to lower the frequency for flash.

[devyte]

slow flash chips

What is the flash brand? There is one known case where the flash requires special additional programming to reach max speed.

[mfacen]

Sorry about the delay, was travelling, I'm out of the country for a month so I dont have access to all my tools and I just took with me one LOLIN V3.0 to keep working and one of the faulty generic modules, I dont have the one I took apart here with me but I remember there were no markings in the flash chip.
Now to continue with the weirdness the non working module I brought with me decided to start working suddenly and it worked fine for one day, now is back to going into zombie mode when trying to wake up from deep sleep. To be clear this is one of the modules with mac starting with dc:4f:22, but I dont have the "DOIT.AM" marking. The weird thing is that the module was stuck on zombie mode, I left it connected as I had to leave and when I came back it was waking correctly from deep sleep. That would explain how I got lucky and was able to use one of the faulty chips for a while and suddenly it started failing, I spent days trying to figure out where the problem was in my code as I thought I did something to break it. Very annoying...

[genotix]

Nice @nikolz0. It works well within my application with all modules. Thanks a lot! I've let it run for an hour now waking up every 5 seconds. I'll leave it running on the problematic modules and confirm if it is stable soon.

The only problem though is that it always wakes up with WiFi enabled (RF_CAL option) and I need it to be able to exit deep sleep without WiFi also. t seems to ignore any previous calls to system_deep_sleep_set_option(RF_DISABLED); Could you please provide some insight on which register may control fr calibration at wake up? or at least point to the register reference you used? I can't decipher this function since I wasn't able to find any detailed register map for this address range.

Here is my C port of @nikolz0 deep_sleep function correcting a few typos and embedding the ets_ functions:

#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");
}

THIS WORKED FOR ME!!
I'm using a WittyCloud with an ESP8266MOD

THANK YOU!!!

[nikolz0]

Hi,
*(_R + 4) = 0; - this command disables WiFi. The simplest solution is to put this command at the beginning of the program.
I place my program inside boot, since Wifi is turned on after it works.
If Wifi Is not required, then I send the ESP to sleep inside the boot.

[devyte]

CC @Tech-TX

[Tech-TX]

The only problem though is that it always wakes up with WiFi enabled (RF_CAL option) and I need it to be able to exit deep sleep without WiFi also. t seems to ignore any previous calls to system_deep_sleep_set_option(RF_DISABLED); Could you please provide some insight on which register may control fr calibration at wake up? or at least point to the register reference you used? I can't decipher this function since I wasn't able to find any detailed register map for this address range.

@hpflatorre Henrique, try this:
https://github.com/esp8266/Arduino/issues/6642#issuecomment-578462867
The second cut is solid, and I'm hoping I can get it even better. It stops the boot RFCAL and turns the modem off as soon as possible.

[Tech-TX]

By the way, I suspect (but can't verify) that you folks looking at the RESET pulse are on the wrong path. When the voltage at the EXT-RSTB pin on the chip starts to go high, the CPU has already responded to the RESET and has released the driver on GPIO16 (it's changed over from a CMOS totem-pole output to HI-Z input). There's little information on the guts of the chip itself, but the OTHER pins on the chip aren't cleared by reset, they're only reset to inputs if the SDK thinks it needs to init them (power-on or ???). On other CPUs I've used that's a hardware function in the chip's reset state machine, but on the ESP8266 it's driven by software.

The comment in cyan is mine.

The RTC hardware _could_ be tied into the internal RESET logic (clearing GPIO16 output driver in hardware) but I think it's more likely done in the boot code in the ResetHandler. Not long after that it's loading the SDK from flash, and it appears that's where your execution is going astray since you get the initial boot message. A funky off-brand flash chip would explain your problems more easily than someone cloning the ESP8266, especially if you're not getting the "load 0x4010f000" message which I think comes from the SDK and not the boot ROM. I could easily be wrong on that point as I haven't researched the boot process yet.

The note at the Espressif BBS about the reset duration is very old, and possibly a worst-case even so after power-up.

[omue999]

I have the same problem with new ESP-12F.
When I pull the MISO pin up to a resistor (47k), the modules run after deep sleep ;-)

[gismofx]

Is this resolved?

I had the same problem and wake was not working after deepSleep on a D1 Mini Clone board.

I noticed that after uploading the board would do it's thing and sleep and then not wake. If I unplugged the board and plugged it back in, it would start working an d waking from deep sleep. My issue was related to using Serial or connected to the serial.

I've yet to try, but Serial1 might be a work-around.

Otherwise, don't use Serial when using deepSleep.

[kebwi]

I'm also having this problem. I have two D1 minis, both clones, but different manufacturers (different logos on the shields). And one is missing the three-legged component between the USB port and the reset switch on the bottom side. At any rate, they both behave exactly the same way. Deep sleep wakens in a garbled (what has been called zombie) state. Two presses to reset fixes it. If I tie D0 directly to RST, then a single press to reset suffices to reboot properly.

I haven't tried the firmware change to the deep_sleep function recommended above because I'm using MicroPython. I may delve into figuring out how to edit the deep_sleep implementation in MicroPython, but I can't believe I'm the first person contending with this problem: MicroPython not deep sleeping properly on the D1 mini. While the Arduino solution above is useful in that environment, I need a MicroPython solution. I'm inquiring on the MicroPython forums about this issue, but I'm dropping it in here too. Has anyone else fixed this in a MicroPython environment already?

Thanks.

[kebwi]

I don't have a 47K lying around, but I tried a 10K on MISO (pin D6) and it didn't fix the zombie wakeup problem. The closet I've come is discovering that directly tying D0 to RST enables me to reboot with a single press to the reset switch, whereas with no connections, it takes two resets, as others have noted above. I don't know what to do. I don't want to buy any D1s, clone or original, or even buy bare ESP-12 boards of any model, until I figure this thing out.

[kpot]

TLDR: I've solved this issue for myself. It was caused by a bad power source.

Long version:
I've had similar issues with my generic ESP-12F modules from Aliexpress. The same code that had worked perfectly on a bit older ESP07 would hang after 3-15 cycles of deep sleep on ESP12Fs. I don't use any ESP-based boards like Wemos D1. My setup is minimal: just the module, a few resistors, and a USB-serial converter like it is shown on this circuit. GPIO16 was connected to the reset pin through a schottky diode. The whole thing was powered from a good Li-Ion battery through a 1.5A-capable buck (step-down) converter. I had also installed 10uF + 0.1uF capacitors across the power pins of ESP12F, as suggested by official guides from Espressif. So everything was looking good. But still didn't work properly.

After 2 days spent trying various hacks, including the function nk_deep_sleep provided by @nikolz0, I decided to connect my bench power supply (DPS5005) to the board. And just like that, the issue was gone. Then I remembered that my well-working ESP07-based device with the same code was actually powered through an LDO linear regulator, and not through a buck converter.

My best theory is that my buck converter module, although powerful enough, has very bad response time characteristic and is unable to cope reliably with power spikes occurring when ESP12F wakes up and tries to access WiFi, store WiFi settings in flash memory and so on. All these power surges lead to significant voltage drops (suddenly, from few uA in deep sleep to about 80mA), which the buck converter is sometimes too slow to compensate for (bad design perhaps). It may even be oscillating for a bit, trying to stabilize its output. Various ESP modules might have different tolerance for such power deviations, depending on which Flash memory module is installed.

So try different power sources if you have this issue, no matter how confident you are that your current power supply is good enough for the job. If you don't have a lab power supply, try a combination of batteries + an LDO linear regulator (>200mA to have some reserve). This will give you a strong enough low-noise power source that will be helpful in testing your device.

[kpot]

I decided to get to the bottom of this and began tinkering with the power source. I noticed that ESP12F starts freezing after deep sleep every time I set the power supply to provide even a tiny bit below 3.31V. Even 3.29V and ESP already becomes unstable.

Then I connected oscilloscope directly to ESP12F's VCC and GND pins, set the power supply to 3.3 and began to wait. Turned out that every time the module wakes up, the VCC-GND voltage drops in multiple spikes from 3.3V to as low as 3.1V. But _every once in a while the voltage spikes down to 3.0-3.05V_ (a particularly heavy WiFi exchange?), and this is exactly when ESP12F freezes.

I don't know the exact model of flash memory under the metallic shield of the module. If it is something like W25Q32FV from Winbond, it should tolerate voltages down to 2.7V. But I suspect either some ESP12Fs come with cheaper flash memory installed, or the copper traces within the module itself are so thin that the actual voltage provided to the ICs drops inside even further to somewhere below 2.7V.

I've replaced the feedback divider on my previously mentioned buck converter so it would output 3.37V instead of 3.3V and it works perfectly well now.

[genotix]

I decided to get to the bottom of this and began tinkering with the power source. I noticed that ESP12F starts freezing after deep sleep every time I set the power supply to provide even a tiny bit below 3.31V. Even 3.29V and ESP already becomes unstable.

Then I connected oscilloscope directly to ESP12F's VCC and GND pins, set the power supply to 3.3 and began to wait. Turned out that every time the module wakes up, the VCC-GND voltage drops in multiple spikes from 3.3V to as low as 3.1V. But _every once in a while the voltage spikes down to 3.0-3.05V_ (a particularly heavy WiFi exchange?), and this is exactly when ESP12F freezes.

I don't know the exact model of flash memory under the metallic shield of the module. If it is something like W25Q32FV from Winbond, it should tolerate voltages down to 2.7V. But I suspect either some ESP12Fs come with cheaper flash memory installed, or the copper traces within the module itself are so thin that the actual voltage provided to the ICs drops inside even further to somewhere below 2.7V.

I've replaced the feedback divider on my previously mentioned buck converter so it would output 3.37V instead of 3.3V and it works perfectly well now.

Great work figuring this out!!

What happens when you place a large capacitor over the buck converter output side to compensate the voltage drop?

[kpot]

Adding capacitors straight across VCC and GND pins of the module does not help. In addition to soldered earlier 10uF + 100nF caps, I tried adding low-ESR ceramic capacitors (47uF and 68uF), beefy 220uF tantalum, low ESR 1000uF electrolytic and all of them combined. They do help to dampen the voltage spikes at the input. However, when I lower the voltage to 3.29V at the next waking everything freezes up again and my terminal shows me the same "sign of death"

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

ets_main.c

So whatever causes the issue, it's inside the ESP12F module. At this point I can only speculate what it could be. Cutting the costs, the manufacturer could entirely skip on installing bypass capacitors across the ICs. Or these capacitors have low quality and high ESR. Or the board itself uses cheap thin copper layers and poorly designed. That's why modules from some batches/manufacturers work well, while some others fail even at their nominal voltage. Awakening from a deep sleep is probably the most stressful conditions we can put the module in. When everything is up and running suddenly and is trying to calibrate, transmit, output, measure, etc.

[mhightower83]

IMO an important parameter to look at in your switching type power supply is _Transient Load_ response. The ESP8266 can go from sipping 60ma to gulping 300ma in an instant. That is a 400% load increase.

For the 5V power supply circuit paired with an LDO that I looked at, it was a little difficult to capture the dip on the oscilloscope. I had to use AC coupling on the trigger line. Adding capacitors helps with the spikes but did not make up for the slow response from the power supply, which resulted in a short voltage droop. Note adding excessively large CAPs may make the power-on rise time too slow for a proper power-up reset inside the ESP8266. I have read blog comments that leaving an ESP8266 in a failed reset state can be destructive.

I would not expect an inexpensive buck converter to have the load response needed and that operating the ESP8266 at a lower voltage level as you describe may result in Undervoltage during _Transient Load_.

It might be worth noting, that many of the IoT devices I have looked at, use a switching power supply designed for changing batters. Battery charging doesn't need a good transient load response; however, they pair it with a good LDO voltage regulator to power the ESP8266.

So far I have not seen a retail device that powers the ESP8266 directly from a switching type power supply. They may be out there. I think when the ESP8266 is a part of a device that uses several times more power than the ESP8266 peak, then the _Transient Load_ based on the total power consumed would be much easier for a switching power supply to handle.

Edited: for clarity and corrected load increase calculation.

[Maker39]

Hi guys.
I also had problems ESP-01S on which stood flash FT25H08.
I tried everything that is written in this thread - nothing helped.
Replaced with Winbond 25Q80BVIG and 25Q32BVSIG and now deep sleep and waking up work fine.

[shivan]

@kpot so can you suggest a good power module (for 3,7V LiPo battery with charging port) and/or good ESP board?

I currently use the AZ-Delivery ESP8266 (Wemos D1) and Battery Shield 1.2.0 from ILS.
Funny is that two independet ESPs with different sketches did not wake up anymore on the same day.
Currently I have one here which does not wake up yet.

Can I do further analysis when plugging in to USB-Port? I did not press reset yet, as I still hope to find a way for further analysis.

[kpot]

@shivan Sorry, can't give you any useful advice on which board to pick up, since I haven't found one completely reliable myself. Which isn't a big surprise since most Chinese manufacturers tend to stick with the same (sometimes poor) choice of cheapest components they could find for the job. And there are plenty of knockoffs on the IC market.

USB port usually provides 5V, and (assuming this port is of a good quality and can provide enough current) your bottleneck will be the device converting these 5V down to 3.3V to power your ESP board + its output capacitor. Usually you can find a linear regulator doing the job, like AMS1117 and a ceramic/electrolytic capacitor on its output. These are the ones you'll need to blame if you plug the board in USB port and it still refuses to wake up properly. Either the regulator cannot provide enough current, or the capacitor is too small for the job.

[nikolz0]

I have already explained that the problem of getting out of sleep is related to the automatic mode selection scheme, which is the same on all NODEMCU and WEMOS boards .
The problem is solved simply-use the ESP12 module, the USB adapter, two buttons-reset and mode selection and four resistors, or change the circuit.

[kpot]

I have already explained that the problem of getting out of sleep is related to the automatic mode selection scheme, which is the same on all NODEMCU and WEMOS boards .

If you're saying this is merely a software problem, then I have to disagree. Yes, writing the code differently can sometimes be helpful. It did work for you and some other people, but didn't help in my case (I've tried your solution).

To me the obvious reason why the purely software solution can sometimes work is because it can slightly dampen the wake-up power surges, which in some cases is all that was needed to avoid dangerously low voltage dips. But this just wasn't enough in my case. For me, a better power source did solve the issue without any change in the code.

[Maker39]

When the ESP comes out of sleep , it accidentally switches to programming mode.
As a result, the program is not executed.
If you remove the automatic mode control scheme, the cause of the problem will disappear.
To avoid this problem, you must disable the possibility of a random pulse on the pin GPIO0 at the moment when the pulse appears at the pin RST.

But how then to explain the problem of zombie mode on the ESP-01S modules without a programming mode switch , and powered by a laboratory power supply?
And how i have working deep sleep for half a year from Li-po through the WEMOS Battery Shield v 1.2 my WEMOS D1 Mini Pro ?
Maybe it makes sense to collect statistics on Flash chips in buggy modules (I think the thing is all the problem)
My two ESP-01S had FT25H08 and "zombie mode" problem, but after replase IC FLASH to Winbond it's work fine.

[Maker39]

I probably pointed it out incorrectly.
The bottom line is that I use wifi-iot.com firmware on SDK 1.3.0 but not Arduino.
So there are no complaints about the software on the SDK.
My ESP-01S were equipped by me with a GPIO16-RESET jumper.
I tried all the options that helped people in this thread. Nothing helped for me. Only the FLASH replacement helped.

[shivan]

you must disable the possibility of a random pulse on the pin GPIO0

@nikolz0 ok I have a DHT22 at GPIO0 and GPIO2, so it could help, when I put it somewhere else? I'll try that.

Currently I use:
GPIO2 = Data
GPIO0 = VCC (+)

[leofds]

I have the same problem.
Pull up resistor (47k or 10k) on the MISO pin, only this worked for me.

[studioant]

@nikolz0 - Your deep_sleep code works to sleep and wake the D1, but it draws 2mA while sleeping with your code. The ESP.deep_sleep function (as I measure) draws ~100uA. Is your code more of a 'light sleep' ?
Could you comment your code? Let us know what each line is doing please? I understand you're manipulating a register in some sequence?

[studioant]

@nikolz0 I refer to current consumption during sleep mode, specifically, the sleep mode function you have created. I measure it at a constant 2mA. But with Andreas Spiess (in this video: https://www.youtube.com/watch?v=rfPwOtoGO4E ) mod of cutting the 3V3 trace powering the onboard LDO and UART, current during ESP.deepSleep is measured at around 25uA.
My question to you is this, what more is required within your function to get the current consumption down this low for these knock off boards?

[inter-coder]

Here is a trick that solved my problem.
On the D1 mini-board, I pull up pins D3 and D4 with 220k resistors and now it wakes up without any problems from a deep sleep

[fsommer1968]

Here is a trick that solved my problem.
On the D1 mini-board, I pull up pins D3 and D4 with 220k resistors and now it wakes up without any problems from a deep sleep

According to the schematics original Wemo1 D1 mini already have pull up resistors on D3 and D4 (12K). Therefore a correct populated board provided the effective resistance would be 11,38K instead of 12K.

[kghxkgh]

Thanks @leofds, I have battled with this issue for months on and off. Was finally able to get the Lolin Nodemcu v3 to wake up from deepsleep using a 220resistor between SD0(MISO) and 3.3v.
(this is in addition to the bridging of GPIO16 and RST of course)

[leofds]

Thanks @leofds, I have battled with this issue for months on and off. Was finally able to get the Lolin Nodemcu v3 to wake up from deepsleep using a 220resistor between SD0(MISO) and 3.3v.
(this is in addition to the bridging of GPIO16 and RST of course)

I recently discovered a new problem. With the resistor it wakes up, but in my case the boot is slower and once it didn't start the application.

The supplier said it was a bad batch, in the new batch the problem does not occur.

[gordoasan]

Thanks @leofds, I have battled with this issue for months on and off. Was finally able to get the Lolin Nodemcu v3 to wake up from deepsleep using a 220resistor between SD0(MISO) and 3.3v.
(this is in addition to the bridging of GPIO16 and RST of course)

This worked great for me, thank you so much