Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to flash firmware ("Failed to connect") on Wemos D1 with D0/RST soldiered #277

Closed
ShakataGaNai opened this issue Feb 22, 2018 · 5 comments

Comments

@ShakataGaNai
Copy link

ShakataGaNai commented Feb 22, 2018

  • Operating system: OSX High Sierra
  • Python version: 2.7.10
  • ESP hardware in use: Wemos D1 Mini 3.0.0

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)

esptool.py v2.2.1
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header

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.

esptool.py --trace --port /dev/cu.wchusbserial1450 flash_id esptool.py v2.2.1 Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data='\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' TRACE +0.000 Write 46 bytes: '\xc0\x00\x08$\x00\x00\x00\x00\x00\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU\xc0' TRACE +0.006 Read 1 bytes: '$' TRACE +0.000 Read invalid data: '$' TRACE +0.000 Remaining data in serial buffer: ' UUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' .TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 data='\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' TRACE +0.000 Write 46 bytes: '\xc0\x00\x08$\x00\x00\x00\x00\x00\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU\xc0' TRACE +0.005 Read 1 bytes: '\x08' TRACE +0.000 Read invalid data: '\x08' TRACE +0.000 Remaining data in serial buffer: '\x1b[K$ UUUUUUUUUUUUUUUUUUUUUUUUUU' .TRACE +0.051 command op=0x08 data len=36 wait_response=1 timeout=0.100 data='\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' TRACE +0.000 Write 46 bytes: '\xc0\x00\x08$\x00\x00\x00\x00\x00\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU\xc0' TRACE +0.005 Read 1 bytes: '\x08' TRACE +0.000 Read invalid data: '\x08' TRACE +0.000 Remaining data in serial buffer: '\x1b[K$ UUUUUUUUUUUUUUUUUUUUUUUUUU' .TRACE +0.051 command op=0x08 data len=36 wait_response=1 timeout=0.100 data='\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' TRACE +0.000 Write 46 bytes: '\xc0\x00\x08$\x00\x00\x00\x00\x00\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU\xc0' TRACE +0.005 Read 1 bytes: '\x08' TRACE +0.000 Read invalid data: '\x08' TRACE +0.000 Remaining data in serial buffer: '\x1b[K$ UUUUUUUUUUUUUUUUUUUUUUUUUU' .TRACE +0.050 command op=0x08 data len=36 wait_response=1 timeout=0.100 data='\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU' TRACE +0.000 Write 46 bytes: '\xc0\x00\x08$\x00\x00\x00\x00\x00\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU\xc0' TRACE +0.005 Read 1 bytes: '\x08' TRACE +0.000 Read invalid data: '\x08' TRACE +0.000 Remaining data in serial buffer: '\x1b[K$ UUUUUUUUUUUUUUUUUUUUUUUUUU'

@projectgus
Copy link
Contributor

projectgus commented Mar 13, 2018

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

@projectgus
Copy link
Contributor

projectgus commented Mar 13, 2018

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.

@ShakataGaNai
Copy link
Author

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.

@030jmk
Copy link

030jmk commented Apr 2, 2018

I ran into the same issue but fixed it with a slower baud rate. 115200 led to the same fatal error but 57600 ran just fine.

@projectgus
Copy link
Contributor

Closing as this seems to be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants