Often failling upload to ESP8266 #1145

Open
ibaranov-cp opened this Issue Dec 4, 2015 · 36 comments

Projects

None yet
@ibaranov-cp
ibaranov-cp commented Dec 4, 2015 edited

Hello all,

This is more a request for advice.

I have the ESP-12E module attached to a CP2012 USB-UART chip, with a independant 3.3V power supply, decoupling caps, etc, all mounted on a USB stick form factor PCB.

My process is:

  1. Plug in module while holding down GPIO0 to ground
    1b) Wait ~2 seconds
  2. Hit the "Upload Button" on Arduino 1.6.5
  3. Wait for the led on ESP12E to start blinking, if it doesn't after ~5 seconds, start again.

With this method, somewhere around 1 out of 6 times the program actually gets uploaded, which is fairly frustrating.

Anyone have advice on making this better?

Source files for Design can be made available if needed.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@kapyaar
kapyaar commented Dec 4, 2015

What happens the remaining 5 out of 6 times? Any error messages?

@ibaranov-cp

The serial data light never blinks.
(Usually it blinks once, I am assuming a reply, pauses for ~1 second, then flashes quickly as data is transferred and verified.)

Here is the IDE error message:
trying to connect
flush start
setting serial port timeouts to 1 ms
setting serial port timeouts to 1000 ms
flush complete
espcomm_send_command: sending command header
espcomm_send_command: sending command payload
read 0, requested 1
warning: espcomm_sync failed
error: espcomm_open failed

@igrr
Member
igrr commented Dec 5, 2015

The way I used to troubleshoot such issues was to take another USB-serial adapter, attach its RX line to the TX line of ESP8266, and monitor the bootloader output while doing the reset.

You could start by verifying that the chip actually enters bootloader mode each time.

If this is the case, then the issue is likely with esptool-ck, which (for some reason) fails to sync with bootloader on the first attempt. Normally esptool-ck will reset the ESP and attempt to sync again, but as i understand in your case CP2102 is not wired to control ESP's reset line.

@joescharf

Also seeing this issue since upgrading from 1.6.5-947 to 2.0.0 core. Same code uploads fine with 1.6.5, but when install 2.0.0, get:

warning: espcomm_sync failed
error: espcomm_open failed

Arduino ide 1.6.5,
Sparkfun Esp8266 Thing Dev Board
Uploading over FTDI on Mac

@tiller123

I also have upload problems since a few days ago. I use two different computers (one mac book aluminum, another mac mini). The problem is on the aluminum but not on the mini. To narrow down the issue, I use the same Arduino IDE (1..6.6 stable, now offered for download), made sure the listed libraries are the same on both computers, and the boards registered in the IDE are the same. I use the same ESP-12E, with the same USB-TTL thing, which I plug into the USB of one computer or the other, and a separate same 3.3V power supply. On the mac mini, everything goes fine. On the aluminum, compilation finished with no errors. Upload starts. But then one of two things happen: 1) the process freezes (no more progress dots added on the screen, and the USB-TTL thing stops blinking), or 2) I get an error message, like, upload failed.

Using the Python based esptool.py outside the Arduino IDE, I can upload the sketch. But it does not run right most of the time. Also, my sketch reads from and writes to EEPROM. The same code worked fine before, but now power cycling replaces what's written with gibberish. This started at the same time as the upload problems. Is this a clue?

For now, I will just use the "good" computer. It would be nice to have both working though.

What else can I try to narrow down the problem?

Thanks in advance!

@ibaranov-cp

Is there a suggested wiring where the reset line is controllable?
On the RTS line?

@tiller123

Pulling RST to ground resets the ESP. Is that what you ask?

@ibaranov-cp

Not exactly.

  • GPIO0 to GND on power on sets ESP8266 into firmware upload mode
  • RST to GND resets ESP8266

However, the RTS hardware serial line on RS232 drops low only after data transmission is done...

@igrr Ahh, so the esptool actually expects to be able to trigger a chip reset? Interesting... And this is usually done with the RTS line?

@tiller123

I think I saw this somewhere, but this function of the esptool is replaced by power cycling with the GPIO0 grounded. Is that right?

@ibaranov-cp

Sure, but like the post is about, having to power cycle ~ 5-6 times each programming cycles gets really frustrating.

@ibaranov-cp

Just added in the Resistor, this seems to fix the issue for me, as long as resistor is <= 5.6K

@duncan-a
duncan-a commented Dec 8, 2015

Resistor where? Am I missing something?

On 7 December 2015 at 18:50, Ilia Baranov notifications@github.com wrote:

Just added in the Resistor, this seems to fix the issue for me, as long as
resistor is <= 5.6K


Reply to this email directly or view it on GitHub
#1145 (comment).

@ibaranov-cp

So what you can do is:

  • Add a pull up (between 3.3V and the pin) resistor to the RST pin on the ESP8266
  • Connect that RST pin to the RTS pin on a usb-serial chip

The RTS line on the usb-serial chip goes active low, and resets the micro.
If programming fails, the esptool seems to try and pull RTS line low again.

So far, this has corrected my problem, with a successful write 9~10/10 times.

