Wemos D1 Pro: Timed out waiting for packet header

[hunmik]

Operating system

windows 10

Python version

What Chip

ESP8266EX

What development board or other hardware is the chip attached to

Wemos D1 Mini Pro

Is anything else attached to the development board, except for the serial flasher connections?

No any connection.

Are you running esptool.py from an IDE such as Arduino or Eclipse?

Arduino IDE 1.8.12 esptool.py 2.5.2- 2.7.1 (same results) selected device: lolin(wemos) d1 mini pro

Full esptool.py command line that was run:

I don'n know how to see that.

Full output from esptool.py

esptool.py v2.6 2.6 esptool.py v2.6 Serial port COM10 Connecting.... Chip is ESP8266EX Features: WiFi MAC: 50:02:91:e9:fc:64 Uploading stub... Running stub... Stub running... Changing baud rate to 460800 Traceback (most recent call last): File "C:\Users\mecseri\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.5.2/tools/upload.py", line 25, in esptool.main(fakeargs) File "C:/Users/mecseri/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 2677, in main esp.change_baud(args.baud) File "C:/Users/mecseri/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 104, in inner return func(*args, **kwargs) File "C:/Users/mecseri/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 665, in change_baud self.command(self.ESP_CHANGE_BAUDRATE, struct.pack('<II', baud, second_arg)) File "C:/Users/mecseri/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 332, in command p = self.read() File "C:/Users/mecseri/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 277, in read return next(self._slip_reader) File "C:/Users/mecseri/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.5.2/tools/esptool\esptool.py", line 1877, in slip_reader raise FatalError("Timed out waiting for packet %s" % waiting_for) esptool.FatalError: Timed out waiting for packet header esptool.FatalError: Timed out waiting for packet header

Do you have any other information from investigating this?

I'm struggling with this for days. I have Wemos D1 MiniPro modules worked in the past, but now I cannot connect them any more. So now I have 4 modules bricked. What happened:

• uploaded one specific sketch to the device, worked well (many times, development going on)
• then something happened
• error message above appears at upload
• I tried with older, known good modules, same error
• removed all connections, same error

Purchased new modules:

• Brand new out-of the box. New USB cable. No any connection to the module, only the USB.
• update the same sketch as before
• first 2 or 3 attempts upload does not fail, but sketch does not work (I assume chip does not enter to run mode).
• After that the error starts, and locks on this status, cannot upload any sketch

Other computer other sketch:

• made a brand new Arduino install on a new computer, empty sketch, same error
• reverting back to version ESPtool library to 2.5.2 (esptool 2.6) as it was suggested in other thread : same result

-meantime I could upload to NODEMCU 1.0 a different sketch (many times, no problem)

Is there any other information you can think of which will help us reproduce this problem?

• Is it possible that uploading a specific sketch may brick the device? I cannot imagine.

• As problem same on a brand new module, virgin installation on new computer it cannot be problem originated from external hardware.

• updated windows USB driver for SIL2104, same result

[hunmik]

The communication recorded with logic analyzer The last packet received, module does not respond on this:

[projectgus]

Hi @hunmik ,

If you change the baud rate from 460800 to something else (suggest trying 115200 first), do you get a different result?

Is it possible that uploading a specific sketch may brick the device? I cannot imagine.

It's very unlikely, especially as the chip starts responding to serial commands OK and doesn't print anythign else when it goes "bad". To 100% rule it out, remove power, then connect the D0 pin and the GND pin on the module, then plug it back in and try the upload again.

updated windows USB driver for SIL2104, same result

Are you certain your WeMos D1 Mini boards all have the CP2104 and not the CH340 serial or another serial chip? I think the genuine D1 Mini design uses CH340. If it's a different chip, it could still be a driver issue.

[hunmik]

Hi projectgus, Thank you for your comments. Finally yesterday night I found the problem. In my sketch by mistake I set GPIO 6 and GPIO 7 to input/output. However these lines are reserved for (not checked but suspect) communication with the flash memory. So first upload was successful. Then code started, and blocked communication with flash. Therefore code did not run. Any more attempts to upload failed, as I pulled the reset and GPIO 0 to enter into flash mode AFTER the power supply was attached, and the GPIO lines were already compromised. Solution was, to remove supply from the chip, pull GPIO0 and then restore supply. Then chip immediately enters into flash mode, the faulty code does not run, GPIO lines are free, and upload is successful.
So lesson is learned, issue can be closed...

[projectgus]

Hi @hunmik,

That's interesting. Was something actually wired to GPIO 6 & 7? I would have expected the reset sequence to clear anything which was only done in software to configure these pins. But if some external connection is made here then this might make the difference, especially if the GPIO state changed and activated something.

In any case I'm glad it's working now.