on Issue 1: Arduino is configured with both cores already when built, so nothing else is required.
on Issue 2: Could you try to lower the flashing speed? You seem to have selected 921600 and I have seen that to fail on my mac too. Try with 115200 as a safe net and report how that goes. To note, I have had success with many baud rates with FTDI chips, but not the same with others. Silabs seems to be better than WCH, but not quite as good as FTDI.

me-no-dev on 26 Apr 2017

👍14 ❤8

Hello,
just tried with lowest speed (115200) without luck.

Sketch uses 104,282 bytes (9%) of program storage space. Maximum is 1,044,464 bytes.
Global variables use 9,492 bytes (3%) of dynamic memory, leaving 285,420 bytes for local variables. Maximum is 294,912 bytes.
/Users/lmc/Dropbox/arduino/hardware/espressif/esp32/tools/esptool --chip esp32 --port /dev/cu.SLAB_USBtoUART --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_freq 80m --flash_mode dio --flash_size 4MB 0x1000 /Users/lmc/Dropbox/arduino/hardware/espressif/esp32/tools/sdk/bin/bootloader.bin 0x8000 /var/folders/zx/4rs36y2j0315wny99n1j7fj80000gn/T/arduino_build_145081/Blink.ino.partitions.bin 0xe000 /Users/lmc/Dropbox/arduino/hardware/espressif/esp32/tools/partitions/boot_app0.bin 0x10000 /var/folders/zx/4rs36y2j0315wny99n1j7fj80000gn/T/arduino_build_145081/Blink.ino.bin
esptool.py v2.0-beta2
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____

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

Moreover, just before flashing, I verified I got my ESP32 put into Download mode with the Arduino terminal, and I got this message:



rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))

waiting for download

I then tried flashing, without success, and after, I went back to the terminal and saw some characters arrived after the "waiting for download" string:



� UU�� UU�� UU�� UU�� UU�� UU�� UU�� UU�� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �

Could it be possible that Arduino IDE does not actually close the serial port well, so that esptool is not able to see the other end?

croisez on 27 Apr 2017

Another info: inside Arduino terminal, I am able to send commands and receive info from the minimalist BASIC terminal which is activated if you pull up GPIO12 while asserting RST.
This means, at least, that my communication through the SLAB chip is bidirectional and arrive well to the ESP32.

croisez on 27 Apr 2017

FYI arduino and idf both use the same upload script. Arduino has it in both python and binary form (to coop with missing python, modules and so on), so your issues are really, really strange. I can not really come up with why it happens...

me-no-dev on 27 Apr 2017

I own another ESP32 module, the WROOM32 module alone, which I have put on a experimentation PCB. This one, I have been able to program it through the same Arduino IDE environment.
So, I doubt that my problem is related to a bug in ESP32-Arduino toolchain.
I am a bit lost, I can't determine the problem, and I am looking for some ideas...

croisez on 27 Apr 2017

When hooking another Serial adapter (FTDI) on TX/RX pins of the WEMS module, I can program it using ESP32-Arduino toolchain:

Sketch uses 104,282 bytes (9%) of program storage space. Maximum is 1,044,464 bytes.
Global variables use 9,492 bytes (3%) of dynamic memory, leaving 285,420 bytes for local variables. Maximum is 294,912 bytes.
/Users/lmc/Dropbox/arduino/hardware/espressif/esp32/tools/esptool --chip esp32 --port /dev/cu.usbserial-FTXQKKR2 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_freq 80m --flash_mode dio --flash_size 4MB 0x1000 /Users/lmc/Dropbox/arduino/hardware/espressif/esp32/tools/sdk/bin/bootloader.bin 0x8000 /var/folders/zx/4rs36y2j0315wny99n1j7fj80000gn/T/arduino_build_658130/Blink.ino.partitions.bin 0xe000 /Users/lmc/Dropbox/arduino/hardware/espressif/esp32/tools/partitions/boot_app0.bin 0x10000 /var/folders/zx/4rs36y2j0315wny99n1j7fj80000gn/T/arduino_build_658130/Blink.ino.bin
esptool.py v2.0-beta2
Connecting.......
Uploading stub...
Running stub...
Stub running...
Attaching SPI flash...
Configuring flash size...
Flash params set to 0x022f
Compressed 12352 bytes to 7462...

Writing at 0x00001000... (100 %)
Wrote 12352 bytes (7462 compressed) at 0x00001000 in 0.7 seconds (effective 147.1 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 105...

Writing at 0x00008000... (100 %)
Wrote 3072 bytes (105 compressed) at 0x00008000 in 0.0 seconds (effective 1534.2 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...

Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 4108.8 kbit/s)...
Hash of data verified.
Compressed 188768 bytes to 57684...

Writing at 0x00010000... (25 %)
Writing at 0x00014000... (50 %)
Writing at 0x00018000... (75 %)
Writing at 0x0001c000... (100 %)
Wrote 188768 bytes (57684 compressed) at 0x00010000 in 5.1 seconds (effective 294.1 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...

But then upon RST, the blink sketch get stuck during the boot process:

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0008,len:8
load:0x3fff0010,len:2036
load:0x40078000,len:9988
load:0x40080000,len:252
entry 0x40080034

Is there some binary to flash into the ESP32 module itself to make it working with the Arduino toolchain?

croisez on 27 Apr 2017

👍1

Hi,
concerning the sketch upload, I tried the following:
pushing on BOOT button during flashing process (but without acting on RST button at all) allows Arduino to flash the WEMS board successfully.
There is still a problem with the sketch which does not start. I will close this issue, and also, my apologize for putting two issues into one ticket. This is perturbating.
So let us close this one.

croisez on 2 May 2017

👍22 🎉3

I am facing the same issue with the WEMOS LOLIN 32 v1.0.0. It does not has a BOOT button though, only the RESET button. What should I do?
_(https://forum.wemos.cc/topic/334/lolin32-v1-0-0-is-release)_

architmuchhal12 on 23 May 2017

Please try installing new CP2102 drivers http://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

With the old drivers I had many problems previously: I could not upload without pressing boot, interference with other USB devices, etc. Curiously, those old drivers worked well with all my ESP8266 boards.

Regards.

lrmoreno007 on 23 May 2017

👍5

Hey, thanks for the suggestion.
I updated the drivers and now this is what the error is -

`Sketch uses 108830 bytes (10%) of program storage space. Maximum is 1044464 bytes.
Global variables use 9616 bytes (3%) of dynamic memory, leaving 285296 bytes for local variables. Maximum is 294912 bytes.
esptool.py v2.0-beta3
Connecting....
Uploading stub...

A fatal error occurred: Response doesn't match request
A fatal error occurred: Response doesn't match request
`

Please help!

error2

architmuchhal12 on 23 May 2017

You should not have to press Boot button, but while you solve the problem you can put a button, as in this image:
lolon32_v1 0 0_2_16x9

And test at a lower speed like me-no-dev say in the second comment.

lrmoreno007 on 24 May 2017

👍8 😄1

I am getting the same issue as the topic of this issue. I tried everything mentioned above but no luck. Do anyone have any other suggestion?
One more thing I like to mention is, I read "OK!" on the serial monitor when GPIO0 is pulled low. I don't know if this is some kind of hardware status ping.

kp372 on 31 May 2017

I experienced a similar issue on a Geekcreit board and I managed to get it working by lowering the Arduino GUI's upload speed to 115200 (menu Tools -> Upload speed -> 115200, flash button does not need to be pressed). The flashing and serial output work fine but however I am still getting garbled bootloader messages on serial as if there are still some issues.

If this does not work try to bypass the FTDI chip, e.g. by connecting directly an USB to TTL cable (4 wires VCC, TX, RX, GND) to ESP-32 (VCC5, RX, TX, any GND, select Esp-32 Dev Module as board in arduino gui). In this way my board works also at full flashing speed and I did not receive anymore garbled messages from the bootloader, so I am quite sure that there is an issue with the ftdi chip on my board (near it there are some empty pads which I think should be populated with some capacitors).

fededim on 17 Jun 2017

Press and hold the boot button until you have progress bar in the bottom , this problem caused by the old CP2102 Driver

i had the same issue and i solved it by press the boot button "hard reset"

Genotronex on 1 Aug 2017

👍18 😄4

Have you tried turning the cpu speed down from 80 to 40Mhz when programming?

G6EJD on 12 Aug 2017

👍2

Hi

I got the same pb with this board: https://fr.aliexpress.com/item/ESP32-Development-Board-WiFi-Bluetooth-Ultra-Low-Power-Consumption-Dual-Cores-ESP-32-ESP-32S-Board/32802136026.html

and last VCP driver https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

trying to decrease cpu speed, upload speed without any success.

I still stuck, not being able to upload sketch :-(

Chris

ouaibsky on 22 Aug 2017

Try to monitor GPIO0 and GPIO2 while sketch is being uploaded. GPIO0 & GPIO2 both has to be pulled down which is a requirement on ESP32 to run it into boot mode unlike ESP8266.

kp372 on 23 Aug 2017

👍4

Hi
Sorry in advance my knowledge regarding electronic is low.

I measure between GPIO2 ans GPIO and o 3.3V in any cases (whatever I reset or push the boot button, or trying to upload a sketch

Error in arduino console is

esptool.py v2.1-beta1
Connecting........_
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Compressed 8192 bytes to 47...

A fatal error occurred: Timed out waiting for packet content
A fatal error occurred: Timed out waiting for packet content

Then into serial monitor I got (looping)

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
Falling back to built-in command interpreter.
OK

ouaibsky on 23 Aug 2017

You have to keep the boot button pressed whilst programming?

G6EJD on 23 Aug 2017

👍6

I test with pressing the BOOT button with same issue.
When pushing BOOT I can see that GPIO0 is LOW (.6v)

ouaibsky on 23 Aug 2017

runnig esptool on command line give me:

./esptool.py --port /dev/cu.SLAB_USBtoUART flash_id
esptool.py v2.1-beta1
Connecting........__
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Manufacturer: ff
Device: ffff
Detected flash size: Unknown
Hard resetting...

There is no Device/Manufacturer, could it be an issue ?

ouaibsky on 23 Aug 2017

I measure between GPIO2 ans GPIO and o 3.3V in any cases (whatever I reset or push the boot button, or trying to upload a sketch

Did you check GPIO2 while pressing BOOT button ?
Pull GPIO2 to ground right from the module. Make sure you are not shorting power supply to ground.

kp372 on 23 Aug 2017

GPIO2 remains LOW (0.0V) and GPIO0 move from 3.33V to ~0.5V

ouaibsky on 23 Aug 2017

GPIO12 sets the flash power ;) make sure it's low when booting/flashing

me-no-dev on 24 Aug 2017

👍1

@ouaibsky I have exactly this board, and works here without set or press anything....

Try just change your USB cable (I got some flash problems with a cheap cable)

copercini on 24 Aug 2017

👍1

I tried 2, they're good quality I think, never had issue before, can flash esp8266 without any pb.
Are you under Mac OS ?

ouaibsky on 24 Aug 2017

no, just tested it on Windows 10 and 7
and I don't have a Mac here for test =/

copercini on 24 Aug 2017

I'll try to get a PC with windows 10

ouaibsky on 24 Aug 2017

Any further information in this topic? Im still getting the same error

ghost on 13 Sep 2017

This is how I flash the ESP32 module.

Check USB port of the connection to the ESP32, mine is usually USB-12
Begin compilation / upload
Press and hold GPIO0 button - don't release
Press and hold GPIO2 button momentarily, the ESP32 responds with entering Flash Mode

Are you getting boot messages from the ESP32 before you start the Flash process?

Do you get messages from the ESp32 during the Flash initialisation?

Are you monitoring the Serial port during flashing?

Have you considered the ESP32 might be fake or faulty?

G6EJD on 13 Sep 2017

👍3

I have to say I'm as newbie as possible with microcontrollers as I'm pretty sure Ive got a totally different problem (I dont even understand most of your questions). I plugged in my Esp32 via USB, installed arduino-core, and drivers linked above. But looks like my PC never recognized my board. No popup or any entry in device manager. (nothing changes with boot and en button pressing)
I see two ways: 1, Im doing something (or everything :D) wrong.
2, My NodeMCU-ESP-32S is faulty

ghost on 13 Sep 2017

You probably need a driver ;)

me-no-dev on 13 Sep 2017

I installed the newest VCP driver, did you mean something else?

ghost on 13 Sep 2017

Sometimes Windows won't recognise a USB device, so when you plug in the ESP32, (the on-board UART) is not being recognised. So what sort of ESP32 do you have, can you post a link to the supplier / image of it please.

G6EJD on 13 Sep 2017

Nevermind, Its working now!
I reinstalled driver, changed the cable, unplugged every other usb device, plugged the board. Aaand it was working.
Anyway, here is the link for the board (its hungarian): https://www.hestore.hu/prod_10037961.html

ghost on 13 Sep 2017

Great new, yes that's a nice standard development board, nice and stable. Happy coding...

No need to press EN and REST on that board the serial port (UART) will do it for you.

G6EJD on 13 Sep 2017

Thank you, and for all the great advice as well.

ghost on 13 Sep 2017

I also have the AliExpress-ESP32 and the same ...._____....._____....._____....._____....._____-Problem when
I try to connect any serial device (i tried many different) on the RX0 (Pin GPIO03).
When I connect to RX2 (Pin GPIO16) my devices work.

mauricio34 on 17 Sep 2017

rx0 and tx0 are used by the on-board UART to communicate with the ESP32 by your IDE through the microUSB, so you cannot use them unless you plan to programme the device and then disconnect it and connect another device via the microUSB or use it standalone from the IDE.

The errors you are seeing are correct as there is a conflict, so you have to use Tx/Rx 2 or SoftwareSerial to define and use any two other pins.

G6EJD on 17 Sep 2017

Removing the ESP32 from the breadboard during programming really does make a difference. I'm using the Doit ESP32 Devkit V1 with the Arduino IDE set on board: ESP32 Dev Module with the Upload Speed baudrate at 115200. If fails with the "A fatal error occurred: Timed out waiting for packet header" when breadboarded, but succeeds when laying on the bench unconnected except for the usb cable. No button presses are required prior to upload.

w8an on 18 Sep 2017

👍7 🎉1

that probably means that one of the bootstrap pins is floating, so when you put it on the breadboard in induces enough to pull the pin in the wrong direction (like reading ADC on floating pin) which causes you not to be able to flash it.

me-no-dev on 18 Sep 2017

👍2

I am having this ........_____....._____....._____..... issue on a board which was uploading just fine half an hour ago. Don't know what happened. Besides, when I disconnect the board from USB or press reset on the board, sometimes my mac restarts... When I connect another similar board to the same cable and USB port, it works just fine...

vahegan on 3 Oct 2017

What board type do you have selected and what mode DIO or QIO the speed can also make a difference try at 40MHz

G6EJD on 4 Oct 2017

The board type selected is WEMOS LOLIN, of course I tried to downgrade to 115200 upload speed and 40MHz flash speed, but no lock. What do you mean by DIO/QIO mode? That same board was loading under these same settings, and just stopped doing so. But the board works and there is output on the serial monitor by the previous sketch (I2C scanner) that was loaded into it.

vahegan on 4 Oct 2017

It seems I have found the solution to this issue on some other board. Will post it here, maybe it will be useful to someone else.

When you click on "upload sketch" in arduino IDE, you see the sktech being recompiled , relinked and then uploaded (before the upload phase), hold the RESET button on the board, then push and hold the second button. When arduino IDE starts the upload stage (Connecting.......), release the RESET button and then in a short while release the second button.

After this procedure the board was successfully uploaded and resumed its normal functions, as before. You need to do this only once, to get the board out of the mode in which it was stuck, then it works as normal, without having to push any buttons during the upload.

vahegan on 4 Oct 2017

❤3

There's a bi-stable circuit on most development boards that does the same as pressing boot/enable for you, sounds like it got into the wrong state and going through your process rest it.

G6EJD on 4 Oct 2017

Hi all,

I had the same issue as described in the topic header.

I could fix it by pushing the IO0 button while uploading the code to the "esp32doit-devkit-v1"
my question : will i always need to use that button, or is there some sort of setting that i can tweak to make the board to be flashed without pushing that button?

I'm on Platformio (totaly newbee on that !)
Totally new to FreeRTOS too :-)

Grtz

YvedD on 8 Oct 2017

VIDEO THAT CLEARS, WITH HIM I STILL RESOLVE THIS PROBLEM

https://www.youtube.com/watch?v=J10J_7Ap6Oo

CONNECTING THE GPIO0 AND EN TO A 10K RESISTOR CONNECTING THE 3.3V POWER SUPPLY

1 - PUSH ON GIO0 - PUSH BUTTON - PLAYING EARTH FOR THE PINE AND SECURING
2 - PUSH ON RESET - PUSH BUTTON - PLAYING EARTH FOR THE PINE AND SECURING
3 - PUSH OFF RESET - PUSH BUTTON
4 - PUSH OFF GPIO0 - PUSH BUTTON
5 - COMPILING THE CODE IN THE ARDUINO IDE
6 - APOS COMPILE PUSH ON THE RESET BUTTON PLAYING EARTH FOR THE PINE

ENJOY !!!
ENGEBOT TECHNOLOGY

sirineo-technologies on 21 Oct 2017

I purchsed ESP8266 ESP-12E CH340G WIFI Network Development Board Module For NodeMcu Lua
I installed per Githut on OSX Sierra.

I am using Arduino IDE 1.8.5
I installed the latest serial drivers

I set up the Arduinoi serial monitor to the default 74880 and upon pressing the reset buttin (the one on the left) I get this:

ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8

2nd boot version : 1.6
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000

rf cal sector: 1017
rf[112] : 00
rf[113] : 00
rf[114] : 01

SDK ver: 2.0.0(5a875ba) compiled @ Aug 9 2016 15:12:27
phy ver: 1055, pp ver: 10.2

so clearly the board is able to talk to my mac.

I use conservative settings of 40mhz and 115200 baud
I can not get a successful download of LEDsfotwareFade code example into the boar/d.
If I do nothing and just upload the code I get this message:

_Sketch uses 137434 bytes (10%) of program storage space. Maximum is 1310720 bytes.
Global variables use 11012 bytes (3%) of dynamic memory, leaving 283900 bytes for local variables. Maximum is 294912 bytes.
esptool.py v2.1
Connecting....

A fatal error occurred: Timed out waiting for packet header
A fatal error occurred: Timed out waiting for packet header_

if I hold down the reset button for the duration of the download get this:

_Archiving built core (caching) in: /var/folders/vw/htc_f5617j3gf7wxn7c63c5r0000gn/T/arduino_cache_129527/core/core_espressif_esp32_esp32_FlashMode_qio,FlashFreq_40,FlashSize_4M,UploadSpeed_115200,DebugLevel_none_5fe93efa7d48502176951b18f35e91e7.a
Sketch uses 137434 bytes (10%) of program storage space. Maximum is 1310720 bytes.
Global variables use 11012 bytes (3%) of dynamic memory, leaving 283900 bytes for local variables. Maximum is 294912 bytes.
esptool.py v2.1
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____.....____An error occurred while uploading the sketch_
_

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

If i try to ge the chip id without IDE , this is what I get:

dorons-imac:tools doron$ esptool.py -p esptool.py -p /dev/cu.wchusbserial1410 --baud 74880 flash_id
esptool.py v2.1
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting...

---- please H---E---L----P---

Doron

doronby on 14 Nov 2017

What power source are you using, the ESP32 takes quite a lot of current at start-up, if your powering from a USB-Serial converter that is most likely your problem. You could add a 10uF capacitor across the supply pins of the ESP32 board, or larger if you have one.

Flashing speed is 115,200.

Sequence is GPIO0 low (usually with one of the typical push buttons, then reset, then release reset and GPIO.

Do you have pull-up resistors on your carrier board for GPIO0 and 2.

G6EJD on 14 Nov 2017

OK, I thought you were using an ESP32 bro g under the ESP32 topic, please post a link to your board so we can see what type it is.

G6EJD on 14 Nov 2017

yup 8266 problem in the esp32 thread :)

me-no-dev on 16 Nov 2017

My apologies for posting in a closed issue, but having read through this issue multiple times, and exhausting the next 3 pages of google search results, I can safely say that this is certainly not a closed issue for me.

Like the original poster, i am encountering an error upon building to my ESP32 device. It looks like so:

37.5 s platformio run --target upload | |-- <SPI> v1.0 | |-- <FS> v1.0 |-- <SPI> v1.0 Compiling .pioenvs/esp-wrover-kit/src/main.ino.o Looking for upload port... Auto-detected: /dev/cu.usbserial-14100 Uploading .pioenvs/esp-wrover-kit/firmware.bin esptool.py v2.1-beta1 Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____ A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header *** [upload] Error 2

I am using a brand new ESP-WROVER-KIT V3, and I have tried the following:

Holding the boot button as I build
Holding the boot button as I build, then releasing it shortly in.
Turning the device off, holding the boot button, turning the device on, then flashing
Unplugging the device, turning it off, holding the boot butting, turning the device back on, plugging it in, then flashing,
Doing the same 4 steps with the EN button
Doing the same 4 steps with the EN AND Boot Buttons, and releasing each at different stages in an exhaustive attempt to make things work.
Using a totally different computer to build from
Using both ESP IDF and the ESP Arduino framework in PlatformIO
Grounding GPIO2 prior to, and during flashing
Building both plugged into a breadboard, and sitting on top of a static free surface
Using both platformIO and the command line to attempt the build
Using bare minimal empty projects.
Using known code that have worked for other people.
Praying to any god who would listen

All to no avail.
I should note, that the very first time I built to the device everything worked fine. Then all subsequent attempts have resulted in the above error.

I'm willing to just chop it up to a defective device, unless somebody else has any input to add here. That would be much appreciated. I miss sleep.

shofixti244 on 22 Nov 2017

Try selecting the ? FireBeetle board type and speed 40Mhz if I recall that’s how I got programming Woking on my WRover board then I recall but not exactly that the mode needs to be DIO - no need to press any buttons if v3 board

G6EJD on 22 Nov 2017

@G6EJD You sir, are a godsend. Programming using the Firebeetle board works succesfully!

I still want to leverage the increased RAM of the WROVER, so should I make a clone of the Firebeetle board and artificially set it's reported RAM higher? Or would that actually matter at all in the first place? Also is there a danger in using an incorrect board profile?

Eitherway, thank you so much. This has certainly helped.

shofixti244 on 22 Nov 2017

I copied the FireBeetle board and named it WRover, apart from flash size I’m not aware of any compiler usage of the memory definitions so left them as they are. You can access the on-board flash but it’s not that big. Glad you have it working now.

G6EJD on 22 Nov 2017

also you will need the Espressif display driver as the v3 board has a revised driver chip, it’s on github in their repository.

G6EJD on 23 Nov 2017

Problem solved , because of manufacturing defect some esp32 chip connecter are not properly Sholder to motherboard, reheat and apply shoulder again ,and the error doesn’t appear and the sketch uploads .

Shreyashvk on 14 Dec 2017

@Shreyashvk I am curious, as despite my above comment we do still have this issue... Could you elaborate on what you soldered exactly? I'm assuming you're talking about the ESP32 module itself and not the esp32 chip within the module?

shofixti244 on 14 Dec 2017

I simply pull down the TX0 and RX0 pins (GPIO1 & GPIO3) with a 10k resistor to ground. No more problem uploading with the ESP32 on a breadboard.

w8an on 1 Jan 2018

👍1

Another solution: I got this error (and various others) with ESP32 dev board with mini USB connected to PC (taking power from there). The issue was resolved by uploading to the board with only the USB cable attached. I guess sensors, leds etc. draw current making supply unstable. It now works nicely with 921600 connection with no need to press buttons etc.

Dannsei on 18 Jan 2018

When I first saw similar errors it took me a long time to figure out it was a power supply issue. When the ESP32 starts it takes a large current, peak and this pulls regulators down unless they have plenty of spare capacity, about 1A at least, 300mA is no good. Good capacitors can help, for example a large C in parallel with a smaller one, usually 47uF and 0.1uF.

G6EJD on 18 Jan 2018

Just for the record, it took me awhile, but I found the solution for me was to change the default port to which the sketch got built to.
Thes ESP32-WROVER module I was using actually, unbeknownst to me, created two usbserial connections:

/dev/cu.usbserial-14100
and
/dev/cu.usbserial-14101

By default, PlatformIO was building to 14100, and failing. It wasn't until I forced it to build to /dev/cu.usbserial-14101 that it successfully builds every time. I doubt this is the problem everyone encounters, but it certainly solved my issue!

shofixti244 on 31 Jan 2018

It’s one of those quirks that no-one mentions, I got there by trial and error because I saw the two ports and decided to try them both.

G6EJD on 1 Feb 2018

I had timeout issues on my 2 ESP32 NodeMCUs. After some debugging I found that using a 10K pulldown on GPIO10 ( TXD1=GPIO10, Flash SD3) pin J1-17. Strange, but seems to solve the issue. When GPIO10 is pulled up I can never AUTO boot, always times out. I have to use the button. When GPIO10 is pulled down I never need to use the button.

Rki009 on 1 Mar 2018

And your GPIO2 state ? GPIO2 must also be either left unconnected/floating, or driven Low, in order to enter the serial bootloader

G6EJD on 1 Mar 2018

GPIO2 is behaving as expected. Left open or pulled down, no problem. Pull GPIO2 high and no boot

Rki009 on 1 Mar 2018

U1 TXD is not available according to the schematic. How are you programming the device, via the on-board UART using your PC USB port or directly to the board? If the latter then this is what is causing the problem IMO as your needing to pulldown U0TXD to enable programming to proceed.

G6EJD on 1 Mar 2018

I am using the USB/CP2102 interface on the NodeMCU board connected to a Window 10 PC. It uses U0TX/RX, DTR->#EN, RTS->IO0. Latest esptool.py (version 2.2.1)

Rki009 on 1 Mar 2018

Then it seems the board has a fault, as none of mine (including NodeMCU ESP32) exhibit any problems like this. Out of interest what speed are you programming it at, most of the NodeMCU boards (UART issue) won't go faster than 256000 baud.

G6EJD on 1 Mar 2018

I have been using both 256000 and 921600. Both work just fine with the 10K pull down on GPIO10. Both fail with GPI010 floating, without the pull down resistor. I can get the upload to work by putting one finger on the ESP-WROOM-32 case (GROUND) and another finger on the lower corner pins of the ESP32s NodeMCU (GPIO 13, 9, 10, 11). Easier than clicking the IO0 button.
I have tried 3 ESP32 NodeMCU devices, standalone, in a proto-board and in a socket board. They behave differently. The problem seems to be related to the load capacitance on the pins. Sorry no scope, so I can only speculate that may be an issue with the timing of the tri-stating or pull down of the FLASH data or control signals.

Rki009 on 1 Mar 2018

It's certainly an interesting problem. I think GPIO-10/ 9 are used for flash memory read/write on that SPI bus, so it looks like when you hold those pins the state of one input is being changed maybe internal Flash (under the EMI cover usually) and probably SS, but who knows. Maybe a bad soldering batch. GPIO-9 will usually be configured as n input, 10 an output and 11 is the SS/CS, which can all be construed as being related to the problem IMO.

G6EJD on 1 Mar 2018

Hello, for those who still have this problem.

In my case the problem was in some way caused by level shifter that was floating on HV side (nothing connected) and that prevented DOIT ESP32 DEVKIT V1 from flashin with that error

esptool.py v2.1-beta1
Connecting........_
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0xffffff, SizeID=0xff), defaulting to 4MB
Compressed 8192 bytes to 47...

A fatal error occurred: Timed out waiting for packet content
A fatal error occurred: Timed out waiting for packet content

====

The solution was to unsolder the cable that connects the esp32 dev boards 3.3 v pin from level shifter.
(power line for LV side of level shifter) and flashing was fine, ater flashin and resoldering the cable board works fine in production env. , really starnge. So if you are powering something from the boards regulator in a time of flashing it may cause that problem. the problem does not exist when level shifter is using it's own regulator that i have added.

So the cause of the problem might be the power drop on commonly used AMS1117 regulators (or power consumption limits on USB port, i will test that scenario using HUB with its own power when I buy one of those because I do not have one at the moment on my desk)

I hope that helped someone to solve the problem.

Cheers.

Netoperz on 2 Mar 2018

Also please note if you try to run an ESP32 sketch using a USB-UART convertor the ESP32 will generally fail to start because the Regulator in nearly all USB-UART's have insufficient capacity to supply enough current (~400mA) at start-up to the ESP32. Normal current demand is ~140mA after a large initial demand of ~340mA. This gives the impression the chip or sketch is faulty, but it's not!

G6EJD on 2 Mar 2018

That's true, I'm using ESP32 in many different production devices, also in automation, and i had some hard moments till i have figured out why the problems are in some cases and in other cases not.

There is one more situation that will cause that problem, and it is relevant to the logic levels on GPIO's when the board is in flash mode. For example if you give high level signal on RX2 pin on doit board it will result with A fatal error occurred: Timed out waiting for packet content.
so choosing proper pins for proper peripheral devices is very important, In my case external WIEGAND keyboard could work only on some pins due to the signaling that this kind of interface generates (solving that took 2 weeks of testing, especially when you are building complex system with many external devices on different interfaces than you do not have many pins to take, in some cases we had to put some work on coprocesors to handle some routines ).

In general ESP32 is a good micro-controller and we have left STM and PIC behind, and making stuff only on ESP32 for production stuff without major problems. Pitty that it does not have USB support :)

And menodev is a milion dolar worth support team in one person when it comes to "strange problems" ;)

