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?

[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: ***@***.***>

[co61]

Hello
I'm facing the issue of this discussion, I did read all of it, test all of it and run some test I saw on different linked discussions.
None of it worked for me but i have the exact same problem. Did not wake up well, I need to push my reset button twice to get it ou of deepsleep or once after GPIO16 trigger its signal to RST...
I'm running out of solutions and I'm oppen to new suggestions
Thanks for help

[Colkerr]

Have you had wake up working on another esp8266, to eliminate something you are doing ?

[co61]

I had my code working an ESP32 DEv Module. This is my first ESP8266 module, but for the 5 I have it's the same behavior.
For testing I did a simple code that blink the build in LED twice and send a message trough Serial. All goes well at first boot but on wake up I have this message and nothing else (exept a little blink on the LED) : ets Jan 8 2013,rst cause:2, boot mode:(3,6) I must press RST button again to have the module wake up fine.
I tried the resistor between GPIO7 and 3.3V, the only thing that change is the message ets Jan 8 2013,rst cause:2, boot mode:(3,7) but nothing happend after that.
using the modified version for deepsleep do not work, it never wake up with it. (not even a message or a blink on the build in LED)
I also tried different code that was shared on this topic or other topic.

[Colkerr]

I only know that with GPI016->RST , the resistor connected as shown in my photo above on Jun 5, and the code I posted above on Apr 2nd (which is longer than you need just to prove wakeup), then all my faulty ESP8266's work.

[co61]

Ok thankyou for your answer. I will test this again and see. How did you set up the rest of the connections for EN, GPIO15, GPIO0, GPIO2. Do you have pull up resitors ?
I will try to have the exact same wiring and see if it works.

[marcosjl31]

Hello
I'm trying to get deep sleep working on two d1 mini pro boards (purchased from 2 different sellers).
I've tried cable/resistor/diode between D0(GPIO16) and RST pins : the board does not wake up stuck at

rst cause:2, boot mode:(3,6)

I also tried to use alternative nk_deep_sleep function from this thread : the boards keep constantly rebooting without staying the deep sleep time (3s in my case) in deep sleep mode.

I'm using PlatformIO code from : [esp8266-alternative-deep-sleep](https://github.com/nokxs/esp8266-alternative-deep-sleep.git )

I don't know what to do next...

[arnabdasbwn]

@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.

I am exactly in the same situation like you , The resistor on the MISO pin helped for one module. which looked like this :

But not working for the module that looks like:

Anyone tried on this ESP-12F Module?

[sendcard]

Today I tried to use D1 mini v4.0, I have add 510ohm % D16 and RST, it can’t wake up. I used to do that. May be you can use another d1 miniOn Nov 19, 2024, at 05:28, marcosjl31 ***@***.***> wrote: Hello I'm trying to get deep sleep working on two d1 mini pro boards (purchased from 2 different sellers). I've tried cable/resistor/diode between D0(GPIO16) and RST pins : the board does not wake up stuck at rst cause:2, boot mode:(3,6) I also tried to use alternative nk_deep_sleep function from this thread : the boards keep constantly rebooting without staying the deep sleep time (3s in my case) in deep sleep mode. I'm using PlatformIO code from : [esp8266-alternative-deep-sleep](https://github.com/nokxs/esp8266-alternative-deep-sleep.git ) I don't know what to do next... —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[PerSkygebjerg]

Hi, I'm using the D1 mini V4 and all boards with LOLIN in print in white on the backside works, all other won't work.

[Tornix242]

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

I had this DeepSleep problem using some AliExpress batches, so I bought AZ-Delivery ones. And today some of these did not work as intended as the last batch looks different from the firsts.

The resistor workaround seems working so far. I need to check the battery consumption in a few days.

Here are some pictures of two different batches from AZ-Delivery. Had the same issue from Aliexpress in 2023.

Workaround being tested, so far so good.

[johnwebsiteprojects]

same problem no solution

[johnwebsiteprojects]

If someone noticed that I only have 7 pins on the socket, it is not an illusion. I'm using standard 2.54 leaving out 1 pin on each side, GPIO16 and GPIO0. This is my solution from 2mm to 2.54mm pin header.

thought it was like a brilliant solution ,not working

[PruntschSoftware]

Hello ! Have (or maybe had) the same issue ( ets Jan 8 2013,rst cause:2, boot mode:(3,6)) with this chip. I was really happy when i came across this solution - but it doesn't work for me :(

I used a 10k from GPIO 7 to 3V3 and tried several Resistor values from D0 to RST.
It changed my boot error from:
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
to: ets Jan 8 2013,rst cause:2, boot mode:(3,7)

My code is super simple also...

void setup() {
Serial.begin(74880);
Serial.println("ESP8266 has awaken!");
}

void loop() {

delay(100);
Serial.println("ESP8266 going into Deep-Sleep...");
delay(100);

ESP.deepSleep(5e6);
}
Can anyone help??

EDIT: i also tried the custom deepsleep function above, but it just resets instantly with some sort of exception. Also i don't think it is a proper reset even. Just feels like it encounters an error and restarts. If there is any solution for that, it would also solve my problem :)

[jaisor]

The 10K between GPIO7 and 3.3v fixed for my "bad" batch of D1. First time encountering this issue.

[racedeyu]

This issue is related to the Flash memory inside the module. I have several modules, including the ESP-12E and ESP8266MOD; some exhibit this problem while others do not. I've confirmed that modules with the Flash chip model "562A" have this issue. Simply swapping this Flash with the "SY25Q32" Flash from a module that doesn't have the problem causes the previously good module to exhibit the same issue. It appears the problem follows the "562A" Flash chip. Adding pull-up resistors might only resolve the issue for certain Flash chips; adding a pull-up resistor to MISO has no effect on the "562A".

[tomboul26]

The 10K between GPIO7 and 3.3v fixed for my "bad" batch of D1. First time encountering this issue. !

I tried your solution, and for me it does not work.
Did you change anything in the code?

[jaisor]

The 10K between GPIO7 and 3.3v fixed for my "bad" batch of D1. First time encountering this issue. !

I tried your solution, and for me it does not work. Did you change anything in the code?

This is my code: https://github.com/jaisor/wifi-climate-sensor/blob/main/src/main.cpp
The sleep part is in the bottom of the main.cpp. Make sure you also have a 1K between RST and D0

    #ifdef ESP32
      digitalWrite(INTERNAL_LED_PIN, LOW);
      ESP.deepSleep((uint64_t)configuration.deepSleepDurationSec * 1e6);
    #elif ESP8266
      digitalWrite(INTERNAL_LED_PIN, HIGH);
      ESP.deepSleep((uint64_t)configuration.deepSleepDurationSec * 1e6); 
    #endif```

[tomboul26]

Make sure you also have a 1K between RST and D0

Thank you Jaisor, shame on me, i forgot to do this, and now it's OK !!!