@duncan-a
duncan-a commented Dec 8, 2015

I have that pullup, one on GPIO0 and another on CH_PD - they're standard
practice...

I thought you were talking about something new.

On 8 December 2015 at 15:11, Ilia Baranov notifications@github.com wrote:

So what you can do is:

  • Add a pull up (between 3.3V and the pin) resistor to the RST pin on
    the ESP8266
  • Connect that RST pin to the RTS pin on a usb-serial chip

The RTS line on the usb-serial chip goes active low, and resets the micro.
If programming fails, the esptool seems to try and pull RTS line low again.

So far, this has corrected my problem, with a successful write 9~10/10
times.


Reply to this email directly or view it on GitHub
#1145 (comment).

@tiller123

I followed the schematic shown, e.g., at http://www.oddwires.com/blog/, in which RTS and DTR of the FTDI are connected to ESP's GPIO0 and Reset, and saw an improvement in uploads

The code of the esptool.py has references to RTS and DTR, related to failing an upload.

@dave-prosee
Contributor

I am having some problems with ESP-12E's too. It's this type
s-l140
and I am using the CH340G USB to TTL converter which gives 3,3V output. It does not have DTR nor CTS.
ch340g usb to ttl stick
With ESP-07 modules (see underneath) I didn't have any problems.
esp-07
My procedure is manual with the schematic underneath; I pull GPIO0 down and keep it down and issue a reset by pulling !RESET down.
esp circuit
The only difference is that I changed the ESP-7 module on the same PCB for an ESP-12E and I just cannot get it to flash.

So far I have seen the debug line issuing the right status :
debugline
when not in flash mode the module issue "main.c" (as I understood, an indication for no user program).
When uploading the esptool is commenting communication failures
esptool warning
I had a few times where flash seem to start, i.e. some dots in IDE log and unrecognised chars in debug output (because of different baudrate like I am used to), but never ever was I successful.

Normally I use the Arduino IDE 1.6.5 with esp8266 version 1.6.5-1160-gef26c5f installed.
I tried using uploading with the esp8266_flasher tools from Espressif but that gave "Invalid head of packet". And with "flash_download_tool_v1.2_15_512" I get
flash_download_tool_log

I am now fooling with baud rates as well as reset method (ck), clock frequency, flash parameters, but to no avail.
Today I came across some posts using RTS/DTR to reset the ESP automatically which made me think that the ESP-12E bootloader might be time critical (but why?). Also some posts on bad flash memory but I am not even started flashing so that is not the problem.

So, here are my questions:

  • are there any directions from the pro's?
  • is ESP-12E time critical (I already ordered an USB to TTL converter with DTR/RTS exposed)?
  • what is different between ESP-7 bootloader and ESP-12E bootloader?
  • might there be a bad batch of ESP-12E in circulation?

Any help is welcome.

@tablatronix

possible related?
#3

@dave-prosee
Contributor

Thanks for the hint @tablatronix . I followed the advice #3 to use esptool.py (got it working from the command line and had some issues left under the Arduino IDE).
Reading mac address and flash Id was no problem, hence the bootloader and hardware seems ok to me. But flashing still doesn't work. I'm gonna check again tomorrow.

@tablatronix

Yeah this is driving me nuts. I now have 2 ftdi adapters running to debug boot codes. And have installed git versions. And tried py tools, to no avail.
I am now unable to upload unless I remove power entirely to reset, but at least its working more reliably.

@dave-prosee
Contributor

I might be on to something now. Must investigate further. On the esptool.py page I saw the protocol and tapped into it. The esp was responding (using debug output which is the same as TX of the esp on the flash comms) with e.g. C0 01 08 02 00 07 07 12 20 01 05 C0 while esptool reported
warning: espcomm_send_command: wrong direction/command: 0x01 0x08, expected 0x01 0x02
warning: espcomm_send_command(FLASH_DOWNLOAD_BEGIN) failed
So how come the ESP is responding to a different command?
Also attaching another RX monitor to the flash TX would halt the process.

I took my scope to find that the TX line on this CH340G USB to TTL converter was merely pulling the line down by 1 Volt. I have not had this communication problems with other ESP's but all the ESP-12E's I have are behaving like that.

I'll dive in the circuit a bit further and keep y'all posted.

@dave-prosee
Contributor

Definitely solved for me. I changed to a PL230 adapter and working. Signal looked much butter, full3v3 and down to zero as it should.
Since this phenomena occured when I started using the ESP-12E's I think the ESP-12E's just need a little more umpf on the RX line. Something the CH340G USB 2 TTL adapter I had could not deliver. By the way: I only saw two diodes, presumably zeners and no regulator.

@tablatronix

Mine are all ftdi and not cheap but ill make sure they are genuine.

@dave-prosee
Contributor

Mine were all cheap. Best way is,if you have an o-scope, to look at the signal shape.

@ikbelkirasan

For some reason I'm facing the same issue. To get around it, I export the binary file and upload it using the NodeMCU Firmware Programmer which seems uploading correctly.

@tablatronix

I gained some stability by switching my progammer to pyesptool. There seems to be some bugs still in esptool.