Netoperz on 3 Mar 2018

Hi for those who still have this issue, you can replace USB cable and test again. I had same issue like you before and just fixed this issue last night and link below have detail test report. Now my NodeMCU-32S Lua ESP32 development module (from AiThinker, no need to press BOOT or RST key before press Arduino upload function) can use Aduino IDE on both Windows and iMac.

https://www.blogger.com/blogger.g?blogID=7530656930048997875#editor/target=post;postID=1747782269863974052;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=0;src=postname

a0908896067 on 12 Mar 2018

It is greatfull that you have read it.
The issue that mention before was of ESP8266 node mcu which had chip
esp8266 that haven't mounted properly with the motherboard itself. So, i
have resholder the (leg/tip) of esp8266 chip.
And it run without any error.

If still you have any problem, i will be happy to help.

On 14 Dec 2017 10:24 pm, "shofixti244" notifications@github.com wrote:

@Shreyashvk https://github.com/shreyashvk I am curious, as despite my
above comment we do still have this issue... Could you elaborate on what
you soldered exactly? I'm assuming you're talking about the ESP32 module
itself and not the esp32 chip within the module?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/espressif/arduino-esp32/issues/333#issuecomment-351770065,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYzkTm9lN1OwrxZEpgYfpl5vUYQd9StNks5tAVLLgaJpZM4NIkny
.

Shreyashvk on 12 Mar 2018

Thanks Shreyashvk,

I don't think it's soldering issue. If you read my test report, you should see that I used 7 different USB cables from different manufacturers and the result is 2 failed and 5 OK. If it's soldering issue, it should be 7 all failed, right. I believed that it's USB impedance matching issue.

a0908896067 on 12 Mar 2018

Many USB to microUSB cables are of relatively high impedance leading to voltage drop, this is why Apple devices (measure voltage on-charge) report chargers that don’t meet their requirements. Given the ESP32 can require ~400mA as a startup transient it does expose poor quality cables and power supplies. These are all good observations to help others diagnose problems and we should all do this.

