7

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

Zedipl
  • 73
  • 1
  • 4

7 Answers7

5

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

David Molony
  • 1,179
  • 7
  • 14
  • better answer than mine :-), but technically it lets the PC set things up... – vicatcu Dec 27 '19 at 15:01
  • 1
    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. – Tim Roberts Jun 29 '21 at 17:54
  • @TimRoberts There's a cap on IO0 that holds it low for a while after it is released. – Roger Dahl Nov 19 '21 at 21:44
  • 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. – Tim Roberts Nov 19 '21 at 22:01
  • @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. – ygoe Oct 22 '22 at 10:43
1

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

vicatcu
  • 22,499
  • 13
  • 79
  • 155
1

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.

Lieven
  • 11
  • 1
1

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.

Artur Antonio de Araújo
  • 11
  • 1
  • 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. – who9vy Dec 07 '21 at 19:10
0

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?

Acathla
  • 1
0

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.

Mitch Bradley
  • 1
  • 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. – ygoe Oct 22 '22 at 11:13
0

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.

N Tal
  • 1