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

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

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

Postby ESP_Angus » Tue Oct 18, 2016 10:33 pm

hydrabus wrote:I have done some Sigrok (PulseView) capture of the signals (tested with Windows7)
Thanks hydrabus. That's interesting, your IO0 delay is closer to 2ms than the 4ms I was seeing. But same pattern.
hydrabus wrote:

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)
Nice work rudi for figuring this one out. However, it's quite strange that this works - when both RTS & DTR are asserted on the Core board it should actually set EN & IO0 high not low. The reason for this is so that normal serial programs (which assert RTS & DTR by default) don't hold the board in reset - it should only pull EN or IO0 low if DTR or RTS is asserted, not when both are.

User avatar
hydrabus
Posts: 29
Joined: Wed Nov 25, 2015 11:45 pm
Location: France
Contact:

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

Postby hydrabus » Thu Oct 20, 2016 9:57 pm

I have done some analysis on this download mode and I think I have found the best alternative (as anyway the hardware have a problem with glitch which avoid to enter directly in download boot mode) to fix it on both Windows & Linux (and probably also MacOS ...)

My solution is to replace
esptool.py from

Code: Select all

            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) # EN=0 and IO0=0
            time.sleep(0.05)
            self._port.setRTS(False) # EN=1 and IO0=1(glitch on IO0 during 1ms)
            self._port.setDTR(True)  # EN=1 and IO0=0
For more details see:
https://github.com/themadinventor/espto ... -255232523

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

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

Postby ESP_Angus » Sun Oct 23, 2016 11:11 pm

Unfortunately, the fixes reported by hydrabus & rudi rely on a silicon bug (the chip resets twice following a power on reset) which has been fixed in the forthcoming next silicon revision of the ESP32.

Also, the timing of the two signals (and the IO0 "glitch") appears to be a Windows driver level behaviour, we can't work around it in software.

The only long term fix I know is a hardware fix:

Add a 1uF capacitor (values in the range 470nF-2.2uF are probably suitable) between EN and GND. This can be done on the PCB or externally on a breadboard. The rising edge of EN is slowed to the point where it misses the "race" with the IO0 glitch.

More details in the github issue: https://github.com/themadinventor/esptool/issues/136

(Note this auto-reset bug only applies on Windows, using hardware the uses the "NodeMCU style reset circuit" - all currently released ESP32 dev boards use this reset circuit.)

MartyMacGyver
Posts: 56
Joined: Sun Dec 18, 2016 9:17 pm

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

Postby MartyMacGyver » Mon Jan 23, 2017 7:29 am

ESP_Angus wrote:Unfortunately, the fixes reported by hydrabus & rudi rely on a silicon bug (the chip resets twice following a power on reset) which has been fixed in the forthcoming next silicon revision of the ESP32.

Also, the timing of the two signals (and the IO0 "glitch") appears to be a Windows driver level behaviour, we can't work around it in software.
I may have found a fix that works with both old and current silicon (edit: as in, it should work equally well with either). More details here:
https://github.com/espressif/esptool/is ... -274413187

It doesn't depend on any special functionality, just a longer (2 second) delay at a different step in the negotiation process.

Who is online

Users browsing this forum: Baidu [Spider] and 123 guests