A fatal error occurred: Failed to connect to ESP32 - Voltlog #357

→Support the channel via Patreon, Paypal or Bitcoin

→Support the channel by clicking these links (CommissionsEarned)

→Blog Post

#ESP32 #FatalError

[tornadokat]

Awesome! You have brought and end to my upload, timeout, *swearing*, upload, timeout, *swearing*, upload, success routine!

[RickSaffery]

This joy compelled me to search for a solution.

A fatal error occurred: Timed out waiting for packet content
Upload error: Failed uploading: uploading error: exit status 2

Your clip is very well done and your content is compelling. So much so, that I feel confident your discovery and solution will help me.

[DougSisco]

Thank you, thank you!! I have experienced this only recently with a new board and your fix worked perfectly! Who would have guessed that there is a race condition between the reset and enable lines??

[userou-igze]

thanks, the oscilloscope picture is really helpful!! As far as I see, this is clearly a design flaw in the chip design in the first place :-(

I totally sympathize with how time consuming it can be to figure out a semi-randomly occurring problem, and usually, until we humans figure it out, it takes ages (even though the solution may only take 2s). It's so frustrating! So kudos to you there for debugging, figuring out and sharing!

[domingomolinero]

Thank you, a simple solution for a annoying problem, explained with technical measurements, not just "the aunt of my niece's boyfriends grandmother added a cap and it worked"

[DavidGranz]

I recently ran into this problem... I've tracked it down to an issue with the way esptool.py hits the DTR and RTS pins to trigger the reset. Turns out the python serial library doesn't have a way to set both those pins at exactly the same time, thus producing the glitch you see. The solution is to change the esptool code to change those pins at the same time. I have some hacked code that works, but haven't had the time to publish it anywhere yet.

[Roobotics]

2 Thoughts on this:
1. I'm sort of thinking from that initial scope capture shown, that the real issue is there is any real capacitance on the EN line. That RC constant is causing the EN to not have a clean edge or easily deterministic start point, a proper reset supervisor wouldn't have an output like that (but RC circuits are cheaper) primarily reading the datasheet I see that:

"During the chip’s system reset release (power-on-reset, RTC watchdog reset and brownout reset), the latches of
the strapping pins sample the voltage level as strapping bits of ”0” or ”1”, and hold these bits until the chip is
powered down or shut down."

So if that EN signal went high faster (it's RC constant were removed and given a more square pulse) before that glitch occurred, then it would have already been stored as a strapped value. the pins are required to stay in the correct state for 1mS after EN "CHIP_PU" goes high to be considered properly latched.

2. The datasheet states GPIO0 has a weak pull-up resistor (WPU) and that the default drive strength of that is ~75uA, another thing worth trying, is installing a pull-down resistor on GPIO. Using a value of 5k should make it ~0.4v during that WPU event. Which puts it well under the required Voltage-Low threshold of ~0.8v @ 3.3v.

[gerritmarskamp]

Hello, we experienced almost the same about a year ago. We used an Olimex development board, the Esp32 devkit lipo. Also sometimes this error would show up. After studying the esp32-wroom data sheet, (page 20 of that sheet) provided by Expressif, we discovered that there should be a 10 k resistor connected from 3v3 to pin 3 EN and a capacitor of approximately 1 uF to ground. We designed our own board in the end with 10 k and 100nF and this worked fine every time

[brucewoods]

I think you just solved my problem with another sketch. It fails on one laptop. (An old HP, my grandsons), but not on my old Toshiba nor the really old tower.

[viniciusfriasaleite]

I designed an ESP32 board and now I'm troubleshooting it. I hope that will solve! Thank you!

[pulporock]

The amount of times I have pressed that En button during flash is beyond frustrating.
Usually just use a different computer.
I'm finding windows o/s way worse than Ubuntu.

[jensgoerke]

Back in the 90s I used a chain of inverters to delay an impulse - a capacitor within that chain would have been an improvement, but the system was slow enough to work anyway.

[dany_]

happend to me, it was a pain to figure it out since is the first esp32 board i used, mine worked if i pushed the "boot" button while uploading the code

[TheDefpom]

On the ESP32 Devkit v1.0 I install a 2.2uF electrolytic on the EN pin to make it easy to program it, no need to press buttons.

[garthberry]

I had a problem with exactly the same programmer symptoms on a custom board. It turned out that the bypass capacitor I had put on the EN (Reset) pin was too big, I swapped the 1uF capacitor out for a 100nF capacitor and I haven't seen the issue on any boards since.

[AndrewJones-tjet]

Yes I had that problem with some TTGO ESP32/LoRa boards. They have on board CP2104 USB to UART IC and adding 2uF across the RST/EN to ground got it working reliably. They seem to only have 100nF to ground with a 10k pull-up to 3V3. I've also used similar Heltec boards which work fine.

[robbieaussievic]

Excellent detective work Mycroft, ( Sherlock's smarter brother )
Intermittent failures are the most difficult to solve across multiple fields.
Substitution is my favourite diagnosis tool.

[chrisrowse]

Thanks fro taking the time to research and explain this. Quite obvious once you see the error.

[KiemPlant]

I figured out that for me it only was able to flash if I removed it from the headers I put it in (luckily I didn't solder it directly to the board). As soon as I put it back in my circuit, it fails. Maybe it has something to do with using the same pin that has the led connected to it as a data output pin.

Edit: Yeah that's actually it... "D2: must be LOW during boot and also connected to the on-board LED"

[AttilaAsztalos]

An USB log (using Snoopy Pro or similar) would be interesting to see, when the "glitch" does happen. It might just be bad programming on the toolset side which sets the EN pin before resetting the IO and depending on the USB packet timing the IO reset might only arrive a packet later; this would be visible in a trace.