G6EJD on 12 Mar 2018

If you are using an ESP8266 board you need to change the chip type in the esptool setting file. Find the file called Makefile.projbuild in the folder \esp-idf\components\esptool_py and edit it with a text editor.
Change the --chip esp32 to --chip esp8266 in this file and save, then try make flash again.

This time it will work because when trying to start flashing, it will look for a response header specific to an ESP8266 not to an ESP32.

If you set the string --chip esp32 to --chip auto it also works.

tuncel3 on 16 Mar 2018

thanks tuncel3, I use esp32 dev module and now it works great after I replace the USB cable. I am sure that my issue is the cable which is poor quality.

a0908896067 on 16 Mar 2018

Hi, i had already a working ESP-WROOM-32 Developerboard. Then i bought from the same distibutor 3 new ones. With my "old" ESP32-Board, i could compile from Arduino IDE without problems. With all the new ones, i got the errormessage "Failed to connect to ESP32: Timed out waiting for packet header". I don't know exactly how, but i got it working with two changes:

I had the USB cable on a USB3.0-port. After putting it into a USB2.0-Port, i was able use the terminal with it (it sends a "Hello"-message). Nevertheless, after this step i still got the errormessage while compiling and uploading.
So i tried a solution from this thread to press the BOOT-Button while trying to connect (dots and underlines are shown in the IDE). After pressing BOOT for 2 secs, the upload finishes and everything works.

Changes in Uploadspeed, flash size or flash frequency didn't change anything for me. I always use flash mode QIO. Maybe this helps someone.

deralex80 on 9 Apr 2018

👍4

Excellent advice deralex80, hitting BOOT for 2 seconds when the 'Connecting...___...___...' message was displaying allowed my sketch to upload perfectly. Hitting BOOT did not work when the button was hit at any other time.

This thread is the first search result on Google when searching this particular error message, so I thought I'd add that anyone stumbling upon this via a search should try this quick and easy method before buying new cables or trying to change settings in Arduino IDE.

RumHamRadio on 19 Apr 2018

👍2

These problems are almost always due to poor power supplies and a lack of smoothing capacitors, when the ESP32 starts it demands about 410mA and few normal regulators can deliver the power.

G6EJD on 19 Apr 2018

G6EJD, if that's the case, why does using the boot button help fix the issue?

RumHamRadio on 20 Apr 2018

To ready an ESP32 for flash programming, the correct sequence is to hold down the boot button and then press reset. So press and hold the boot button then press and release the reset when the cpu starts with the boot button low, it will enter the flash programming mode. The Espressif data sheet gives the conditions to enter programming mode. All development boards provide the correct sequence via a bistable gate arrangement are you programming a bare breakout board or using a development board?

G6EJD on 20 Apr 2018

I experience the same problem, with the "new" Doit Development board with 18 pins on each side. I have connected a 0.96 inch OLED to the ESP32 on a breadboard over i2c.

Here is the thing; when the OLED is attached, and the ESP running a sample program, I cannot flash. When the OLED is disconnected, I can flash. Holding boot, and pressing the "EN" button on the chip does nothing.

I don't know if this is related to the OP problem, sorry for hi-jacking if not.

glennbech on 7 May 2018

Your problem is typical of the on-board regulator not being able to supply enough power to drive the ESP32 at start-up and the OLED. Most development boards fit a relatively low capacity regulator of 500mA capacity, but your ESP32 takes typically ~400mA at start-up leading to these sort of errors.

G6EJD on 7 May 2018

I am also having same issue with my DOIT ESP32 v1 board, but my particular find out is:

I can flash even at 921600 baud when I have the board disconnected from any circuit.
But when I place the board on a breadboard( even no wires, or components attached, just the board) I can't upload sketch.

I think its because some sort of stray capacitance or similar issue.
I have tried pressing boot during upload along with reset button in sequence but couldn't fix the issue so far.

shkhamd on 21 May 2018

Have you tried flashing at the default speed of 115200 baud? Your thoughts as to stray capacitance are probably correct.

G6EJD on 21 May 2018

yes, I can flash it at any baudrate, works every time with no problem when only the board is connect without any component to it.
However, never succeed to flash when placed on a breadboard.
Currently it fine for me, but have to figure out a way for in-circuit programming for my upcoming projects.

shkhamd on 21 May 2018

I'm not sure what difference between the breadboard environment and board by itself is, I presume you have external components connected to the ESP32 on the breadboard. If so, it is highly likely that your power supply arrangements are insufficient to meet the demands of the ESP32 and external components, the ESP32 needs a minimum of 400-500mA then add your external componentry (unknown) demands and you should be working towards ~1000mA capacity. This is a peak demand requirement , when nominal probably about 150mA. Need more information on loads.
Unless your saying that a bare ESP32 will not programme on a breadboard, in which case speed is an issue usually with external UART's and you can't supply power in my experience from the UART and you have to set the correct conditions on the ESP32 for it to programme.

G6EJD on 21 May 2018

Unless your saying that a bare ESP32 will not programme on a breadboard, in which case speed is an issue usually with external UART's and you can't supply power in my experience from the UART and you have to set the correct conditions on the ESP32 for it to programme.

yes, that is exactly the case, my bare ESP32 board is placed on the breadboard and sketch doesn't flash (unless I pull it off from the bb and flash again), i have tried all combinations of baudrate and DIO/QIO/DOUT modes for the flash.
Also tried to manually put the chip in flash mode with the boot button, doesn't work either.

shkhamd on 21 May 2018

👍1

You can’t fit an ESP32 using a breakout board onto a breadboard, what sort of board are you using? Is it the double-row type like most, if so then that’s the problem as the pins get shorted out.

G6EJD on 21 May 2018

yes I am using DOIT Devkit v1 board, similar to the Nodemcu board.

shkhamd on 22 May 2018

👍1

What type of breadboard.

The board programmes OK when not in breadboard.
When inserted into the breadboard, it does not. So it must be the breadboard.

Suspect unusual wiring of the breadboard or a fault on it. The stray capacitance is minimal, but it could be rows are shorted together, have you checked with a DVM for inter-row shorts?

G6EJD on 22 May 2018

Interesting thing I found out with the board.
Its not the breadboard actually. Its the TX0 and RX0 pin or the ESP32.
Since the breadboard traces are like a short cable connected to each pin; to mimic the breadboard trace behavior I did the following:

TX0----[Female Jumper Cable Connected]
RX0----[Female Jumper Cable Connected]

and guess what, the code failed to upload.

From the DOIT DevKit V1 schematic I found that TX0 and RX0 pins are connected to the USB-UART Transceiver chip in the following way:

ESP32.TX0---------[TX0 physical pin in this net]----------[1K Res]--------USB-UART-CHIP
ESP32.RX0---------[RX0 physical pin in this net]----------[1K Res]--------USB-UART-CHIP

So my conclusion is since the signals in the traces of TX0 and RX0 physical pins are in a high impedance path (due to that 1k resistor), therefore they are more susceptible stray capacitance and all that sorts of environmental noises.

Therefore, to successfully upload code, at least the TX0 and RX0 pins has to be disconnected from any other additional circuitry (even wires o jumper cables too) in DOIT DevKit V1.

I have 2 such boards, this theory worked with both of them.

shkhamd on 27 May 2018

👍2

Solved it thanks to @w8an

My board is like this:

Putting this board in a breadboard would give the error in this thread. All I had to do was to place a 10k resistor from RX0 (GPIO3) to GND. This solved everything for me. Hope that helps!

salqadri on 14 Jul 2018

I'm using the HiLetgo boards from amazon and this solution worked for me:

when you click on "upload sketch" in the IDE, ...the sketch is recompiled, relinked and uploaded
before upload phase starts, during compilation stage, hold the "EN" button of the board
this maintains the board in reset state
then push and hold the "BOOT" button
when you see the IDE has started the upload stage (esptool bla bla bla.....), release the EN button and then after a short delay release the BOOT button

...but seems like a hack rather than normal operation - and certainly isn't sustainable for a production setting.

Has anyone got two boards from the same manufacturer where one works normally and the other doesn't - or you have received a replacement board (of the same type) that worked normally ?

gigmaps on 17 Jul 2018

If you check the data sheet you will see this is sequence required to switch the esp to serial port programming of the flash memory. In simple terms and within a 20-sec or so time out period you press the boot button hold it it then press the EN then release EN then released BOOT the device is then in serial port flash programming mode. If no valid start sequence is detected eventually it times out and reverts to normal operation. Most development boards have a pair of cross coupled gates to do this for you.

G6EJD on 17 Jul 2018

@G6EJD thanks - so you're saying this whole issue (ie the OP's problem) is simply normal operation for a base level dev board - but some of us are used to boards that do this sequence for us ?

gigmaps on 17 Jul 2018

No not necessarily a lot of people try to programme the esp with a usb-UART which don’t have the power delivery requirements for an ESP32 and causes similar problems the only way to be sure what’s going wrong is to monitor the ESP32 serial port during a programming attempt because it gives you the associated error messages to enable quick debugging of the programming task. For a bare board the sequence to initiate programming via the serial port is the simple hold the boot then momentarily press the en then release en then release boot it then sits waiting for a programming sequence about 20-30 secs before tone out. A development board uses the usb lines to set-reset a pair of gates that assert the same logic states in the required sequence to boot and en. It’s not special but it works every time.

G6EJD on 17 Jul 2018

in an interesting twist:
if I use the Esptool to erase the flash memory of the board, IDE sketch upload via USB works fine again - ie without having to go through the sequence I describe above

...but only for the first sketch upload - subsequent sketch uploads fail - sometimes with a different error message:

A fatal error occurred: Failed to connect to ESP32: Invalid head of packet (0x00)

However to get the esptool to work you'll have to use the Reset button :

download (or install) the esptool from https://github.com/espressif/esptool
run the erase_flash command python ./esptool.py --port=/dev/cu.SLAB_USBtoUART erase_flash
once you start seeing the following lines

Connecting........_____....._____....._____.....

click & hold Reset (left button) for 2 seconds then release

output looks like:

Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision (unknown 0xa))
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 3.4s
Hard resetting...

gigmaps on 17 Jul 2018

Just a hit for someone looking for a solution. I had similar problem with (fake)Wemos D1 R32. A board like this.
According to ESPduino 32 specification it is said that: _"The baudrate to flash for Esp32 must be 230400"_. Then it works. It's worth mentioning that my other ESP32 boards go with default 921600.

The problem was exactly like described in this thread.

Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...

