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