A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
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)
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)
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
That is the workaround for v1 boards with hardware bug, are you sure you have v2?hydrabus wrote: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)
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
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)WiFive wrote:That is the workaround for v1 boards with hardware bug, are you sure you have v2?hydrabus wrote: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)
Do you have a schematic / gerber of the v2 to check ?
-
- Posts: 25
- Joined: Thu Oct 13, 2016 5:53 am
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
OK, I will delete it. Thanks for your feedback.rudi ;-) wrote:hianaloglamb wrote:ESP_Angus wrote: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
please guy, Your advertising is very aggressive and annoying.
hope you understand my posting very well meaned.
best wishes
rudi
ESP32 Chip, Module, Development board! Go: http://analoglamb.com/shop/esp32
-
- Posts: 25
- Joined: Thu Oct 13, 2016 5:53 am
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
Yeshydrabus wrote: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)
ESP32 Chip, Module, Development board! Go: http://analoglamb.com/shop/esp32
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
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.hydrabus wrote: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)
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.
You can find the V2 schematic PDF in this thread.analoglamb wrote: Thank you very much.
Can you send me ESP32_Core_Board_V2 schematic?
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.
-
- Posts: 25
- Joined: Thu Oct 13, 2016 5:53 am
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
You mean that we need to press BOOT button when download firmware with V2 Board. Is it right?ESP_Angus wrote: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.hydrabus wrote: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)
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.
You can find the V2 schematic PDF in this thread.analoglamb wrote: Thank you very much.
Can you send me ESP32_Core_Board_V2 schematic?
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.
ESP32 Chip, Module, Development board! Go: http://analoglamb.com/shop/esp32
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
Yes: If using esptool.py on Windows and the automatic reset doesn't work.analoglamb wrote: You mean that we need to press BOOT button when download firmware with V2 Board. Is it right?
Re: A fatal error occurred: Failed to connect to ESP32: Invalid head of packet ('p')
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 Corresponds to UART decoded data (extracted from sigrok capture):
Result (of sigrok-cli Ascii Hex converted to binary):
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 Corresponds to UART decoded data (extracted from sigrok capture):
Result (of sigrok-cli Ascii Hex converted to binary):
I also confirm that by modifying esptool.py
from
to
That fix the problem on win7 (thanks to rudi post http://esp32.com/viewtopic.php?f=13&p=1512#p1512)
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 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
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
...
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 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
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
À
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)
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)
auto flash not work - workaround for esptool.py
https://github.com/themadinventor/espto ... ol.py#L278
change the lines
to this
and you go on with auto flash in
-> Developer V2
-> Nano32
-> ...
you find the esptool.py here
best wishes
rudi
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)
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
-> Developer V2
-> Nano32
-> ...
you find the esptool.py here
best wishes
rudi
- Attachments
-
- esptool_py_auto_flash.jpg (229.46 KiB) Viewed 28576 times
-------------------------------------
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
love it, change it or leave it.
-------------------------------------
問候飛出去的朋友遍全球魯迪
Who is online
Users browsing this forum: No registered users and 274 guests