ESP8266 Community Forum

- Sat Nov 06, 2021 1:39 pm #92780 I'll have to admit that I've reached the end of the line on this one. The only next stage I can think of is to actually start watching the connection protocol at the byte level because nothing is getting traction.

I've been using a pile of WEMOS/LOLIN D1 mini boards for many projects over the last few years. Generally they work like a champ and I've been very happy with the platform. The last project I did with one was the around the start of summer 2021 and everything worked fine. I decided to use one for a new project this week and I am no longer able to program any boards with any of my setups. I'll do my best to summarize here:

OS: Linux Mint 19.3 and Linux mint 20 (two different physical computers)
USB cables: tried multiple known working cables on multiple USB ports on both computers
Devices: Wemos/LOLIN D1 Mini boards, both ones labeled "D1 Mini" and "D1 m1 n1 / v3.0.0"
-- I've tried three of each type in my testing

OS setup: User is in the dialout group with rw permissions on the /dev/ttyUSB0 dev file
-- All ESP8266 devices show up as /dev/ttyUSB0

I am able to connect to the devices using serial modem packages:
screen /dev/ttyUSB0 115200
minicom

In both packages the serial output is what I'd expect. There's some boot junk and then the old programs on the devices start putting out text as appropriate so their serial setup is working.

I generally use ArduinoIDE for dev work, which is just calling esptool.py. I have the official esp8266 libraries installed. I've tried various versions of the esp8266 driver packages:
* 3.0.2
* 3.0.0
* 2.7.4
* 2.5.0
* 2.5.1
* 2.6.x (a few of them)

I've tried the "LOLIN(WEMOS) D1 R2 & mini" device along with: D1 mini (clone) and D1 mini pro. No difference in behavior.

After building the blink sketch, I've tried running the esptool.py program on the command line and it's output is exactly what I saw in the AruinoIDE terminal/status window (it's just printing STDOUT from the command line tools anyway).

I have Python 2.7.17 on one of the Linux machines. That's what esptool.py is calling.

The best output I've gotten so far from an old version of esptool.py (version 2.5.1) is:

Code: Select all
/home/acrandal/.arduino15/packages/esp8266/tools/python/3.7.2-post1/python /home/acrandal/.arduino15/packages/esp8266/hardware/esp8266/2.5.1/tools/upload.py --chip esp8266 --port /dev/ttyUSB0 --baud 115200 --trace version --end --chip esp8266 --port /dev/ttyUSB0 --baud 115200 --trace write_flash 0x0 /tmp/arduino_build_182769/Blink.ino.bin --end

TRACE +0.102 Timed out waiting for packet header
.TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=
    0707122055555555 5555555555555555 | ... UUUUUUUUUUUU
    5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU
    55555555                          | UUUU


The latest esptool.py output looks like this:

Code: Select allTraceback (most recent call last):
  File "/home/acrandal/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/upload.py", line 66, in <module>
    esptool.main(cmdline)
  File "/home/acrandal/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool/esptool.py", line 3552, in main
    esp.connect(args.before, args.connect_attempts)
  File "/home/acrandal/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool/esptool.py", line 529, in connect
    raise FatalError('Failed to connect to %s: %s' % (self.CHIP_NAME, last_error))
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 154, in apport_excepthook
    os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o640), 'wb') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/var/crash/_usr_bin_python3.6.1000.crash'

Original exception was:
Traceback (most recent call last):
  File "/home/acrandal/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/upload.py", line 66, in <module>
    esptool.main(cmdline)
  File "/home/acrandal/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool/esptool.py", line 3552, in main
    esp.connect(args.before, args.connect_attempts)
  File "/home/acrandal/.arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool/esptool.py", line 529, in connect
    raise FatalError('Failed to connect to %s: %s' % (self.CHIP_NAME, last_error))
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header


I'm using 115200 for the baud rate to be safer, though I've tried 57600, 9600, 921600 (which is changed silently to 460800 in the esptool.py script anyway). I've always used the default settings for the programming options in ArduinoIDE in the past without issue.

ArduinoIDE is set to use the correct serial port (/dev/ttyUSB0).

I've tried various combinations of the reset button before and during programming attempts. I've held it down, I've pulsed it, I've tapped it as programming started (Adafruit Feathers made me quite twitchy about reset timing). I also grounded D3 during power on and tried some variations of that with the reset button, but I haven't seen the text in a serial session about flash programming mode. I've *never* had to do that before with these devices, but if it's likely the direction to continue I can keep digging there.

I have done apt purge modemmanager from my systems since it sometimes interferes with serial communications.

The Linux Mint 20 machine is a pretty fresh OS install. I had to install the tools clean to start this project while the Mint 19 machine has been used to program ESP8266 boards before and was (I thought) in a known working state to begin with.

*Nothing* seems to make a difference in this situation. No permissions, library versions, tool reinstalls, reset button timings.

Please anyone give me anything to try next. This has been hours of hair rending and head banging. I've loved these boards in the past and there's lots of projects on my slate that would use them (I've got about 20 of them in a box ready to go), but I'm at a total standstill now. Shy of starting to tear apart esptool.py in more depth to debug the handshake for programming I don't know what to do.

- Fri Jan 13, 2023 9:11 pm #95797 I know this is an old post but I just wanted to share since I experienced the same problem with my D1 m1 n1 v3.0.0 board.

I managed to get the board into programming mode by pulling out the breadboard and adding a button from D3 (GPIO0) to ground. I also needed to add a resistor to 5V to get the button press to register. Now I can put the board into programming mode by holding down the GPIO0 button, plugging the board in, pressing reset, and releasing both. Not sure what the correct combination actually is, but this works for me so I'm going to run with it.

Was able to upload the "Blink" sketch with no issues.

- Sun Jun 11, 2023 11:57 pm #96527 Although I am aware that this is an old post, I felt compelled to publish it because my D1 m1 n1 v3.0.0 board had the exact same issue.

By taking off the breadboard and connecting a button from D3 (GPIO0) to ground, I was able to bring the board into programming mode. To make the button press register, I also required to add a resistor to 5V. By holding down the GPIO0 button while connecting the board, pushing reset, and then releasing both buttons, I can now put the board into programming mode. I'm not sure whether this is the right combo, but it works for me, so I'm going to stick with it.

basketball stars