ESP32 Forum

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.

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.

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 to For more details see:
https://github.com/themadinventor/espto ... -255232523

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

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.