ESP8266 Community Forum

- Sun Jun 18, 2017 9:21 am #67315 I'm not inclined to just blame the power supply.

For testing I'm using power from the download cable direct from my PC.
Some units work, others fail.

I've started down a different debug path.

One thing I have noticed is that a brand new Huzzah board does not show the very dim DIO0 LED when it goes into deep sleep. These seem to work very reliably for a while.

But, I board that I've been using for a while, doesn't start with a dim DIO0 LED, but if I put a DVM on that pin, it light up and stays lit.

And finally, a board that fails regularly, always lights the DIO0 pin dimly when it goes into deep sleep. And I've seen others mention the dim LED.

I decided to figure out why the LED behavior would change over time. The thing I found with all the boards (old to new) is that they all have 1.75V on the DIO0 pin when it goes into deep sleep. This struck me as strange because it's at 3.0V when the code is running (but not accessing that pin).

The more I looked at it, I realized that because of how the Huzzuh is wired, it's not a pure pullup on the DIO0 pin, but instead it's a pullup through a LED, and that LED is dropping some of the voltage. So, the fact that the LED is lit dimply means that current is flowing and being wasted while it's in deep sleep.

but more importantly, the deepsleep level on that pin is not a proper 3.0V. It's right in the in-between range. And, depending on the given state of the LED, resistor and input gate, there may be some issues when it tries to startup and read that pin.

So, I've added an additional 22K pullup to 3.0 V on the DIO0 pin to see whether this helps to stabilize the reset.

The first think I notice is that the LED is no longer coming on dim. It goes off like on a new Huzzah module.

Time will tell if this fixes the problem.

- Sun Jun 18, 2017 4:05 pm #67325 Maybe it is a design flaw with the Adafruit HUZZAH? I've not tried the Huzzah but the others like NodeMCU, Wemos D1 MIni, or just an ESP12 on a white breakout board work ok for me, why not give one of those a try?

- Wed Nov 07, 2018 6:38 pm #79064 Hi guys.

I know that this thread has not been used for quite a while but I just stumbled about the very same issue. Luckily I remembered having found an issue with the nRST pin current (and posted here) in late 2016.

Maybe this information here helps others seeking for an answer why deep sleep sometimes works and sometimes get stuck even if HW and SW parts seem to be OK.

I have no access to Adafruit modules, but I noticed the same issues on e.g. Wemos D1 Mini boards as the source of error is no PCB design flaw but something inside the ESP8266 which I cannot track down further.

Here are my observations:
On most modules the RST pin is connected to 3.3V by a 10k resistor and to GND by a 100nF capacitor and, in parallel, the RST pushbutton.
For deep-sleep operation I connected GPIO16 (labeled D0 on Wemos D1 Mini) through a 1.5k "fear" resistor to RST. The 1k5 resistor is small compared to the 10k pullup and should provide a sufficient low level to the RST pin.

The device boots normally, goes to deep-sleep, but a the time when it should reset itself to get out of deep-sleep the serial output only shows:

Code: Select allDeep sleep initiated.
ets Jan  8 2013,rst cause:5, boot mode:(3,6)
ets_main.c


Afterwards the chip is not responsive any more and needs a hard reset. That game can be repeated over and over, the chip is stuck when trying to end the deep-sleep mode.

Using even higher resistors results in exactly the same behavior. Using less than 1k resistors results in the expected, fully funtional deep-sleep behavior:

Code: Select allDeep sleep initiated.
ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v3de0c112
~ld
��������
Firmware started
ResetCause: 5, Wake up from deep-sleep
Deep sleep initiated.
...


Conclusion:
The RST pin behaves somehow dynamically, the current flowing out of this pin is higher than expected and, in addtion, depends on the mode the chip currently is in (see my post #58904).
Using a 1k5 resistor between RST and GPIO16 (which pulls to GND after end of deep-sleep) yields in a voltage of 1.49V at the RST pin (a 2k7 resistor gives an increased voltage of 1.84V).
Due to that current sourcing behavior the RST pin is driven to a level which is not properly defined as logical high or low. It could be detected high, or low, and this detection may vary with voltage, age, temperature etc.

Best advice is to use a direct wire connection or a really low resistance like 100 ohms for current limiting purpose e.g. when the RST button is pressed. This helped in my case to get deep-sleep work reliably.

Best regards,
Kelrob

- Wed Nov 07, 2018 8:46 pm #79066 Don't use a direct wire - you won't be able to flash the chip automatically.

As discussed in several posts, the best solution is to use a Schottky diode like a BAT43. This will give you consistent deep sleep operation while still letting you perform flash operations