A fatal error occurred: Timed out waiting for packet content

If you use PlatformIO, it's enough to add in platformio.ini a line like below:
upload_speed = 230400

baldram on 5 Aug 2018

That board has a UART between the USB and ESP32 and it will be that device ?cp2104 that will be limiting programming speed, nothing to do with the ESP32. This is a very common arrangement and many won’t reliably programme any faster that 115200 baud.

G6EJD on 5 Aug 2018

@G6EJD Exactly. You're right. It's nothing about ESP32 itself. The original Espressif ESP32 DevKitC works like a charm. The cheap one (ESPDuino-32) has slow USB to UART Bridge.

baldram on 5 Aug 2018

I am having this issue with an M5CAM module (using the wrover-kit board configuration), shorting pins will be a pain as the IO is not broken out, it has the cross coupled transistors for the EN and IO0 pins and 4MB rom same as wrover kit. I am using platformio and adding ..

upload_speed = 115200 to platformio.ini has not helped, port is detected correctly,

major lack of info for these out there, instructions on running the preprogrammed sketch and the schematic (whew) .. but thats about it. Will update when I find a solution.

stonemull on 7 Aug 2018

How are you powering the board? You need a psu with at least 1.5A capacity.

G6EJD on 7 Aug 2018

I dont think its a power issue.
It has an lithium (I have an 18500 attached) that I can use or not,that is the only way to connect any external power without tacking into the rail somewhere.
I get the same result with or without lithium connected, why 1.5A ? seems a little excessive.
The same USB cable happily programs an M5Stack which is also ESP32 and usually it is charging the battery as well as having a backlight on.
The highest current I have seen with a USB power monitor is 910mA while it is fast charging, drops to 210mA peak once charged.
I identified the best areas to tack some wires onto to add an external boot switch or at least monitor it..

edit .. oh schematic is here if anyone is interested.
https://github.com/m5stack/esp32-cam-demo/blob/m5cam/M5CAM-ESP32-A1-POWER.pdf

edit2: EN is also the rear pins (closest to grove connector) of the reset button, note to me, white wire is GPIO, blue is EN.

stonemull on 7 Aug 2018

ok, adding a wire to GPIO0 and connecting it to ground (battery -ve wire) and I had success at 115k first try (and then at 960k as well)
Another thing I have not seen mentioned here that can cause issues is check the propertys for the serial port in device manager and have a look at "hardware flow control", it should be set to "none" if your device does not have the 2 transistor logic on RTS/DTR to EN/GPIO0. Without those transistors and a direct DTR-GPIO and RTS-EN connection then hardware flow control will hold the chip in reset. With those transistors it should not matter but worth checking nevertheless.

