Unable to flash firmware ("Failed to connect") on Wemos D1 with D0/RST soldiered #277
Full esptool.py command line as run:
esptool.py --port /dev/cu.wchusbserial1450 --baud 115200 write_flash --flash_size=detect 0 ~/Downloads/esp8266-20171101-v1.9.3.bin
Full output from esptool.py (please copy and paste all lines of output)
What is the expected behaviour?
Flashing of firmware
Do you have any other information from investigating this?
I have multiple Wemos D1's which I've successfully flashed. However one particular unit did not. Eventually I reproduced (with a second unit) the "Failed to connect" error during flash. Note: I was able to erase firmware, just not write firmware. The Wemos D1 have a RST/D0 jumper you can solder which I had done on the first problem unit. Manually doing doing with breadboard/jumper wire on the second unit caused the same issue. As soon as I yanked the wire, flash works again.
While I have the work around, it's sub optimal. Especially since some units have been solder bridged.
Is there any other information you can think of which will help us reproduce this problem?
I saw the mention of trace flash_id, so I ran that as well. Below is a partial output. Truncated because it just spewed the same thing for pages.
The text was updated successfully, but these errors were encountered:
Hi @ShakataGaNai ,
Sorry for the very slow reply. I've not heard of this WeMos hardware feature. Do you have any more information about it?
The schematic here https://wiki.wemos.cc/products:d1:d1_mini only shows one solder jumper which is RST<->GPIO16 (which is required for deep sleep to work).
If the jumper does bridge RST to GPIO0, this will prevent the ESP8266 from ever correctly entering the bootloader mode for use with esptool.py. This is because to do so RST needs to transition LOW->HIGH while GPIO0 is kept held low. You can read more about this here: https://github.com/espressif/esptool/wiki/ESP8266-Boot-Mode-Selection
Ah, my mistake I forgot that WeMos use their own numbering scheme so their "D0" is ESP8266 GPIO16. Sorry.
Looking more closely at the trace data you provided, it looks like the device is going into bootloader mode correctly but the first byte of the response is being corrupted.
I'll try to get hold of a WeMos D1 Mini to attempt to reproduce this myself.
It's a long shot, but I appreciate it! The answer for anyone else running across this issue, especially in the near term, is to simply make the Deep Sleep connection something that can be disabled. Either by switch, jumper or using headers and pulling the D1 during programming.