A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')

[hydrabus]

About your question:
If you put the board in download mode first using buttons does it ever fail?

It seems it always works when just plugged / powered on (so yes it seems to be software bug maybe in python script of in the code injected/executed by ESP32 ...).
I just want to know if the issue I describe when doing multiple command(without power off / power on) work for other board or you have same issue as me ? (which will confirm I do not have a strange board ...)

Just an update I have found a workaround to the random connection problem if I keep "Boot" button pressed esptool.py always works (even on Win7)

[WiFive]

Just an update I have found a workaround to the random connection problem if I keep "Boot" button pressed esptool.py always works (even on Win7)

That is the workaround for v1 boards with hardware bug, are you sure you have v2?

[hydrabus]

Just an update I have found a workaround to the random connection problem if I keep "Boot" button pressed esptool.py always works (even on Win7)

That is the workaround for v1 boards with hardware bug, are you sure you have v2?

Yes I have a v2 as it is wrote on the board on the back ESP32_Core_board_V2 from AdaFruit (it is a black board not like on photo on Adafruit)
Do you have a schematic / gerber of the v2 to check ?

[analoglamb]

aggressive and annoying advertising .jpg

The V1 (blue PCB) DevKitC boards have a bug with the auto-reset circuit where it doesn't work reliably. You need to hold down the "Boot" button (J3, pulls down IO0) in order to reliably enter the bootloader. V2 (black PCB, "ESP32_Core_Board_V2" marked on bottom) DevKitC does not have this problem.

Thank you very much.
Can you send me ESP32_Core_Board_V2 schematic? 1814830468@qq.com

Thanks again

hi
please guy, Your advertising is very aggressive and annoying.
hope you understand my posting very well meaned.

best wishes
rudi

OK， I will delete it. Thanks for your feedback.

[analoglamb]

About your question:
If you put the board in download mode first using buttons does it ever fail?

It seems it always works when just plugged / powered on (so yes it seems to be software bug maybe in python script of in the code injected/executed by ESP32 ...).
I just want to know if the issue I describe when doing multiple command(without power off / power on) work for other board or you have same issue as me ? (which will confirm I do not have a strange board ...)

Just an update I have found a workaround to the random connection problem if I keep "Boot" button pressed esptool.py always works (even on Win7)

Yes

[ESP_Angus]

Just an update I have found a workaround to the random connection problem if I keep "Boot" button pressed esptool.py always works (even on Win7)

Thanks for reporting this, hydrabus. I have reproduced this issue on Windows 7 with a v2 core board. On Windows there is a 4ms delay between when "EN" goes high and when "IO0" goes low. This is caused by the way the auto-reset circuit is wired, to keep compatibility with "normal" serial programs (there is a small table in the schematic that shows how DTR/RTS control lines related to the EN/IO0 pins). The value of "IO0" seems to be being read/latched during this 4ms period.

I think on ESP8266 the startup time was slightly slower so this 4ms delay had already ended when the pin value was read.

I don't see an easy fix for this because of the way pyserial handles DTR/RTS on Windows - the two pin changes go out to the device in separate requests. I'll keep thinking about it.

In the meantime, holding down the BOOT button is a reliable workaround.

Thank you very much.
Can you send me ESP32_Core_Board_V2 schematic?

You can find the V2 schematic PDF in this thread.

The bug with the V1 boards was caused by the pinout of Q1 & Q2 being wrong on the PCB. There may have been other changes between V1 and V2, though.

[analoglamb]

Just an update I have found a workaround to the random connection problem if I keep "Boot" button pressed esptool.py always works (even on Win7)

Thanks for reporting this, hydrabus. I have reproduced this issue on Windows 7 with a v2 core board. On Windows there is a 4ms delay between when "EN" goes high and when "IO0" goes low. This is caused by the way the auto-reset circuit is wired, to keep compatibility with "normal" serial programs (there is a small table in the schematic that shows how DTR/RTS control lines related to the EN/IO0 pins). The value of "IO0" seems to be being read/latched during this 4ms period.

I think on ESP8266 the startup time was slightly slower so this 4ms delay had already ended when the pin value was read.

I don't see an easy fix for this because of the way pyserial handles DTR/RTS on Windows - the two pin changes go out to the device in separate requests. I'll keep thinking about it.

In the meantime, holding down the BOOT button is a reliable workaround.

Thank you very much.
Can you send me ESP32_Core_Board_V2 schematic?

You can find the V2 schematic PDF in this thread.