proof...
Connecting.....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse
MAC: 80:7d:3a:c4:85:cc

Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 19168 bytes to 11299...
Wrote 19168 bytes (11299 compressed) at 0x00001000 in 1.0 seconds (effective 150.9 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 82...
Wrote 3072 bytes (82 compressed) at 0x00008000 in 0.0 seconds (effective 877.7 kbit/s)...
Hash of data verified.
Compressed 519344 bytes to 319473...
Wrote 519344 bytes (319473 compressed) at 0x00010000 in 28.7 seconds (effective 144.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
=== [SUCCESS] Took 53.90 seconds

stonemull on 7 Aug 2018

Well been looking at the EN and GPIO0 lines on pulseview and it is apparent why it consistently fails on this hardware, when EN is released from reset the GPIO0 line is always high, just.
This image is a failed program sequence ..
esp32_gpio0_norm_prog_fail

a zoom in one of the edges (they are all much the same timing)
esp32_gpio0_norm_prog_fail_zoom

and just for comparison a successful program with GPIO0 held low..
esp32_gpio0_low_program

Does that give anyone any ideas on how to resolve this ?

I cant see any options in esptool that affect timing configuration.
https://github.com/espressif/esptool/wiki/Advanced-Options

stonemull on 7 Aug 2018

It looks like the board has not been designed correctly, quite common, as the ESP states for flashing as you’ve discovered are not correct. Probably worth complying about the board

G6EJD on 7 Aug 2018

actually I made a mistake, the "reset button" on this board is not connected to EN, it is net label SW_KEY and is connected to pin 5 of the IP5306 and turns power on and off, however I now am monitoring the EN line and the timing looks identical so I suspect there is a connection between the 2 not shown on the schematic, the centre of the last image on the schematic shows a 10k resistor between net PWR and EN that is the only mention of the PWR net on the entire pcb, so perhaps it is that.
I am going to add a cap to the EN pin and see if it slows it down sufficiently to boot.
It might be why these boards are cheap currently.

edit: ok docs seem incomplete, I am getting continuity of 18-22 ohms (polarity dependent) between the reset button and EN line, adding a 1uF cap across the button had made zero difference to the timing which I find odd.

stonemull on 7 Aug 2018

Ok I thought this was an issue previously addressed at ..
https://github.com/espressif/esptool/issues/136

however I only just noticed there is a difference between this board and the WROVER-kit.. I think it has a design error but I am not sure as others have successfully programmed it.
I was looking at esptool.py and also the schematic and I wondered how GPIO0 is ever pulled low..
From the schematic of the M5CAM ..

and from the WROVER kit..

So VT2 appears to be wired with collector-emitter reversed.
will have a better check tomorrow, but it looks a bit suspect to me, I did do a continuity test between VT2 emitter and pin 23 of the esp32.

edit: ah of course .. the transistor will work with C-E reversed, it may well affect timing though.

stonemull on 7 Aug 2018

When DTR is low and RTS high then GPIO-0 is low, well Vce above the voltage on DTR

G6EJD on 7 Aug 2018

I was confused by the comments in the esptool python code around line 400 as they appeared to not do what was expected, but of course they are for the non-inverted logic. So set.DTR(False) is setting the DTR or nDTR pin high. So the little auto program logic diagram on the wrover sheet is confusing till you reverse the logic polarity.

        self._setDTR(False)  # IO0=HIGH
        self._setRTS(True)   # EN=LOW, chip in reset

        self._setDTR(True)   # IO0=LOW
        self._setRTS(False)  # EN=HIGH, chip out of reset

Also the WROVER uses a FT2232 (nets are marked nDTR and nRTS) but the M5cam uses a CP2104 and I thought perhaps the signal polarity was wrong but CP2104 datasheet says "Data Terminal Ready control output (active low)" and same for RTS, so they are in fact nDTR and nRTS.
Since no combination of RTS and DTR can set both EN and GPIO0 low, so they are relying on a 100nF cap across EN/ground to delay the edge on the reset signal as you need both low to allow entering programming mode, just before you take EN high to leave reset.

I hear the ESP download tool works on programming these so going to look at the timing on that.

stonemull on 8 Aug 2018

quick update, ESP download tool had exactly the same timing so was also unable to program it, I ended up adding a 100nF between base-emitter of VT1 to slow down the rise time of the EN pulse when nDTR goes low, it appears to work so far, programmed first time from platformio anyway.

stonemull on 21 Aug 2018

👍2 😄1

I solved the problem by updating the macOS drivers from:
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

After reboot the ESP-32 appears under a different port name than before:
/dev/cu.SLAB_USBtoUART

No button press is needed als always.
The Mac recognises the USB as CP2102 USB to UART Bridge Controller from Silicon Labs as before.
My upload speed is set to 921600 as usual.

s-hintz on 27 Aug 2018

Had the same problem with Wemos LOLIN 32 pro v2.
Connected GPIO 0 and GND fixed it.

Lotsanoiz on 30 Aug 2018

There is an issue about SiLabs CP210x drivers uninstall.sh on macOS. kextunload is unable to unload the driver if an instance still exists. I am not sure how that happens but I recommend the following procedure to install new drivers:

execute uninstall.sh from the terminal
restart your mac
install new drivers

How to diagnose the issue:

$ sudo kextunload -b com.silabs.driver.CP210xVCPDriver
(kernel) Can't unload kext com.silabs.driver.CP210xVCPDriver; classes have instances:
(kernel)     Kext com.silabs.driver.CP210xVCPDriver class com_silabs_CP210xGPIO has 1 instance.
Failed to unload com.silabs.driver.CP210xVCPDriver - (libkern/kext) kext is in use or retained (cannot unload).

ddacunha on 20 Sep 2018

I had a same problem,
I have:
https://www.adafruit.com/product/3269

It works for me just by holding the boot button while programming.
$ make flash
Flashing binaries to serial port COM23 (app at offset 0x10000 )...
esptool.py v2.5.0
Serial port COM23
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Invalid head of packet (0x52)
make: * [/home/imanpakii/esp/esp-idf/components/esptool_py/Makefile.projbuild:63: flash] Error 2

Now when I hold the boot button I get this:
$ make flash
Flashing binaries to serial port COM23 (app at offset 0x10000 )...
esptool.py v2.5.0
Serial port COM23
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core
MAC: 24:0a:c4:08:56:68
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 20928 bytes to 12366...
Wrote 20928 bytes (12366 compressed) at 0x00001000 in 0.2 seconds (effective 766.6 kbit/s)...
Hash of data verified.
Compressed 136272 bytes to 66940...
Wrote 136272 bytes (66940 compressed) at 0x00010000 in 1.3 seconds (effective 812.0 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.0 seconds (effective 787.7 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

So it's work each time I hold down the boot button.

Thank you '
Iman

imanpakii on 12 Oct 2018

as an update I've got the flashing working without having to press / hold the boot button with the following changes:

HiLetGo agreed to send me two replacement (updated?) ESP32 chips - effectively ESP-WROOM-32 boards - they look almost identical, both listed as V1.1 but the writing on the wifi cover is slightly smaller on the new boards
updated the SiLabs CP210x drivers to v5.0.6 (running Mac OS 10.13.6)

Fairly certain its the new boards rather than the drivers since the old boards still require boot button press - even with the new CP210x drivers.

P.S. For those wondering why this is important - it's very hard to press the boot button for updates via USB cable when the board is enclosed in a housing / project box (as mine is). OTA updates might be ok but I haven't got to that stage yet.

gigmaps on 12 Oct 2018

I have 10 working boards from one supplier and 10 dodgy boards from another. All are marked "NODEMCU ESP32s V1.1 101010"
The Twist I have to add is the following:
As in most cases above, on the dodgy boards I have to hold the BOOT button in order to get past the ......._____.... part of the download process. The working boards don't require the BOOT button to be touched.

If I erase the flash with a python from the command prompt on windows 10:
"C:\Python27\python C:\Projects\ESP32\Python\esptool.py --port com9 erase_flash"
I still need to hold down the Boot key.
BUT HERE IS THE INTERESTING BIT
After I have erased the flash I am able to download the any Arduino sketch once and only once.
I did try to see if the issue was code related but its not. Even downloading "Blink" will prevent me from downloading without the BOOT key a second time.

This leads me to believe there is a subtle difference in the CPU or code embedded in the CPU between these two modules.

GwynMunich on 26 Oct 2018

See here:

http://esp32.net/

Scroll down to ESP32S you will see they are clones made by AI-Thinker, but no longer available but still being sold.

G6EJD on 26 Oct 2018

This is the message from the Arduino firmware flasher, just after connection is made:

Chip is ESP32D0WDQ6 (revision (unknown 0xa)) ------ FAULTY UNIT

Chip is ESP32D0WDQ6 (revision 1) ------ WORKING UNIT

It would appear that I have been shipped some older ESP-32 modules with the ESP-WROOM-32 modules that contain older silicone.

The ODD thing is the fact that they work after flash is erased.

I'm noticing that if I touch some of the GPIO pins that are connected to the internal Flash it will occasionally boot without the BOOT button being pushed. Also, if I probe these pins they appear to be floating during the boot process.

I'm wondering if the issue is do do with floating pins needing to float to ground and holding the BOOT button simply extends the period the pins are given to reach ground. I'll look at this and let you know.

in another twist I also have a small batch Mini ESP32 from WeMos; no Boot button and always downloads. and displays:
Chip is ESP32D0WDQ6 (revision (unknown 0xa)) ----- WORKING UNIT (WeMos MINI)

GwynMunich on 26 Oct 2018

If you check the ESP32 data sheet it tells you exactly what pin states are required to boot, for example boot from serial port or flash. Essentially GPIO-0 and GPIO-2 and yes all other pins demising in tristate until programmed otherwise.

G6EJD on 26 Oct 2018

quick update, ESP download tool had exactly the same timing so was also unable to program it, I ended up adding a 100nF between base-emitter of VT1 to slow down the rise time of the EN pulse when nDTR goes low, it appears to work so far, programmed first time from platformio anyway.

This totally solved my issue. Adding 100nF on VT1 (see picture below) fixed my "Lolin32 oled clone".
Autoupload is working finally!

img_20181026_213705

cimba007 on 26 Oct 2018

👍2

if I use RealTerm set to 115200 I can switch RTS and DTR, setting RTS H and switching DTR L->H the units produce boot screen text with different results.
The good units produce:
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:10212
entry 0x40078a00

The Bad units produce
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:812
load:0x40078000,len:0
load:0x40078000,len:10212
entry 0x40078a00

the difference is rst:0x1 (POWERON_RESET) on the dodgy units and rst:0x10 (RTCWDT_RTC_RESET)
I assume these are the state of the boot pins as the unit comes out of reset.
I don't claim to understand exactly why this may be the case but its the first evidence that might point me in the right direction.
I wonder if the boot loader reads the pins and takes the first bit to be set as boot mode.
I and tie GIO5 high with a 0.1uF cap to gnd and the dodgy units load code all be it with some delay.

I still don't consider this to be a solution.

GwynMunich on 27 Oct 2018

With the above example;
the good units seem to be getting a second reset, is this reset due to code running on the CPU?

If I erase the flash and watch the results on the RealTerm
both units repeatedly send out:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

GwynMunich on 27 Oct 2018

I have made this mod and it works every time on the faulty units now.

esp32 boot mod

On 26/10/2018 21:39, cimba007 wrote:
>

quick update, ESP download tool had exactly the same timing so was
also unable to program it, I ended up adding a 100nF between
base-emitter of VT1 to slow down the rise time of the EN pulse
when nDTR goes low, it appears to work so far, programmed first
time from platformio anyway.
This totally solved my issue. Adding 100nF on VT1 (see picture below)
fixed my "Lolin32 oled clone".
Autoupload is working finally!

img_20181026_213705
https://user-images.githubusercontent.com/3453121/47588736-730eaa80-d967-11e8-9ef3-e005cf8062bd.jpg

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/espressif/arduino-esp32/issues/333#issuecomment-433521147,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqX0UGVSaavYx0x6GJDM5dVBv0N8iW_iks5uo2UCgaJpZM4NIkny.

GwynMunich on 27 Oct 2018

It is booting in the wrong mode, have you checked the GPIO pin states against the requirements set out in data sheet?

Are your boards based out bare ESP32’s or development boards?

G6EJD on 27 Oct 2018

I have the NodeMCU ESP-32S V1.1 and some identical looking clones with the problem,.
The SilkScreen on the PCB has EN by one button and IO0 by the other. On the Faulty clones the EN text is mirrored

GwynMunich on 28 Oct 2018

Very weird: I was able to program my ESP_DevKit32_V4 without problem. Then I put it onto a breadboard and this error msg popped up. I tried about everything from this thread to no avail, until I popped the device out of the breadboard. Now it works again! Even if I put it back in.
It's just too obscure to be true ...

weego on 19 Nov 2018

Try the cap mod. It appears to be something to do with timing of the EN
/ GPIO0 pins.

Gwyn Evans
Mobile Video Systems
Spitzwegstr. 10
81373 München
+491733510658

On 19/11/2018 14:05, weego wrote:
>

Very weird: I was able to program my ESP_DevKit32_V4 without problem.
Then I put it onto a breadboard and this error msg popped up. I tried
about everything from this thread to no avail, until I popped the
device out of the breadboard. Now it works again! Even if I put it
back in.
It's just too obscure to be true ...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/espressif/arduino-esp32/issues/333#issuecomment-439885966,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AqX0UNMncMYhvgbdlRxn1WUNM5zBHdi6ks5uwqyBgaJpZM4NIkny.

GwynMunich on 19 Nov 2018

yes it certainly is related to changes in capacitance of the electric parts. So, as soon as the problem should re-appear, I will do it. For now, there's no need because it's all fine :)

weego on 19 Nov 2018

I did not have this issue until I downloaded the latest version. I an using the ESP32THING from sparkfun. Sometime it connects without holding down the BOOT LOAD button (GPIO0). Other time I must press the BOOT button during the connect. This happens on three different computers running win10 and win7. I am able to build and load BLINK but when I try to run my old code that uses RTOS, I2S, DMA, RMT, and interupts it builds and loads but does not run. The old version from a year ago works fine.
ws2812_1024FFT_real_imag_OK.zip

RussBarr on 27 Nov 2018

Have you run any diagnostics on your old code since the ESP core was updated, it seems more likely to be a code issue than hardware. You should be able to trace programme flow to determine where it’s failing.

G6EJD on 27 Nov 2018

I started to debug. My RMT driver is timming out. It uses the RMT device with interrupts. It looks like the RMT never outputs anything and never generates RMT interrupts. I need to go back to debugging interrupt using GPIOs set reset and my digital scope since serial debug will not work in an IRQ.
My code runs fine in the earlier version from about a year ago.

RussBarr on 27 Nov 2018

Have you disabled IRQ’s first thing in the IRQ handler, there’s a macro to do that.

G6EJD on 27 Nov 2018

Try to monitor GPIO0 and GPIO2 while sketch is being uploaded. GPIO0 & GPIO2 both has to be pulled down which is a requirement on ESP32 to run it into boot mode unlike ESP8266.
@kp372 You are correct. In my case, I used GPIO2 for DHT signal, so the problem solved if I remove the DHT pin 2 when flashing.
Thank you very much!

tuan-karma on 30 Nov 2018

Thanks for the help. My problem looks like that the GPIO pin is not being mapped into the RMT device anymore.

I use the following code to do this. It worked in the old core of about 1 year ago.

This code gets called once during RMT setup.

PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[gpioNum], 2);

gpio_matrix_out((gpio_num_t)gpioNum, RMT_SIG_OUT0_IDX , 0, 0);

gpio_set_direction((gpio_num_t)gpioNum, GPIO_MODE_OUTPUT);

If these are not the function I should be using please let me know how to do this

From: G6EJD [mailto:[email protected]]
Sent: Tuesday, November 27, 2018 4:05 PM
To: espressif/arduino-esp32
Cc: RussBarr; Comment
Subject: Re: [espressif/arduino-esp32] A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header (#333)

Have you disabled IRQ’s first thing in the IRQ handler, there’s a macro to do that.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/333#issuecomment-442216402 , or mute the thread https://github.com/notifications/unsubscribe-auth/AM2bLRTJNeKSqY4yFSK_v5sWhA8Fh4Cqks5uzaj6gaJpZM4NIkny . https://github.com/notifications/beacon/AM2bLQVec3VgTI84_AV1xM7i0IencvJCks5uzaj6gaJpZM4NIkny.gif

RussBarr on 30 Nov 2018

It looks like my GPIO is not correctly mapped to the RMT device anymore. This code worked about 1 year ago

PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[gpioNum[j]], 2);

gpio_matrix_out((gpio_num_t)gpioNum[j], RMT_SIG_OUT0_IDX + i, 0, 0);

gpio_set_direction((gpio_num_t)gpioNum[j], GPIO_MODE_OUTPUT);

Do you know what functions/macros need to be used today?

From: G6EJD [mailto:[email protected]]
Sent: Tuesday, November 27, 2018 4:05 PM
To: espressif/arduino-esp32
Cc: RussBarr; Comment
Subject: Re: [espressif/arduino-esp32] A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header (#333)

Have you disabled IRQ’s first thing in the IRQ handler, there’s a macro to do that.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/333#issuecomment-442216402 , or mute the thread https://github.com/notifications/unsubscribe-auth/AM2bLRTJNeKSqY4yFSK_v5sWhA8Fh4Cqks5uzaj6gaJpZM4NIkny . https://github.com/notifications/beacon/AM2bLQVec3VgTI84_AV1xM7i0IencvJCks5uzaj6gaJpZM4NIkny.gif

RussBarr on 30 Nov 2018

My RMT problem is related to me setting up mapping to the RMT myself with the following 3 statements at init time.

PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[gpioNum[j]], 2);
gpio_matrix_out((gpio_num_t)gpioNum[j], RMT_SIG_OUT0_IDX + i, 0, 0);
gpio_set_direction((gpio_num_t)gpioNum[j], GPIO_MODE_OUTPUT);\

This worked about a year ago

If I replace them with the following function call from RMT.H it works fine with the new version of ESP32.

rmt_set_pin((rmt_channel_t) i, RMT_MODE_TX, (gpio_num_t) gpioNum[j]);

Thanks for the help

Have you disabled IRQ’s first thing in the IRQ handler, there’s a macro to do that.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/333#issuecomment-442216402 , or mute the thread https://github.com/notifications/unsubscribe-auth/AM2bLRTJNeKSqY4yFSK_v5sWhA8Fh4Cqks5uzaj6gaJpZM4NIkny .

RussBarr on 30 Nov 2018

RMT pins are now predefined, good to hear it’s resolved.

G6EJD on 30 Nov 2018

Worked for me when I keep pushing down the IO0 button until the upload begins. Works on default baud rates, I guess is 921600, or 115200 is also OK.
NB: for the Serial, I set it to 9600 to be able to read the ouput, cannot read on 115200

leductan-nguyen on 18 Dec 2018

You should not have to press Boot button, but while you solve the problem you can put a button, as in this image:

And test at a lower speed like me-no-dev say in the second comment.

Is there are permanent solution where I will not need to press each time ? thanks in advance

TechSgin on 2 Jan 2019

Same problem with my ESP32 WROOM 32. Pressing the button "BOOT" during the download (some times many times) solve the issue.

geraldhuguenin on 3 Jan 2019

So the correct sequence is to press and hold the BOOT/EN button, then momentarily press the RESET until the device enters FLASH programming mode, then you can release the BOOT/EN button once you see programming progressing.

G6EJD on 3 Jan 2019

In my case (LOLIN32 believe it is fake) it get even worse where i need to put 1000uF cap between the GND and the 3.3V pins for the BLE and WIFI to work. :-(

if I don't put the 1000uF cap i get;
Brownout detector was triggered ... :-(

I have tried to put a cap on VT1 (UMH3N chip legs 1 and 3) between the emitter and base but in my case again LOLIN32 the UMH3N IC is too small for my eyes and hands.

see LOLIN32 schematics;
http://esp32-server.de/wp-content/uploads/LOLOIN32_Schaltplan.png

thanks guys

TechSgin on 3 Jan 2019

@TechSgin if you are seeing a brownout I'd check how you are powering the board, if via USB you may need a different cable. WiFi and BLE will have a significant power draw at runtime which would explain the need for the added cap.

atanisoft on 3 Jan 2019

@TechSgin if you are seeing a brownout I'd check how you are powering the board, if via USB you may need a different cable. WiFi and BLE will have a significant power draw at runtime which would explain the need for the added cap.

thanks @atanisoft
I have tried all my power supplies with no success, only the CAP between the 3.3 and GND works.
I believe that the on board 3.3 regulator is not up to the task :-)

TechSgin on 5 Jan 2019

@TechSgin I have a whole bunch of those (probably fake) Lolin32's with exactly the same brownout problem, but a 220uF is enough in my case.

Older boards (which probably were not fake), did not have this problem.

A quick way I found to distinguish between faulty/fake boards and good ones, is that faulty Lolin32s upon connection to power (USB or external) flicker their CHG LED, even though no battery is connected.

I hope this helps someone, but we are already off topic.

mouridis on 9 Jan 2019

👍2

@mouridis , thank you mine is blinking without a battery too 😉

TechSgin on 10 Jan 2019

when i try to compile a code for esp 32 it is showing this

_Board lolin32 (platform esp32, package esp32) is unknown_

i could not make it out why it is showing this please help

shikharuniyal on 12 Jan 2019

update: 115200/921600 works for me. need button pressed (for the borad below, it has 2 button, one is 'EN' and the other is 'Boot' so need to press 'Boot' during 'Connecting ...' in Arduino UI)

esptool.py v2.6-beta1
Serial port /dev/cu.SLAB_USBtoUART
Connecting........_____....._____....._____....._____....._____....._____.....____
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, Coding Scheme None

https://www.aliexpress.com/item/Lolin-ESP32-OLED-wemos-for-Arduino-ESP32-OLED-WiFi-Modules-Bluetooth-Dual-ESP-32-ESP-32S/32807531243.html

ypwangnexus on 13 Jan 2019

👍1

update: 115200/921600 works for me. need button pressed (for the borad below, it has 2 button, one is 'EN' and the other is 'Boot' so need to press 'Boot' during 'Connecting ...' in Arduino UI)

esptool.py v2.6-beta1
Serial port /dev/cu.SLAB_USBtoUART
Connecting........_*....._....._....._....._.....*_.....____
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, Coding Scheme None

https://www.aliexpress.com/item/Lolin-ESP32-OLED-wemos-for-Arduino-ESP32-OLED-WiFi-Modules-Bluetooth-Dual-ESP-32-ESP-32S/32807531243.html

What are the modes and buttons to press? Because I have the same card but I can not load the code...

lucabarbieri on 5 Feb 2019

for me it was a bad usb cable

sloth1 on 14 Mar 2019

Hello all, I am not sure if this will help or not but I think I might know what's going on. I have had the issue of "A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header". It turns out that for me anyways It never gets to connect to the esp32. There are two small back buttons on both sides of the micro-usb port. If you have the port facing towards you, the button to the right is the "boot" button and this is what you want to press. This will allow your computer to connect with the esp32 and should fix your problems when uploading (press this button as you are uploading your code to the esp32). The button to your left is the "EN" button and is not needed for connecting to the esp32. I hope this helps and code on!

burkettng on 7 Apr 2019

This issue was fixed for me by making sure GPIO0 was at ground low while uploading the sketch.

jschulz97 on 16 Apr 2019

You should not have to press Boot button, but while you solve the problem you can put a button, as in this image:

And test at a lower speed like me-no-dev say in the second comment.

Hi, thanks for your post, that resolved my issue on WEMOS Oled board which had microUSB connector broken but I could send the firmware via TX/RX pins.

But right now I have the same issue on a Heltec board that has a FTDI driver broken. I try to send the firmware via TX/RX and reboot it with GPIO0 on low, the board turns on waiting mode for downloading as WEMOS board:

rst:0x1 (POWERON_RESET),boot:0x7 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

but when I send the firmware I get the next error:

esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
*** [upload] Error 2

maybe do you know what I need with this Heltec Board?

I tried all solutions on this thread, GPIO0 on low with GPIO2 on low, boot button, but nothing works.

Thanks

hpsaturn on 5 May 2019

👍2

This sort of problem is nearly always connected with programming speed, try running the board at 115,200 baud

G6EJD on 5 May 2019

Hi, thanks for your response. I'm already sending to 115200, my line for upload the firmware is:

esptool.py --chip esp32 --port "/dev/ttyUSB0" --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 system/bootloader_dio_40m.bin 0x8000 system/partitions.bin 0xe000 system/boot_app0.bin 0x10000 firmware.bin

I tested with different speed but nothing works

hpsaturn on 5 May 2019

Open a command prompt and run python esptool.py chip_id to see if you have any communication with the device.

lbernstone on 5 May 2019

mmm not, it failed with this test:

./esptool.py chip_id
esptool.py v2.6-beta1
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____....._____....._____....._____....._____
/dev/ttyUSB0 failed to connect: Failed to connect to Espressif device: Timed out waiting for packet header

A fatal error occurred: All of the 1 available serial ports could not connect to a Espressif device.

But when I reboot it with boot button on serial console I get:

rst:0x1 (POWERON_RESET),boot:0x7 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

(the same message as my WEMOS board that do work)

hpsaturn on 5 May 2019

I've had this problem. It turns out to be to do with the state of the IO
pins at boot.

check IO0 and make sure this pin is either floating or pulled High.

Confirm this by trying to program the board unplugged from your hardware
(It should work) then plug in your hardware bit by bit, there will be a
point at which it fails.

There is another thread on this issue. One way to fix this involves
soldering a 0.1uF cap onto the board (in the area where EN/IO0 are
driven by the two transistors).

Gwyn Evans
Mobile Video Systems
Spitzwegstr. 10
81373 München
+491733510658

On 05/05/2019 23:14, Antonio Vanegas wrote:
>

mmm not, it failed with this test:

./esptool.py chip_id
esptool.py v2.6-beta1
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____....._____....._____....._____....._____
/dev/ttyUSB0 failed to connect: Failed to connect to Espressif device: Timed out waitingfor packet header

A fatal error occurred: All of the 1 available serial ports could not connect to a Espressif device.

But when I reboot it with boot button on serial console I get:

rst:0x1 (POWERON_RESET),boot:0x7 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waitingfor download

(the same message as my WEMOS board that do work)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/espressif/arduino-esp32/issues/333#issuecomment-489463935,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKS7IUHJ5RMMMKYYK3XGSQTPT5E2VANCNFSM4DJCJHZA.

GwynMunich on 6 May 2019

It sounds like your esp32 is not receiving the data. You can spend an hour or two troubleshooting the RX/TX connections, or you can spend <$10 to buy another board.

lbernstone on 7 May 2019

Yes, but another board take one month on arrive and also this board is very discontinued.. But I agree, maybe is another problem because the connections be very simple and with my other board, WEMOS board, this method works fine.

ok, goodbye board

hpsaturn on 9 May 2019

I had the same problem, but only with CameraWebSerwer example for esp32-cam, the solution was to install git , https://robotzero.one/heltec-wifi-kit-32/ helped me to solve it

that shall help you too
hope

nahkoy on 13 May 2019

I solved the problem on my board by doing the following sequence:

depress the reset button
depress the boot button
release the reset button
release the boot button
then initiate the upload

ichibrosan on 5 Jun 2019

👍1

Espressif should make this sequence of getting the ESP32 into UART boot mode more prominent which on most boards without an automatic reset circuit is:

Press and hold RESET
Press and release BOOT
Release the RESET
Start programming.

G6EJD on 5 Jun 2019

👍3

Thanks,

That it what I just discovered by accident.

What I don’t understand is why this is necessary whenit is not needed for uploading
in the Arduino GUI.

Douglas

--
Douglas Wade Goodall
Multiware Engineer
https://github.com/ichibrosan

On Jun 5, 2019, at 4:24 AM, G6EJD notifications@github.com wrote:

Espressif should make this sequence of getting the ESP32 into UART boot mode more prominent which on most boards without an automatic reset circuit is:

• Press and hold RESET
• Press and release BOOT
• Release the RESET
Start programming.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

ichibrosan on 5 Jun 2019

Well it is documented in the ESP32 data sheet as certain pins have to be in the correct state at reset to initiate flash boot or UART boot mode, reset alone always starts the device in flash boot mode. If your using a development board there is always a cross-connected set of logic gates sometimes comprised of two transistors the role of which is to simulate the correct settings of IO-0 and IO-2 so in effect pressing and holding reset then pressing boot and then releasing boot then reset, all this is done by the DTR line of the USB port which the IDE conveniently toggles to initiate all this thereby placing the ESP32 into UART boot mode.

G6EJD on 5 Jun 2019

"A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header"

To sort out this problem ..

when "Connecting........_____....._____....._____....._____." was start showing in IDE, press and hold "BOOT" button.

Ashim9474 on 28 Jun 2019

👍3 🎉1

Hi everyone,
I have the same problem but whit a ESP32 CAM buy here : https://fr.aliexpress.com/item/32992663411.html?spm=a2g0s.9042311.0.0.59664c4dSvjxgI

This version don't have USB port so I use FTDI . I don't understand why it's do no work, The boot mode is start correctly if i check serial

`rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

`
I use FTDI so I don't have problem whit power right ?

`Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 3c:71:bf:5a:04:64
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0x0, SizeID=0x0), defaulting to 4MB
Compressed 8192 bytes to 47...

Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 4096.0 kbit/s)...

A fatal error occurred: Timed out waiting for packet header
A fatal error occurred: Timed out waiting for packet header`

I precise that version don't have boot button just reset. But I plug GI0 and GND to gether for flash mode.
Any Idee ?
Thanks to you :)

tutur05 on 29 Jun 2019

Please don't hijack issues, particularly closed ones. You are clearly connecting to the board, but the transfer is failing. Try reducing the baud rate, or switch down to DIO/40MHz flash settings. cp2102 always seems to work better than ftdi with esp32, if you have one available.

lbernstone on 29 Jun 2019

👍1

Finally got it working!! - there were a couple of things wrong!
And - I don't need to hold down any buttons during flashing.

Board:
DOIT DEVKIT V1

Issue 1 - Drivers:
I had an old version of the drivers installed which worked with the ESP8266... this didn't seem to work with the ESP32. In Windows Device Manager I could see a warning-icon on the CP210x device under PORTS (COM & LPT).
I donwloaded the new driver from here: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

Issue 2 - COM Port:
After installing the new drivers, when I plug in the board, I can see two COM ports under Windows Device Manager and also in the Arduino IDE. You need to select the COM port in the IDE which corresponds to the _Silicon Labs CP210x USB to UART Bridge_ device in Device Manager.

Issue 3 - Power:
With the ESP32 plugged in only via USB calble, it boots up but I can't flash to it. I had the USB cable plugged in via the crappy front-IO panel on my machine..., maybe thats why...?
After I plugged the board into a breadboard power supply (almost like this one https://www.aliexpress.com/item/32815388569.html) and powered it with a 12v DC plug, and then plugged in the USB cable - then things started working.

Issue 4 - USB Cable:
Not sure if this is a 100% cause but it cetrainly contributes:
I have 2 USB micro cables here - a thin one and a thick one. After solving steps 1-3 above I can use both cables to flash (without needing to hold down any buttons), but with the thin cable, flashing is much slower, and the "connecting...." phase takes much longer... almost like it won't work...
Make sure you have a _good_, not just a _working_ cable.

rudolf81 on 6 Jul 2019

I had the same problem.
After disconnecting the GPIO2 it works well.

Dutchman2 on 3 Sep 2019

Hi, from the solution on the webpage https://randomnerdtutorials.com/solved-failed-to-connect-to-esp32-timed-out-waiting-for-packet-header/

There is a problem on resetting the chip after finished programming.

I’ve solved the problem by adding one more resistor in series with the capacitor as shown in the diagram :

EN pin ---- R 2.2kOhm ---- (-) C 10uF (+) ----- 3.3V pin

It works both programming and resetting the chip.

koson on 9 Sep 2019

👍2

I found my problem was with the USB port on my laptop. If I use a USB 3.0 cable (USB-A -> USB 3) in the USB 2.0 port, I get the exact error messages above. When I moved the cable to the USB 3.0 port it worked just fine. I didn't realize my laptop had a single 2.0 port which is the one I naturally use due to it's location. As I understand, it should have worked with the USB 2.0 port, but it does not on my laptop either due to the cable or the port. Hope this helps someone.

gpratt3151 on 21 Sep 2019

Just make sure whether following conditions meet,

Check if GPIO 0(IO0)) is connected with Ground(gnd),
Press & Hold rst button when you are uploading the code,
In my case, I had connected 5V output instead of 3 .3V output.

mehtaSmitK on 22 Sep 2019

👍1

Hi, from the solution on the webpage https://randomnerdtutorials.com/solved-failed-to-connect-to-esp32-timed-out-waiting-for-packet-header/

There is a problem on resetting the chip after finished programming.

I’ve solved the problem by adding one more resistor in series with the capacitor as shown in the diagram :

EN pin ---- R 2.2kOhm ---- (-) C 10uF (+) ----- 3.3V pin

It works both programming and resetting the chip.

Great Solution!
I also applied upper linked solution.
After connecting your solution(EN pin ---- R 2.2kOhm ---- (-) C 10uF (+) ----- 3.3V pin) it works.
Thank you so much! :-)

hik9175 on 27 Nov 2019

Sharing my experience:
I'm seeing the same issue with ESP-Eye(has ESP32). Initially, I programmed the board using my laptop USB port. I could see the Hello World app output in the serial port.

When I try to flash the board again, it won't let me do it. I'm getting the same error as posted in this thread:

Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header
esptool.py failed with exit code 2

Using external power supply is not an option for me. I accidentally got it working by repeatedly pressing the boot button when the terminal output showed Connecting........______ once. I tried holding flash and boot buttons in all possible configurations mentioned in this post but I was unable to program it. No luck at the end. Still searching...

dheerajdake on 7 Dec 2019

Most likely a poor quality usb cable. Try another (different make) cable and see if the problem persists.

G6EJD on 7 Dec 2019

It's definitely not USB cable issue. I've tried 3 cables at this point. When the terminal shows Connecting......._______ in the serial output, the device is restarting several times instead of going into boot mode. There is something which is preventing the ESP32 from entering boot mode. I also tried to keep the ESP32 manually into boot mode. Couldn't get it to work.

I raised an issue on ESP EYE forum. Here's the link:
https://github.com/espressif/esp-who/issues/125

dheerajdake on 7 Dec 2019

The following happened to me: connect my esp32 and you can turn on a LED through your own server, also connect a potentiometer to read it to me on the serial monitor and it did it perfectly.
The problems started when I wanted to connect to the thinger.io platform where I could not appear as connected (the code did not mark me any error, all right, just that I do not appreciate conceded). So start testing in different ways, including other libraries, etc. Until in a moment I skip this error we are all talking about "A fatal error occurred: Timed out waiting for packet header"
Also try the solutions they said about changing the USB cable port and using the "RESET" and "BOOT" buttons

Arduino: 1.8.7 (Windows 10), Card: "NodeMCU-32S, 80MHz, 115200"

The Sketch uses 640718 bytes (48%) of the program storage space. The maximum is 1310720 bytes.
Global variables use 38816 bytes (11%) of dynamic memory, leaving 288864 bytes for local variables. The maximum is 327680 bytes.
esptool.py v2.6
Serial port COM3
Connecting ........_
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 3c: 71: bf: f0: ae: b8
Uploading stub ...
Running stub ...
Stub running ...
Configuring flash size ...
Auto-detected Flash size: 4MB
Compressed 8192 bytes to 47 ...

Writing at 0x0000e000 ... (100%)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 4096.0 kbit / s) ...
Hash of data verified.
Compressed 15856 bytes to 10276 ...

