3

I'm working with the following circuit using a NodeMCU: schematic

I have the solder jumper bridged between RST and BTN. In addition to what's in the schematic, pins 2, 3, and 4 of J1 are connected to the cathodes of 3 LEDs powered via pin 1 on the same connector.

I'm using the following code to test waking up from deep sleep:

#include <Arduino.h>

void setup() {
  delay(1000);
  Serial.begin(9600);
  Serial.println("start");
  ESP.deepSleep(0);
  while (1);
}

void loop() {
}

I build the code with -DDEBUG_ESP_PORT=Serial -DDEBUG_ESP_CORE and observe the following behaviour on the serial port after startup:

SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀

This looks as expected to me (except maybe for the trailing ␀?). The current consumption is as low as I'd expect from deep sleep. I now pull RST low by pressing the push button once and see a few bits of garbage (different every time) being output in the device monitor - nothing else happens:

SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀␀�

At this point current consumption increases from single-digit milliamps to a few tens of milliamps. However, a full reset doesn't seem to happen and my program doesn't appear to execute again from the beginning.

If I now pull RST low again with a second press of the push button I see a bit more garbage being output before a proper reset seems to finally happen:

SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀␀�␕{��1S�
SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀

This cycle then repeats, always requiring two button presses for a reset.

Similarly, if I try to upload a new program to the ESP8266 after it entered deep sleep initially, the upload will fail with:

A fatal error occurred: Timed out waiting for packet header
*** [upload] Error 2

Trying the upload again right after that does succeed. The next upload after that will fail again, and so on.

Based on those observations it looks to me like the ESP8266 doesn't get fully reset on the first button push, or it does get reset but enters some state in which it's not executing my application for some reason.

What could be the reasons for that? Is it something I can work around either in hardware or code?

Thanks!

4
  • 2
    Add Serial.flush(); after your print. Otherwise you'll never see it print anything. – Majenko Apr 24 at 17:52
  • @Majenko I do see the serial output I'm expecting before going to sleep, and using other indicators such as the LEDs or buzzer to find out if my program is re-executed after a reset have the same behaviour of requiring two resets. – Florian Ragwitz Apr 24 at 18:21
  • 1
    random ideas: might want to hard pull gpio 0 and 2. might need caps on vcc, rst, etc. might be a noisy switch on 16. Could be a power-hungry attachment; does the problem persist w/o buzzer and LEDs? – dandavis Apr 24 at 21:15
  • I ended up taking the ESP8266 out of the circuit to test the reset behaviour in isolation and to compare it to other ESP8266s. It turns out that only the one unit out of a total of 6 that I tested had that behaviour. Putting a different ESP8266 back into the same circuit works just fine and only one reset is needed. I'm not sure if there perhaps was some damage to that one unit, but just replacing the component was more practical than debugging it further. – Florian Ragwitz May 8 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.