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

[croisez]

NB: I introduced same issue report at espressif/esptool, because I don't know actually where the problem could be: espressif/esptool#198

Hello ESP32 lovers,
I am facing a problem with a WEMS ESP32 dev board which I bough on Aliexpress very recently:
https://fr.aliexpress.com/item/ESP32-Development-Board-WiFi-Bluetooth-Ultra-Low-Power-Consumption-Dual-Cores-ESP-32-ESP-32S-Board/32801337284.html

I am able to flash it using Eclipse/esp-idf/xtensa-esp32-elf triplet. The /dev/tty.SLAB_USBtoUART device configured by "make menuconfig" makes the flashing process a success. Further on, my user application (one of the examples of esp-idf) starts and does what expected.

But, with Arduino IDE, this is not the same story. I have installed the toolchain as written at ESP32-Arduino github page, then selected "ESP32 dev module" as the board in Arduino IDE, and also selected /dev/tty.SLAB_USBtoUART as the flashing device.
Like I did for the Eclipse case, I reset dev board with RST and BOOT buttons. I verified to get the "DOWNLOAD" invite on the terminal, then closed the terminal pushed on flash button of Arduino IDE. All I get in Arduino logs is the following:

Sketch uses 118,890 bytes (11%) 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 921600 --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_538507/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_538507/Blink.ino.bin 

esptool.py v2.0-beta
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

The programming does not detect the dev board in download mode, and the flashing does not start.
As a workaround, I hooked up an external FTDI adapter cable directly to the ESP32, and then Arduino IDE is able to start the flashing. But after, the Arduino sketch does not seems to run. My simple Blink sketch is not running (it toggles a GPIO and prints some text on Serial console).

Issue 1: I saw a post about the problem of the FreeRTOS scheduler not started on Core1, or not enabled Core1, which could resolve the Arduino sketch not running (but I don't know how to configure it within ESP32-Arduino libraries/board from inside Arduino IDE. Could it be a efuse which should be reset to enable Core1 to start?

Issue 2: Concerning my flashing issue, I don't understand why my dev module can be successfully programmed by using the Makefile from within Eclipse/esp-idf, while it ends-up with a timeout from within ArduinoIDE/ESP32-Arduino toolchain.

Anyone could help me about my two issues?
Thank you so much.

[me-no-dev]

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.

[croisez]

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]

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.

[me-no-dev]

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...

[croisez]

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]

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]

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.

[architmuchhal12]

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)

[lrmoreno007]

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.

[architmuchhal12]

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!

[lrmoreno007]

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.

[kp372]

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.

[fededim]

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).