Writing at 0x00001000 ... (100%)
Wrote 15856 bytes (10276 compressed) at 0x00001000 in 0.9 seconds (effective 137.6 kbit / s) ...
Hash of data verified.
Compressed 640832 bytes to 384168 ...

Writing at 0x00010000 ... (4%)
Writing at 0x00014000 ... (8%)
A fatal error occurred: Timed out waiting for packet header
A fatal error occurred: Timed out waiting for packet heade

NicoLoiacono on 22 Dec 2019

New to this Sport. When trying to flash this is the error I get. When I check the dir there is no file in either the dir or the zip for the dir.

I am using the ESP-WROOM-32 with Arduino 1.8.10 IDE

Sketch uses 207721 bytes (15%) of program storage space. Maximum is 1310720 bytes.
Global variables use 15228 bytes (4%) of dynamic memory, leaving 312452 bytes for local variables. Maximum is 327680 bytes.
esptool.py v2.6
Serial port COM3
Connecting........_____....._____....._____....._____....._____....._____.....____An error occurred while uploading the sketch

Invalid library found in C:\ProgramLang\Arduino\hardware\espressif\esp32\libraries\AzureIoT: no headers files (.h) found

Any ideas?

Thank you, Mark

MarkAdams-MOS on 29 Dec 2019

