Auto program Boot Flasher is still mysterious!

[FluxGS]

Hello all and thank you for reading.
I have searched and read all of the related internet posts regarding the ESP32 flashing mode which should be automatically entered using a usb serial interface on the development boards Rover and Dev Kit C.
Each of these boards employ a resistor / transistor bridge circuit from DTR and RTS to properly toggle the ESP32 EN and IO0.

While both of my development boards work just fine, I believe the logic to this circuit has some real mysteries and is not reliable.

I have build a board design with this exact circuit, as exampled in the dev kit schematics:
DTR -> 12Kohm -> Base Q1
RTS -> 12Kohm -> Base Q2

EN -> Collector Q1
IO0 -> Emitter Q2

Emitter Q1 -> RTS
Collecter Q2 -> DTR

There is a logic table provided in the schematic
Auto Program
DTR RTS -> EN IO0
1 1 1 1
0 0 1 1
1 0 0 1
0 1 1 0


OK, here is the MYSTERY!
My understanding to enter serial flash upload mode, IO0 is held low, EN is pulsed low, then IO0 is brought high.
This circuit does not allow for a DTR RTS combination which will pulse EN low while holding IO0 low.
My understanding of the required timing:
IO0 ''''''''''''''''\.........................../''''''''''''''''''''''''''
EN ''''''''''''''''''''''''''''''''''''''''''\...../'''''''''''''''''''''''''''''''''''''''''''
^ Serial Upload ready

The circuit does not allow for both IO0 and EN to be low at the same time.
I think it works because there is a capacitor on EN which my hold it low long enough to get the IO0 pulse coincident.

I have build 40 boards with this circuit using the 12K ohm and S8050 transistors as called out. I have 5Kohm pull down on IO2 and a 12Kohm pull up on EN.

On 40 boards, about 2/3 work from the USB, the reset need me to manually assist with the flasher BOOT / EN buttons which are also on my board design.

This flaky operation seems to be a result of the circuit design of the two transistors which make the low state for IO0 or EN mutually exclusive.

I am looking to make thousands of these boards for an internal IOT solution and would really like to solve this.

Thoughts?

I would really like to have a reliable USB serial flash connection, rather than the mystery ... -------.......------ error!

[mikemoy]

I made my own programming board as well. Start with sticking a 0.1uf cap on EN to GND.

[FluxGS]

Hey mikemoy,
That makes sense in the fact that EN will be slow to rise while IO0 falls low, giving the opportunity of a rising EN while the chip has IO0 low.

The schematic published for the ESP32 Kit C illustrates the use of 1nF on EN. Thanks for the tip, I will give it a try.

It seems like the transistor exclusive or network was legacy from some other chip that is not quite suited for the ESP32.

Thoughts?

[mikemoy]

I tried the 1nf, but it worked on a few but not all prototypes. So I kept upping the capacitance while monitoring it with an oscilloscope until i got to a stable work ability across all boards. 0.1uf was the sweet spot for me, but you mileage may vary

[ESP_Angus]

I kept upping the capacitance while monitoring it with an oscilloscope until i got to a stable work ability across all boards.

Glad that adding the capacitor on EN solves the problem. As noted, the rise time of EN has to be timed such that IO0 has time to transition low before the ESP32 starts up.

It seems like the transistor exclusive or network was legacy from some other chip that is not quite suited for the ESP32.

This circuit does have some history. Back in the day (2014?) some ESP8266 development boards wired RTS & DTR directly to EN & IO0. This is still a valid option for low cost automatic boot mode circuits. This has the problem that most serial terminal programs will (by default) assert both RTS & DTR when the serial port is opened. Asserting RTS holds the chip in reset indefinitely, so the serial program needs to be configured to disable hardware flow control signals. This is possible, but it's not user friendly for dev boards aiming for ease of use.

This "two transistors" circuit was first used on the NodeMCU development boards designed for the ESP8266 (I think by vowstar). The idea is to cancel out the scenario where both RTS & DTR are asserted by a serial terminal program, while still allowing the pins to be used individually for reset mode control.

It turns out with ESP32, the IO0 signal is read slightly earlier in the hardware bootstrapping sequence compared to ESP8266. This also depends a bit on USB timing (we can't control USB host timing from the host operating system, Windows in particular can be quite slow in between sending control line transitions). Adding a capacitor on EN solves this problem. Espressif reference designs have adopted this since late 2016, but not every third party design has adopted it. If you want to really follow the history of this bootstrapping issue, it's all here.

[FluxGS]

Good break down ESP_Angus,
Mystery solved! It is nice to get the back ground and a reliable solution as well.
The BOM and Schematic provided with the ESP Kit C on the Espressif site do still call out 1nF for the EN capacitor.
I am about to make a second build and am so pleased to know the programming will be reliable.
Depending on the buttons makes the whole system manual.

Regards to mikemoy and ESP_Angus for sharing.
FluxGS

MYSTERY SOLVED!

[ESP_Angus]

The BOM and Schematic provided with the ESP Kit C on the Espressif site do still call out 1nF for the EN capacitor.

I think 1nF is what the board design team settled on as working. As far as I know this works on the Espressif dev boards. Interesting that you needed more capacitance in your case, though. What host platform & USB/serial interface are you using?

[Vader_Mester]

I guess, it can come down to using cheap transistors. Ver cheap and crappy transistors are not to be used above a couple of kHz, so they are not the fastest. They transition slower, and also usually have bigger internal capacitances, hence even slower response. This would eliminate the need for a bigger cap.

If you use a faster transistor, then you may end up using a bigger cap. So sometimes cheaper stuff have benefits, from a certain point of view