I'm trying to get the D1 mini to return operation after ESP.deepsleep(). The code below compiles and gives the expected output for the first run. Five seconds after the announcement that that the device is going to sleep, there is a brief flash on the on board LED and I get a string of garbage on the serial monitor. Ideas for things to try would be appreciated.

// Testing d1 mini deep sleep
// D0 and RST are connected

/*  platformio.ini:
  platform = espressif8266
  board = d1_mini
  framework = arduino
  monitor_speed = 115200

#include <Arduino.h>

void blink();

void setup() {
  pinMode(D0, WAKEUP_PULLUP);

void loop() {
  Serial.println("Going for some deep sleep");
  ESP.deepSleep(5e6); // 5e6 is 5 seconds

void blink() {
  digitalWrite(LED_BUILTIN, LOW);
  digitalWrite(LED_BUILTIN, HIGH);

As you can guess I'm running this with platformio. The output on the serial monitor is:

stefan@Cameron ~/.../Projects/Deep sleep $ platformio device monitor --baud 115200
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
Going for some deep sleep

There is a blink of the LED on the first run, nothing there either after the apparent reset.

  • I've got same issue after a deep sleep. Here is the error code @74880bps : epc1=0x40100000, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000 Fatal exception (0): But when I see this issue, if I manually push the reset button or manually plug RESET to GND, the board is rebooting and restart my code as expected. Only the wakeup from deepsleep generates this issue. Have you fixed your issue ? Thanks, – gbetous Sep 21 '19 at 16:21

The garbage is because the ESP8266 outputs boot information at 76800. This should include the boot reason and may help you understand why the code's not working as expected.

Try changing your Serial speed to 76800 in your code (just so that your messages don't end up being gibberish), use 76800 on platformio's monitor and you should be able to at least see what the D1 says it's doing.

You should see a line that ends in something like:

rst cause: x, boot mode:(y, z)

x should be 1 ("Power reboot"), 2 ("External reset or wake-up from Deep-sleep" - obviously what you want), 3 ("Software WDT" - the software watchdog went off) or 4 ("Hardware WDT reset" - the hardware watchdog timer went off)

boot mode indicates where the runtime image came from - y should be 3 ("Flash"); anything else is really unlikely for your setup.

There's more info on this at ESP8266 Reset Causes and Common Fatal Exception Causes

If you try this please post how it goes! I'd like to hear more about what's going on here.

  • Thanks a lot! The baud rate is right to capture that "garbage" - this is the output after setting the serial rate to 76800 everywhere: stefan@Cameron ~/.../Projects/Deep sleep $ platformio device monitor --baud 76800 --- Miniterm on /dev/ttyUSB0 76800,8,N,1 --- --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- Hello I'm in the setup now Going for some deep sleep ets Jan 8 2013,rst cause:5, boot mode:(1,6) ets_main.c – SEngstrom Nov 26 '18 at 5:00
  • Don't know how to format code in the comments... – SEngstrom Nov 26 '18 at 5:01
  • So the reset cause was the deep sleep wake up. The deviation in boot mode is something I'll have to dig in for tomorrow. – SEngstrom Nov 26 '18 at 5:07
  • Yeah, unfortunately there's not a good way to format comments :( bites me all the time. Boot mode 1 should mean it's trying to boot via the UART (download new code) rather than the flash. Do you have anything wired up to D3 or D4? If you do try disconnecting them or try wiring D3 to 3.3V via a high value resistor (say, 47K or more, shouldn't really matter exactly the value). More info on boot mode at github.com/esp8266/esp8266-wiki/wiki/… – romkey Nov 26 '18 at 5:16
  • So the 1 in `boot mode(1,6) seems to mean my d1 mini is expecting to download code from the UART like you say: github.com/esp8266/esp8266-wiki/wiki/… That message doesn't make a lot of sense to me. Sending code over serial doesn't seem like something the board can request. Anyway - a little frustrated with this - I do appreciate all the input from folks, but for now deep sleep is eluding me. – SEngstrom Nov 27 '18 at 4:08

Try and clear out the whole memory. Maybe there is something that is messing it up.

I tried your code and it works for me. I do not have a D1 mini but I can't see any reason for it not to work. (due to hardware reasons)

I would include a delay and then output a newline in the setup. As it is your loop print is written after the boot info and gets lost at the end of the line.

Like I said, your code worked for me. But I find this more user friendly. https://raw.githubusercontent.com/wemos/D1_mini_Examples/master/examples/02.Special/DeepSleep/Blink/Blink.ino

Check again your connections. (I'm sure you have done that a dozen times)

  • Thanks. Did what I think is a firmware reset by connecting D3 to GND for 5 seconds. Added a delay and a Serial.println() in setup(). Same results. I came across the link you suggested before but there is no difference if I put it all in setup(). It seems it is not only that the Serial communications are borked, the blink() should still happen if the code gets there (and it should reset again a little later). – SEngstrom Nov 26 '18 at 3:21
  • Yeah. Like I said, your code works. (even though I don't like it) Do you have another board you can try? – Rudy Nov 26 '18 at 3:34
  • I think @Rudy is right. I just tried the code on a D1 mini and it works fine for me. You can completely reset the firmware with PlatformIO with a command like this (you may need to change the serial device name): ~/.platformio/packages/tool-esptool/esptool -vv -cd nodemcu -cb 115200 -cp /dev/cu.usbserial-1430 -ce – romkey Nov 26 '18 at 4:31
  • Thanks John - executing that results in: stefan@Cameron ~ $ ~/.platformio/packages/tool-esptool/esptool -vv -cd nodemcu -cb 115200 -cp /dev/cu.usbserial-1430 -ce – esptool v0.4.13 - (c) 2014 Ch. Klippel <ck@atelier-klippel.de> setting board to nodemcu setting baudrate from 115200 to 115200 setting port from /dev/ttyUSB0 to /dev/cu.usbserial-1430 espcomm_erase_flash opening port /dev/cu.usbserial-1430 at 115200 error: cannot access /dev/cu.usbserial-1430 – SEngstrom Nov 26 '18 at 5:05
  • seems there were some success, but no change in the behavior when running the code. – SEngstrom Nov 26 '18 at 5:05

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.