Have you installed both ESP 8266 and 32 extensions for the Arduino IDE?

G6EJD on 29 Dec 2019

👍1

I installed AzureloThub and was able to get past the error. I am able to flash the esp32 and run my script . Thank you for the quick answer.

MarkAdams-MOS on 29 Dec 2019

I had the same problem, but it has been solved when i removed the load from D8 Pin...After removing i tried to upload it again.. yeeahh... it got uploaded...!

frizbug on 14 Jan 2020

👍1

Thank you I got it working.

MarkAdams-MOS on 15 Jan 2020

Same error with AZDelivery ESP32 and Arduino 1.8.11 on Windows 10
As pointed somewhere, updated the CP210x driver (driver date as 2016) and new date is 20/06/2019 (ver 10.1.8.2466).
All works fine now ;-)

inakigarm on 13 Mar 2020

bonjour
j utilise un arduino relier en usb et esp-32 cam
dans mon Url de carte supplémentaire j ai ajouter : https://dl.espressif.com/dl/package_esp32_index.json
ds le gestionnaire carte j ai ajouter ensuite esp32 et installer
type de carte esp32wover module
partition sheme HUGE APP (53MB No OTA/1MB SPIFFS)
exemple=> esp32 camera =>camera web sever

quand je compile voici mon erreur

esptool.py v2.6
Serial port COM3
Connecting........_____....._____....._____....._____....._____....._____....._____

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

je ne sais pas quoi faire pour résoudre mon problème

stef-mik on 29 Apr 2020

"A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header"

To sort out this problem ..

when "Connecting........_*....._....._.....*_." was start showing in IDE, press and hold "BOOT" button.

This solved the issue for me! Thanks, @Ashim9474 !

PS: This was using this board: https://archive.is/uezG8

DurvalMenezes on 8 May 2020

👍1

Just leaving my feedback here that it can definitely be a USB cable issue. Replacing my worn down old kindle charger cable with a newer phone charger micro usb cable did the trick.

justinkb on 7 Jul 2020

👍1

Arduino-esp32: A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header

Most helpful comment

All 194 comments

In my case the problem was in some way caused by level shifter that was floating on HV side (nothing connected) and that prevented DOIT ESP32 DEVKIT V1 from flashin with that error

Related issues