failed to connect to ESP32: timeout waiting for packet header

[shivam5594]

• Operating system: Windows 10
• Python version: (python -V to check this) 3.7.0
• ESP hardware in use: esp32 Using Arduino IDE for prototyping purpose.

Full output from esptool.py

Archiving built core (caching) in: C:\Users\schauhan\AppData\Local\Temp\arduino_cache_150265\core\core_espressif_esp32_esp32_PartitionScheme_default,FlashMode_dio,FlashFreq_80,FlashSize_4M,UploadSpeed_115200,DebugLevel_infoea8546689b3bf5c2088efcf789d8012e.a Sketch uses 165513 bytes (12%) of program storage space. Maximum is 1310720 bytes. Global variables use 11224 bytes (3%) of dynamic memory, leaving 283688 bytes for local variables. Maximum is 294912 bytes. esptool.py v2.3.1 Connecting........____.............................................___An error occurred while uploading the sketch

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

What is the expected behaviour?

• Output of ESP32 which gets programmed easily via Arduino IDE.

• Output of my prototype when I am using external controller as a USB to UART converter to get ESP32 in boot mode.

Extra information

• Problem is when Arduino tries to program it the the data it sends is 192 0 8 $ 0 0 0 0 0 7 7 18 SPACE U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U 192

and gets reply like

192 1 8 4 0 7 18 SPACE U 0 0 0 0 192 192 1 8 4 0 7 18 SPACE U 0 0 0 0 192 192 1 8 4 0 7 18 SPACE U 0 0 0 0 192 192 1 8 4 0 7 18 SPACE U 0 0 0 0 192 192 1 8 4 0 7 18 SPACE U 0 0 0 0 192 192 1 8 4 0 7 18 SPACE U 0 0 0 0 192 192 1 8 4 0 7 18 SPACE U 0 0 0 0 192 192 1 8 4 0 7 18 SPACE U 0 0 0 0 192

But when I try with external controller I get this response for exactly same command

192 1 8 4 0 18 SPACE U U 0 0 0 0 192 192 1 8 4 0 18 SPACE U U 0 0 0 0 192 192 1 8 4 0 18 SPACE U U 0 0 0 0 192 192 1 8 4 0 18 SPACE U U 0 0 0 0 192 192 1 8 4 0 18 SPACE U U 0 0 0 0 192 192 1 8 4 0 18 SPACE U U 0 0 0 0 192 192 1 8 4 0 18 SPACE U U 0 0 0 0 192 192 1 8 4 0 18 SPACE U U 0 0 0 0 192

In short I don't get the number 7 but instead I get extra U after SPACE. As you can see in first image it later start writing to flash but that doesn't happen to my setup.

The entire trace is here.

op.txt

Does anyone know why this happens? the second controller is being run on 3.3V and also all the control signals for EN and IO_0 from that are 3.3V.

[shivam5594]

I have updated this with trace of flashing op.txt . this has the trace of my setup which is not working.

[projectgus]

Hi @shivam5594,

Can you give some more details about your custom hardware setup, please? A schematic and/or a photo would be the best.

To reword what you have given above in terms of the "--trace" log, a correct sync response from an ESP32 should look like this:

TRACE +0.000 Full packet: b'\x01\x08\x04\x00\x07\x12 U\x00\x00\x00\x00'

The responses in the attached trace log are varied, but the longest is this:

TRACE +0.000 Full packet: b'\x01\x08\x04\x07\x07\x12 '

With lots of variations where some other bytes in that sequence are randomly missing. This makes me think there is one of:

• Physical signal integrity problem with the connection between the USB/serial chip and the ESP32, causing it to see framing errors (corrupt data on the wire) and drop those bytes.
  • You can try passing esptool.py -b 9600 ... to sync at a much lower baud rate, and see if this helps.
  • Does the Saleae logic analyzer software report any framing errors?
  • Do you have an oscilloscope you can use to look at the serial traffic as an analog signal?
• Some driver problem is causing the USB/serial chip to drop bytes. I've never seen this before, but you haven't said what hardware you're using - if it's something very unusual then this might explain it.

BTW, small tip, if you update esptool to v2.4.1 then the --trace output is much more readable in this newest version. :)

[shivam5594]

Hi @projectgus ,

• I have updated my esptool.py to 2.4.1 and python to 2.7.15 .

• I tried to erase_flash at 9600 baud rate and here its trace output and logic analyzer capture. My logic analyzer isn't giving any framing error at 115200 baud either.

---------> op.txt

• I am using PSoC5 in CDC USB mode to convert USB signals to USB. It doesn't give out the DTR and RTS signals as esptool.py should do for automatic bootloading mode, but that part is taken care of by hard coding the GPIO pins.

[projectgus]

Hi @shivam5594 ,

It seems like the unusual factor is the USB/serial converter.

If you check the logic analyzer captures, do you see the exact same bytes for RX/TX that you see in the trace log from esptool?

[shivam5594]

Hi @projectgus

• I think it is same but still I have attached both files here.
• Even I suspect it is USB/serial converter. Because I am using the original ESP32_core_V2 board (Not a cheaper copy) and also connections and boot mode selection working fine.

Output Files

• Trace op.txt

• Logic Analyzer op_analyzer_tx.pdf

[shivam5594]

If anyone has worked with PSoC5 CDC usb to uart and successfully gets esp32 in download mode.. Please let me know.

TIA

[projectgus]

I think it is same but still I have attached both files here.

It's hard to read in a PDF format, but it seems like a lot of data is being lost in the conversion to USB.

ie the sync response on the "TX" capture in op_analyzer_tx.pdf is this:

'192' (0xc0)
'1'
'8'
'4'
'0'
'7'
'7'
'18' (0x12)
U (0x55)
'0'
'0'
'0'
'0'
'192' (0xc0)

(Hex annotations by me)

And all of the responses in the "TX" side of the capture seem to be this exact sequence of bytes, repeated. This is a correct sync response from the ESP32.

However, the esptool.py trace output in op.txt says it receives the following bytes over USB:

TRACE +0.000 Read 1 bytes: b'\xc0'
TRACE +0.000 Read 1 bytes: b'\x01'
TRACE +0.000 Read 1 bytes: b'\x07'
TRACE +0.000 Read 1 bytes: b'\x07'
TRACE +0.000 Read 1 bytes: b'\x12'
TRACE +0.000 Read 1 bytes: b'\xc0'
TRACE +0.000 Full packet: b'\x01\x07\x07\x12'

(And different random variations of this.)

This is not the same sequence of bytes. All of these individual single bytes are present in the TX capture, but a lot of other bytes have been lost somewhere. Hence, esptool can't parse the response.

I'm going to close this as it seems to be a bug in the PSoC5 USB to UART firmware running on the chip. Suggest connecting the PSoC5 to something else (like a different USB/serial chip) and doing some tests in a serial program until it can loop data back without dropping bytes. (Note that manually typing characters in a terminal program may not be enough to test it, you need to try and send bytes via the interface at the maximum speed allowed by the baud rate.)

Angus