@f3z0
f3z0 commented Jan 25, 2016

I got around the issue by placing the chip in flash boot mode, unplug the usb at the ftdi side (not at the macbook side or it goes into a state that I have to reboot to regain use of the ftdi chip on that usb port), and then plug the usb back in. The problem seems to be, at least for me, when the esp-12e resets it causes the ftdi to no longer be able to talk, unattaching/reattaching then fixes that. Took me a week to figure out and even ordered an extra sparkfun ftdi board thinking the problem was with my cable...

@mtnbrit
mtnbrit commented Jan 25, 2016

I’ve noticed that about the FTDI driver in os x recently started needing a reboot after re-plugging, most annoying….I wonder where would one report that to get it fixed?

On Jan 24, 2016, at 4:11 PM, Gregory Ray notifications@github.com wrote:

I got around the issue by placing the chip in flash boot mode, unplug the usb at the ftdi side (not at the macbook side or it goes into a state that I have to reboot to regain use of the ftdi chip on that usb port), and then plug the usb back in. The problem seems to be, at least for me, when the esp-12e resets it causes the ftdi to no longer be able to talk, unattaching/reattaching then fixes that. Took me a week to figure out and even ordered an extra sparkfun ftdi board thinking the problem was with my cable...


Reply to this email directly or view it on GitHub #1145 (comment).

@ibaranov-cp

Perhaps trigger the reset on the FTDI?

Or switch to the CP2102 like me :)
On Jan 24, 2016 4:16 PM, "mtnbrit" notifications@github.com wrote:

I’ve noticed that about the FTDI driver in os x recently started needing a
reboot after re-plugging, most annoying….I wonder where would one report
that to get it fixed?

On Jan 24, 2016, at 4:11 PM, Gregory Ray notifications@github.com
wrote:

I got around the issue by placing the chip in flash boot mode, unplug
the usb at the ftdi side (not at the macbook side or it goes into a state
that I have to reboot to regain use of the ftdi chip on that usb port), and
then plug the usb back in. The problem seems to be, at least for me, when
the esp-12e resets it causes the ftdi to no longer be able to talk,
unattaching/reattaching then fixes that. Took me a week to figure out and
even ordered an extra sparkfun ftdi board thinking the problem was with my
cable...


Reply to this email directly or view it on GitHub <
https://github.com/esp8266/Arduino/issues/1145#issuecomment-174355352>.


Reply to this email directly or view it on GitHub
#1145 (comment).

@tablatronix

I have not noticed this on my mac, but i have not restarted in some time, when did you notice this starting? Have you tried power cycling or removing the rx tx connections instead maybe they are holding stuff high or messing the adapter up.

@tablatronix

Could this new dropout issue be related to this
http://m.slashdot.org/story/306597

@f3z0
f3z0 commented Jan 31, 2016

I don't think so, my FTDI chip should be genuine as I purchased it from
SparkFun.

On Sun, Jan 31, 2016 at 10:52 AM, Shawn A notifications@github.com wrote:

Could this new dropout issue be related to this
http://m.slashdot.org/story/306597


Reply to this email directly or view it on GitHub
#1145 (comment).

@f3z0
f3z0 commented Feb 10, 2016

FTDI has confirmed this issue with OSX to me in a private correspondence,
they recommended switching to the Apple version of the FTDI driver as a
work around.

On Sun, Jan 31, 2016 at 2:44 PM, Gregory Ray gregory.james.ray@gmail.com
wrote:

I don't think so, my FTDI chip should be genuine as I purchased it from
SparkFun.

On Sun, Jan 31, 2016 at 10:52 AM, Shawn A notifications@github.com
wrote:

Could this new dropout issue be related to this
http://m.slashdot.org/story/306597


Reply to this email directly or view it on GitHub
#1145 (comment).

@mtnbrit
mtnbrit commented Feb 11, 2016

Thanks for this tip! I removed the FTDI extension and restarted, now the driver unloads properly when the usb is disconnected. Great!

@h4rm0n1c
Contributor
h4rm0n1c commented Mar 9, 2016

I've had the opposite experience, I disabled the Apple FTDI driver and installed v2.3 from FTDI's site.

Open terminal and run the following commands:

cd /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns
sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled
sudo touch /System/Library/Extensions

Then install FTDI's drivers and reboot.

Before I did this I always got:
warning: espcomm_sync failed
error: espcomm_open failed

I'm using the PlatformIO GUI (latest version) on a 2010 Macbook Pro with 10.9.5

@f3z0
f3z0 commented Mar 9, 2016

Harrison - what OSX version and mac model? Maybe we can narrow this down to
specific setup configuration requiring one way or the other.

On Wed, Mar 9, 2016 at 8:34 AM, Harrison Mclean notifications@github.com
wrote:

I've had the opposite experience, I disabled the Apple FTDI driver and
installed v2.3 from FTDI's site.

Open terminal and run the following commands:

cd /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns
sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled
sudo touch /System/Library/Extensions

Then install FTDI's drivers and reboot.


Reply to this email directly or view it on GitHub
#1145 (comment).

@h4rm0n1c
Contributor

Recheck above, I edited the post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment