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

[petrilloa]

Basic Infos

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

Platform

• Hardware: ESP-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
universam1/iSpindel#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);

2. What happens if you use the instant version?
3. What happens if you sleep with a mode other than the default?
4. 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);

2. What happens if you use the instant version?
   Checked, same result

3. What happens if you sleep with a mode other than the default?
   Checked, same result

4. 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?

[manj9501]

Your code made it work for 12 cycles before it woke up and refused to connect to WiFi, yet again.

[manj9501]

@GeoX234 you get that message since you don't have this secrets.h file

[Colkerr]

do you mean to wait 5 seconds between each attempt to connect ? I have 50ms. If your wifi is slow for some reason you probabaly give up before it's made many tries.
Anyway I've flashed you code but with my credentials and it's running fine so far - 20 updates. I'll leave it running for an hour but I suspect it's fine.
No it's not. It does occasionally not connect first time and then the 5 secs per attempt cause a long period without anything happening. I'll change to 50ms and leave it for a while.
No still a problem.

[manj9501]

While I'm glad that you are able to replicate the issue, it leads me to suspect that the way this code is written is the issue. What's your take on it?

[Colkerr]

I'm going to pass you my code that works but I have to test it first as I've extracted it from a larger program. I recall having a bit of trouble when I first starting deep sleeping but now I have lots of programs working in different ways, but I always copy what worked before. I'll be as fast as possible but may be tomorrow evening before I've give it a good check and replied. Also I've used wifimanager in the program I'm checking but I have another that doesn't so I need to figure out what's closest to your code but which works.

[Colkerr]

Might as well let you have what's working currently but I'll leave it going overnight. This isn't the fastest way to connect but that only matters if you are running from battery. If it matters to you I will send you a longer version - I store a flag in RTC memory so my code knows whether it's power up or wake up and it connects differently since it knows wifi.begin() should work on wake up but for power on the ssid and password are needed. (I don't know how you posted code so neatly.)

//Demonstrate fast WiFi reconnection after deepSleep. Also Reset reason, and deepSleep.
//#include <WiFiManager.h> //https://github.com/tzapu/WiFiManager
#include <ESP8266WiFi.h>
#include "ThingSpeak.h" // always include thingspeak header file after other header files and custom macros
char ssid[] = "xxxxxxxxxx"; // your network SSID (name)
char pass[] = "xxxxxxxxxx"; // your network password
unsigned long myChannelNumber = xxxxxxxxxx;
const char * myWriteAPIKey = "xxxxxxxxxx";
const int iIntervalSecs = 20, iLongWaitSecs = 1000;
bool DEBUG = 1;
int number = 123;
WiFiClient client;

String sFileName, sFileDate, sFileTime;

void setup() {
Serial.begin(9600); // start up serial port
Serial.println();
Serial.print( FILE); Serial.print(TIME); Serial.println(DATE);
Serial.println(ESP.getResetReason().c_str()); // this should show power up here when turned on
enableWiFiAtBootTime(); //for releases >=3
ThingSpeak.begin(client); // Initialize ThingSpeak
WiFi.mode(WIFI_STA);
WiFiTasks();
}

void loop() {
Serial.println(millis()); Serial.println(" when connected");
int x = ThingSpeak.writeField(myChannelNumber, 1, number, myWriteAPIKey);
if(x == 200){
Serial.println("Channel update successful.");
}
else{
Serial.println("Problem updating channel. HTTP error code " + String(x));
}
Serial.println("I'm awake, but I'm going into deep sleep mode for 20 seconds");
ESP.deepSleep(iIntervalSecs * 1e6);
}

void WiFiTasks() {
int counter = 0;
WiFi.begin(ssid, pass);
while (WiFi.status() != WL_CONNECTED) {
delay(10); // use small delays, NOT 500ms
if (++counter >= 1000 ) {
Serial.println("cannot connect, sleep and try later ");
ESP.deepSleep(iLongWaitSecs * 1e6 );
}
}
Serial.print(" tries = "); Serial.println(counter);
}

[manj9501]

Brother @Colkerr, it is with great joy that I tell you that your code has been running perfectly fine on my NodeMCU as well as my bare ESP12F module, for over 3 hours now🥳
Thanks very much for helping me out!

But I wonder what exactly was wrong with the code I was using previously?
I mean what exactly are the best practices here?

[Colkerr]

I want to figure that out also. It might be the weekend before I have time. But one thing I discovered recently, the ESPs can arrive with the wifi flash area in a mess which glitches wifi, so always use the compile option to reflash all when it's new. Also I include the enableWiFiAtBootTime() as some say it's needed for the newer IDE versions.

[Colkerr]

@manj9501
I changed this section in your code and think it fixes the problem. I took the WiFi.begin(ssid, pass); out of the while loop. (And also reduced the delay(5000) to 50 though that wasn't the problem.)

if(WiFi.status() != WL_CONNECTED){
Serial.print("Attempting to connect to SSID: ");
Serial.println(SECRET_SSID);
WiFi.begin(ssid, pass);
while(WiFi.status() != WL_CONNECTED){
Serial.print(".");
delay(50);
}
Serial.println("\nConnected.");
}

[sendcard]

YESSS !!!! Like others have stated above...... I can also confirm that this fix WORKS !! THANK YOU Sanc0Pansa !!!

Problem: D1 mini (clone with ESP8622MOD, no VENDOR print) doesn't wake up after "deep-sleep" with a software timer. You might observe a dim flash of the built-in LED, when the RTC module tries to boot up the chip for the first time. But the module does not boot and is frozen right there. The only way to continue then is to press manually the "Reset Button". The fix:

1. STANDARD : Connect RST pin to D0 pin with a simple wire bridge.
2. On the bottom of the ESP module are 6 unlabeled connectors...internally connected to the flash memory chip. You need to solder a 10K resistor to the second connector from the left (GPIO7/SD0/MISO) and connect to a point with VCC 3,3V. For me it was the best to connect to a point on the backside. To the RESET push button, lower left corner. This pad carries also VCC 3.3V.

BAMM !! D1 mini clone boots with RTC timer periodically...runs a sketch, connects to Wifi.....goes back to sleep...and so on.... Powered by 3.3V batteries I measure (simple digital multimeter) in deep sleep mode a current consumption of 330uA. While USB is suspended, the CH340 USB bus convert chip takes still 90 to 150uA according to the data sheet....

@GeoX234 You are a genius! I follow your steps and save my D1 mini from deep sleep. However, because of shorting EST and D0, the D1 mini can't be flashed. Is it possible to add a resistor between EST and D0 to make it flash?

[Colkerr]

@sendcard I use a resistor. 10k or more even seems to work fine.

[sendcard]

@sendcard I use a resistor. 10k or more even seems to work fine.

Thanks @Colkerr. I have used 510 ohm, and it works perfectly.

[sendcard]

To summary up:
RST --510 ohm -- D0
GPIO7 -- 10k ohm -- 3.3V

[n89thanh]

@GeoX234 I also tried connecting to the corner of the reset button like in your picture and IT WORKS! Thank you and everyone for solving this years-old issue!

[gagabla]

Hey guys, after weeks of frustration i came across this ticket and the solution/workaround with pullup resistor seems to work for everyone ... just not me. Out of 7 ESP12f modules from 2 suppliers (via aliexpress) only one 1 working (=waking up on first reset from deep sleep) without any additional measure, and one additionally started to work by adding the pull-up resistor 10k from MISO to 3.3V.

I also tried lower resistor value 1k but no help. I also checked the power-supply, now i am using a lab-power-supply and i tried also slightly higher voltage since someone earlier mentioned that even slight drop below 3.3 V might affect wakeup, again no help.

One additional observation i have is, that in "zombie mode", the MISO-signal shows permanent square signal with roughly 300k Hz frequency which is very different from the short sequences observed when waking up properly.

And one more observation i cannot currently make sense out: for my use-case i dont have GPIO16 connected to RST becaues i only want to wakeup on button press, still, if i enter deep sleep with timer, something seems to happen when the timer expires:

1. ESP running normal, running my code: MISO signal stable at 3.3 V, almost no ripple, 18 mA current
2. ESP entering deep sleep: MISO signal stable at 3.3 V, almost no ripple, current below what my power-supply can measure
3. ESP deep sleep timer expired (but not connected to RST as mentioned): short flash of on-board LED, MISO signal starts jittering in a range of 0.8 V (!), 16 mA current (another kind of zombie mode??)
4. once i press reset button manually, ESP enters zombie mode described by all the others, i get the one line output but not more, MISO shows permanent square signal, 36 mA current

So while the state in 4. is the zombie mode well known here in the ticket, i think in 3. i have yet another strange state which i cannot understand how it can exist since i havent connected the wakeup pin ...
This is not an issue when i enter deepsleep without timout (/timout=0), so i am just curious if someone has a theory why the chip reacts to the timeout even if i dont have the wakup signal connected.

@leofds how did you come up with this solution which worked for you and all the others back in 2020? Maybe if i can understand your train of thought, i could see what is the difference in my case and take appropriate measures.

[emaddoost]

Hi everyone,
Can anyone provide a hint on how to apply this solution to Arduino Nano ( Atmega328p)? it has different pins than you discussed so I don't know to which pin should I connect RST (and with how much resistor) to solve this wake-up problem.
My problem is that my DFPlayer mini module does not work correctly after wake up, so I think your solution may apply to my case as well.
Thank you in advance.

[Colkerr]

I doubt it's the same cause. Nano is a different microprocessor family as you have noted.

[n89thanh]

@gagabla you say you're connecting with MISO... Which GPIO pin exactly are you referring to? Make sure you're connecting GPIO7, not GPIO12.

[gagabla]

@n89thanh thanks for jumping in, i connected the resistor to the pin labeled with MISO, so i hope this is the correct one since i cannot find the mapping to GPIO7 in the available material for esp12f / esp12e.


I further connect the resistor to 3.3v then with a little clamp since i want to have my esp12f modules to be exchangeble (because of this issue, obviously) and the pogo pins dont work so well when i solder into the pins.

There were a few images above here in the thread, eg from manj9501 and from sendcard which seem to connect to the same pin on a similar board (and for them it seemed to work!).

Any other idea? Do you have an explanation why this resistor is helping for everybody else so i could check what is different for me?

[Craig1516]

@gagabla. Here is a plugable solution I designed that allowed me to insert different radios in to a PCB. It is kind of a bed of nails using segmented guitar strings. It is quite effective. This wasn't for a ESP 12, but the idea could be adapted. There were many other plugable solutions discussed in the rest of the [post]. Hope it helps. (https://forum.mysensors.org/topic/11954/most-reliable-best-radio/218?_=1655321080395)

[Colkerr]

@n89thanh thanks for jumping in, i connected the resistor to the pin labeled with MISO, so i hope this is the correct one since i cannot find the mapping to GPIO7 in the available material for esp12f / esp12e. I further connect the resistor to 3.3v then with a little clamp since i want to have my esp12f modules to be exchangeble (because of this issue, obviously) and the pogo pins dont work so well when i solder into the pins.

There were a few images above here in the thread, eg from manj9501 and from sendcard which seem to connect to the same pin on a similar board (and for them it seemed to work!).

Any other idea? Do you have an explanation why this resistor is helping for everybody else so i could check what is different for me?

Without seeing everything you are doing it's impossible to know but here is my fix which has worked for all 8 faulty ones I had.

[gagabla]

@Craig1516 thanks for the tipp, i am quite happy with the pogo pins/clamps though. Not so cheap (20€ on aliexpress ) but very nice to handle for prototyping. Here is how it looks in my setup:

@Colkerr yes, i am aware of all the happy users of the MISO workaround above ... just .... for me it is not working consistently :-( (only for one board out of 7)
My setup is the bare minimum to reproduce the issue i belive, see foto above.
I have connected

• RST via push-button (green cable) to GND
• ENABLE with pull-up 10k to VCC
• VCC to 3.3 V lab power supply
  
• TX/RX to FTDI for programming via USB
• GPIO0 with pull-up 10k and push-button to GND for programming
• GPIO15 with pull-down 5k to GND (helped to improve reliability of flashing)
• GND to GND
• AND the magic MISO/GPIO7 of course, connected with 10k pull-up to VCC, which does not help for me

Thats it! I can reproduce the issue on most of my modules, i need two resets via push-button for EPS8266 to actually start once it is in deepSleep. When resetting while it is running normally, reset works every time.
(but i also have 1 module where the issue is not present right from the beginning and one module where the issue vanished once the 10k were used for MISO).

Code is also minimal:

void setup() {

  Serial.begin(74880);
  Serial.println("Started");

  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);  // LED on to see something
  delay(1000);

  Serial.println("Going to sleep");
  ESP.deepSleep(0, WAKE_RF_DISABLED);
}

void loop() {}

So if only i could understand what motivates the MISO workaround , then i might also be able to find out why it does not work for me ... like i wrote above, i could already observe that when ESP8266 does not wake up properly and goes to zombie mode, MISO pin is permanently going crazy with a square pattern with 300k Hz => seems that communication with flash memory not working normally.

[Craig1516]

@ gagabla. These clamps look like what I've wanted for a long time. Just bought several. Thanks for the idea.

[Craig1516]

@gagabla. Forgot to mention, Andreas Spiess has a great video on the zombie zone. I've found my projects have drifted there occasionally. Not only does it render your project dysfunctional, it is also a high current event and will kill your battery... if you are using one.

[gagabla]

@Craig1516 just pay attention that you fetch one with the right pin spacing of 2 mm for esp11, for other spacings there are much cheaper offers, but for 2 mm had to by the expensive stuff.

Thanks for the hint to the videos from Andreas, I was not aware of those. I checked few which are related to deep sleep but couldn't find any mention of zombie Mode so far, do you remember which video it was?

As written in previous comment I can observe two flavors of zombie Mode, first one consumes about 15 mA (although esp is not running) and second flavor of zombie mode ( the one typically observed here in the thread) draws 36 mA.

[Craig1516]

I spent some time this evening looking. Never found it. But the basic takeaway I remember is that if the MCU falls in to a lower voltage as indicated by the datasheet the MCU will not recover and sit there churning, as you have found. How to avoid: I remember having a power supply with adequate capacitance and filtering was key. If I come across it I will certainly send your way! Craig From: gagabla ***@***.***> Sent: Friday, June 7, 2024 11:30 PM To: esp8266/Arduino ***@***.***> Cc: Craig1516 ***@***.***>; Mention ***@***.***> Subject: Re: [esp8266/Arduino] ESP.deepSleep hangs after wakeup - ESP12F (Working on older chips) (#6007) @Craig1516 <https://github.com/Craig1516> just pay attention that you fetch one with the right pin spacing of 2 mm for esp11, for other spacings there are much cheaper offers, but for 2 mm had to by the expensive stuff. Thanks for the hint to the videos from Andreas, I was not aware of those. I checked few which are related to deep sleep but couldn't find any mention of zombie Mode so far, do you remember which video it was? As written in previous comment I can observe two flavors of zombie Mode, first one consumes about 15 mA (although esp is not running) and second flavor of zombie mode ( the one typically observed here in the thread) draws 36 mA. — Reply to this email directly, view it on GitHub <#6007 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHYUHCG2OOMIIJUAK6OZZDZGKQHBAVCNFSM4HHT54AKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJVGU4DGNJWG42Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>