Often failling upload to ESP8266

[ibaranov-cp]

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]

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]

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]

Resistor where? Am I missing something?

On 7 December 2015 at 18:50, Ilia Baranov [email protected] 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]

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 [email protected] 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]

I am having some problems with ESP-12E's too. It's this type

and I am using the CH340G USB to TTL converter which gives 3,3V output. It does not have DTR nor CTS.

With ESP-07 modules (see underneath) I didn't have any problems.

My procedure is manual with the schematic underneath; I pull GPIO0 down and keep it down and issue a reset by pulling !RESET down.

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 :

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

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

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]

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]

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]

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]

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]

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]

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 [email protected] 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" [email protected] 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 [email protected]
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]

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 [email protected] 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]

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 [email protected]
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 [email protected]
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]

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

[h4rm0n1c]

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]

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 [email protected]
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]

Recheck above, I edited the post.

[marcelops]

@f3z0 Do you have the link to the Apple FTDI driver that you used?

[marcelops]

Inexplicably, I started using 230400 baud for the upload, and it has been working great without freezing. My ESP is flashed to operate at 38400 baud, but I have been uploading the sketches at 230400 without any issues, on Mac OS X 10.12.3, Arduino IDE 1.8.1.

[f3z0]

Sound like auto-baud.

…

On Thu, Mar 9, 2017 at 4:43 AM, Marcelo Pereira da Silva < ***@***.***> wrote: Inexplicably, I started using 230400 baud for the upload, and it has been working great without freezing. My ESP is flashed to operate at 38400 baud, but I have been uploading the sketches at 230400 without any issues, on Mac OS X 10.12.3, Arduino IDE 1.8.1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1145 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA9xjK3rrT2Tq-f6NILutOcR1ZjYWeQks5rj_PmgaJpZM4GvG17> .

[tablatronix]

sketch baud has nothing to do with upload baud, not sure what you meant by "flashed to operate.."

also fake ftdi have speed issues, an ftdi in general do not work well at high bauds, also any noise is more relevant at higher speeds, when in doubt always program at 115200.

I can program 921600 100% of the time on cp210x, ftdi not so much , also if you are using autoreset, it can be iffy at high speeds depending on transistors etc, and esptool.exe also has some bugs at high speeds causing wrong direction errors and other wierdness sometimes.

[marcelops]

@tablatronix There are two scenarios where I refer to baud rate when using my ESP8266:

1. Its "normal operating" baud rate is 38400. I flashed the firmware in it, and configure the module ESP to use that speed when in normal mode.

2. The speed at which you upload sketches to the ESP module. This speed is just the "upload speed", and has nothing to do with the normal operating speed. I have successfully "uploaded" sketches using 115200, 230400 baud.

Regardless of the speed used to "upload" the sketch, my module will always "operate" at 38400, because that is the setting I set when I flashed the module.

I hope it is clear now.

[aqualaguna]

These are reaaaaally annoying. I got the same problem and guess what?
the connection between esp12 in pin tx is not connected(or loose) to the circuit board. got some lead and solder and its solved. damn it, waste 5 hours for this problem

[devyte]

Closing per #3655 .