The bug with the V1 boards was caused by the pinout of Q1 & Q2 being wrong on the PCB. There may have been other changes between V1 and V2, though.

You mean that we need to press BOOT button when download firmware with V2 Board. Is it right?

[ESP_Angus]

You mean that we need to press BOOT button when download firmware with V2 Board. Is it right?

Yes: If using esptool.py on Windows and the automatic reset doesn't work.

[hydrabus]

I have done some Sigrok (PulseView) capture of the signals (tested with Windows7)

esp32_after_boot_win7_esptool_py_flash_id_KO:
This screenshot corresponds to automatic boot by esptool.py (with parameter flash_id) which fail
Root cause SPI Boot mode (IO0 high) instead of UART0 Download mode(IO0 low)
For more details you can download Sigrok file here:
http://hydrabus.com/esp32_boot/esp32_af ... h_id_KO.sr

esp32_after_boot_win7_esptool_py_flash_id_KO.png (132.51 KiB) Viewed 28688 times

Corresponds to UART decoded data (extracted from sigrok capture):

Code: Select all

sigrok-cli -i ../esp32_after_boot_win7_esptool_py_flash_id_KO.sr -P uart:rx=0_UART_RX:tx=1_UART_TX:baudrate=115200:format=hex -A uart=tx-data -O hex:width=128 > ../esp32_after_boot_win7_esptool_py_flash_id_KO.txt

Result (of sigrok-cli Ascii Hex converted to binary):

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_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:2
load:0x3ffc0000,len:0
load:0x3ffc0000,len:3028
ho 0 tail 12 room 4
load:0x40078000,len:4092
load:0x40098000,len:704
entry 0x400981dc
...
and so on
...

esp32_after_boot_Keep_Boot_IO0_Pressed_win7_esptool_py_flash_id_OK:
This screenshot corresponds to forced UART0 Download mode(IO0 low) button Boot always pressed and use of esptool.py (with parameter flash_id) which work fine
For more details you can download Sigrok file here:
http://hydrabus.com/esp32_boot/esp32_af ... h_id_OK.sr

esp32_after_boot_Keep_Boot_IO0_Pressed_win7_esptool_py_flash_id_OK.png (182.86 KiB) Viewed 28688 times

Corresponds to UART decoded data (extracted from sigrok capture):

Code: Select all

sigrok-cli -i ../esp32_after_boot_Keep_Boot_IO0_Pressed_win7_esptool_py_flash_id_OK.sr -P uart:rx=0_UART_RX:tx=1_UART_TX:baudrate=115200:format=hex -A uart=tx-data -O hex:width=128 > ../esp32_after_boot_Keep_Boot_IO0_Pressed_win7_esptool_py_flash_id_OK.txt

Result (of sigrok-cli Ascii Hex converted to binary):

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
ets Jun  8 2016 00:22:57

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

I also confirm that by modifying esptool.py
from

Code: Select all

            self._port.setDTR(False)
            self._port.setRTS(True)
            time.sleep(0.05)
            self._port.setDTR(True)
            self._port.setRTS(False)
            time.sleep(0.05)
            self._port.setDTR(False)

to

Code: Select all

            self._port.setDTR(False)    # GPIO0 -> 1
            self._port.setRTS(True  )   # RST -> 0
            self._port.setDTR(True  )   # GPIO0 -> 0
            time.sleep(0.05)
            self._port.setRTS(False )   # RST -> 1
            time.sleep(0.1) 

That fix the problem on win7 (thanks to rudi post http://esp32.com/viewtopic.php?f=13&p=1512#p1512)

[rudi ;-)]

https://github.com/themadinventor/espto ... ol.py#L278

change the lines

Code: Select all

            self._port.setDTR(False)
            self._port.setRTS(True)
            time.sleep(0.05)
            self._port.setDTR(True)
            self._port.setRTS(False)
            time.sleep(0.05)
            self._port.setDTR(False)

to this

Code: Select all

## workaround....still as workaround
## 15 Oktober 2016 rudi ;-)
            self._port.setDTR(False)    # GPIO0 -> 1
            self._port.setRTS(True  )   # RST -> 0
            self._port.setDTR(True  )   # GPIO0 -> 0
            time.sleep(0.05)
            self._port.setRTS(False )   # RST -> 1
            time.sleep(0.1) 
#   end workaround ...still as workarround

and you go on with auto flash in

-> Developer V2
-> Nano32
-> ...

you find the esptool.py here

fix_esptool_py.png (97.83 KiB) Viewed 28685 times

best wishes
rudi