ESP32 Dev Board DTR/RTS

Question

I recently got an ESP32 development board. I also found the schematic to this board online but I got an question. Can someone explain to me, what this part of the circuit is doing?

Schematic: https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf

enter image description here

Answer 1

EN is enable... Or nrst pin. IO0 is a boot mode pin. When the esp32 chip exits reset, it samples io0 and if it's low it will enter programming mode.

This enables the dev board to reset the board and automatically select the correct values for those pins when programming. See: https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection

• vicatcu: better answer than mine :-), but technically it lets the PC set things up...
• Tim Roberts: OK, but tell me why that truth table is right. To enter flash burn mode, I have to be able to hold IO0 low while toggling EN low and then high. There are no input conditions that lead to that state.
• Roger Dahl: @TimRoberts There's a cap on IO0 that holds it low for a while after it is released.
• Tim Roberts: I don't see that in the schematic, and we couldn't get it to work reliably. We threw this out and wired RTS to EN and DTR to IO0. That works, and seems to be what the tools expect.
• ygoe: @TimRoberts There's an unconnected capacitor in the "ESP32 module" section but there's also a connected capacitor and resistor in the "switch button" section. Maybe that has an effect. I haven't implemented that part yet, only the transistors, and observe strange behaviour (code reset?) when closing the serial monitor. Need to try some more here.

Answer 2

The circuit permits indeed to enter the bootloader. However the truth table doesn't seem to permit so. What I found so far indicates that lowering the RST pin for a long time then raise it quickly and at the same time lower GPIO0 it should enable the bootloader condition. Apparently there is some residual capacity on RST that enables this. It's very time sensitive and fails often. That's why the ESP32 esptool does plenty of retries until gets a SYNC across. I'm trying to reproduce this in C code on Linux.

Answer 3

It exploits behavior of the USB-Serial chip to put the ESP32 into bootloader mode to load new software over USB.

Answer 4

The development board must have a RC circuit for reset function, with the capacitor from EN to GND, to hold this pin in "0" for a short time after power on, all MCUs need it to boot safely. When you change DTR level from "1" to "0" and RTS from "0" to "1", IO0 will be "0" and the capacitor voltage are still growing up holding EN in "0". That is the desirable situation. Some times, if RC are not in the circuit or the time is not long enough, the procedure need to be restarted.

• who9vy: This is totally correct. Since it is not possible to get the state EN = 0 and IO0 = 0 by using DTR and RTS, it couldn't boot into normal mode after flashing. This state is just required for a short period. The capacitor will help to reach this state.

Answer 5

Regarding "why not directly connect the transistors's emitters to the ground so DTR and RTS would drive the pins independently" - I cannot speak for the designers, but I do have an educated guess about why they did it with the cross-coupled transistors. It has to do with what happens when a USB-serial chip is not powered or otherwise disabled. It is possible, and often desirable, to power the ESP32 independently from USB. If that is the case, and the ESP32 is running and the USB cable is not plugged in, you do not want the ESP32 to be reset (or GPIO0 to be forced) during that state. Nor do you necessarily want it be reset when you do plug in USB, or when the USB enumeration process wakes up the USB-serial chip, or when a program connects to the chip. You want to let the program decide what to do, not for something to happen automatically before the program takes control of the serial. It is hard to say what happens to the RTS and DTR lines during all of those transitions - are they high or low or do they change when power is applied? But one thing that is fairly likely is that, whatever it is that happens, the RTS and DTR lines do the same thing. So with the cross-coupled circuit, you have at least a fighting chance of disconnecting/reconnecting USB and all that entails, without crashing an already-running program.

• ygoe: Good explanation, but that circuitry doesn't achieve this effect. I see an MCU code reset every time I disconnect the serial monitor app from the port (i.e. closing the USB port on the PC side). Need to analyse this with a scope to see what's really going on here.

Answer 6

It works via the fact IO1 an EN on the ESP have weak internal pullups.

So when a base is 0(low) the pull up takes over because that transistor is OFF hence the pullup take the collector to 1(high). The design is poor but it does work, I personally dislike it.

Redraw the diagram with pullups on the collectors, then the truth table works.

Answer 7

I asked myself the same question, and the same logic is used on some Kendryte K210 boards. I also got the same truth table and wondered why. May be it's historical. So now, why not directly connect the transistors's emitters to the ground so DTR and RTS would drive the pins independently?

Answer 8

There is a big misconcept and misunderstanding in the ESP-Tool programmer hardware. The ESP-Tool sends both DTR and RTS. The two Transistor XOR Logic prevents EN and Boot held to 0 allways in case the RTS and DTR Data lines are held both high or low in idle mode of the USB-Serial-IF. The thing with ESP tool is, that without any capacitor on EN or Boot there is not the required timelag of 3 millisecends (datasheet) between Boot low and EN Release.

If you check the EN and the Boot signal with Oszi both signals are identical in timing. So increasing the EN Capacity is the wrong way. The most successfull way is to put a 10uF to the Boot Pin . Then there is the wanted Timelag between EN and Boot on the first positive flange of the EN Signal. The ESP Tool makes several attempts to enter bootloader but with a delayed Boot Pin it works at once. The datasheet explicidly warns about a big capacitor at the boot pin but 10uF is exact the right value to get a reliabe timing for the bootloader. The 100nF at the EN Pin is mandatory for the reset delay