ESP32 Reset To Bootloader Issues on Windows (ESPTOOL-386)

[negativekelvin]

On windows, it seems like there are timing issues with the reset to bootloader functions using the DTR and RTS circuit for esp32 because setDTR and setRTS are sent separately. Possible fix:

            # issue reset-to-bootloader:
            # RTS = either CH_PD or nRESET (both active low = chip in reset)
            # DTR = GPIO0 (active low = boot to flasher)
            self._port._dtr_state = False
            self._port._rts_state = True
            self._port._reconfigure_port()
            time.sleep(0.05)
            self._port._dtr_state = True
            self._port._rts_state = False
            self._port._reconfigure_port()
            time.sleep(0.05)
            self._port.setDTR(False)

I haven't scoped this or tested it because my v1 board has the transistor bug.

[projectgus]

Thanks @negativekelvin. I don't know if you're following the forum thread, but I'm guessing you are.
http://esp32.com/viewtopic.php?f=2&t=334&p=1503#p1497

I considered this solution as well (although I didn't test it either.) The problem is, I'm not comfortable relying on the private interface of pyserial. At minimum, it's necessary to check it hasn't changed over any previous supported pyserial versions. But even if it works with all those, if the private interface changes in the future then it could break esptool without warning.

A hacky but somewhat safer way would be to check all these properties exist with hasattr() before calling them, and fail back to the public API instead. But this is still super hacky.

The safest, most maintainable, fix that I can think of is probably to call the win32 GetCommState/SetCommState API functions directly. This is a stable public API, and the only private part of pyserial it needs to touch is the port handle. I still don't like that idea, but it seems least likely to suddenly break.

[projectgus]

Or to submit a patch to pyserial, some variant of the existing apply_settings() that applies all settings as an "atomic" operation.

[negativekelvin]

Yes, that makes sense. I don't know if those properties and methods are very likely to change, so yes I like the check and fall back strategy until pyserial can support it.

[negativekelvin]

However it also looks like _reconfigure_port() only updates the RTS/DTR lines on windows, not other platforms. So would have to add a platform check before calling.

[bvernoux]

For full details on this issue I have done a full analysis of the problem on Win7 see
http://esp32.com/viewtopic.php?f=2&p=1511#p1511

I also confirm that by modifying esptool.py
from

            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

            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)

[bvernoux]

In fact after analysis of rudi patch it is pure luck (thanks to watchdog and glitch on EN signal)
For more details on Rudi patch see Saleae Logic 1.2.10 capture:

• RudiPatch Saleae Capture
• See screenshot:
  

I have simplified it like that
esptool.py modifications (MyPatch):
from

            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

            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

The main problem is the glitch on IO0 during 1.1ms which does not allow to enter download mode as IO0 is sampled by ESP32 during this glitch but we are lucky that we have a reset by watchdog after 0.385s (with message RTCWDT_RTC_RESET) which then boot in download mode because EN=1 and IO0=0

For more details see Saleae Logic 1.2.10 capture of MyPatch:

• MyPatch Saleae Capture
• See screenshot:
  

For information MyPatch is a bit faster (300ms) compared to Rudi version and keep EN to 0 during at least 50ms(and not 3.5ms like Rudi which in fact is a glitch) and after multiple test my patch never fail with Win7 64bits and also under VirtualBox with Xubuntu 14.04
If other can give feedback it will be great

[negativekelvin]

@bvernoux are you able to capture the waveforms for the method using reconfigure_port in the first post on windows?

[projectgus]

I just tried a different fix for this issue (1f5d9d2) which should be equivalent to calling _reconfigure_port, and I thought would definitely correct the issue.

Unfortunately the timing seems to be the same (trace attached), even when both DTR & RTS are set in the same Windows API call. Which I think means the CP2102 Windows driver is doing this, and there's no way to change that pulse in software.

[negativekelvin]

That is disappointing. Time to ask silicon labs?

[negativekelvin]

we are lucky that we have a reset by watchdog after 0.385s

What is the cause of this?

[projectgus]

we are lucky that we have a reset by watchdog after 0.385s
What is the cause of this?

It's a silicon bug, that will be fixed at some point.

A solution that seems to work reliably is to add a ~2.2uF capacitor (I think 470nF-2.2uF range should be suitable) to the EN pin (between EN and GND), so it rises slower (there is a ~12K pullup on this pin.) This is not super desirable, as it requires a hardware change, but it works.

[bvernoux]

I confirm adding a 2.2uF capacitor on EN (connected between EN and GND) fix the problem