A Deep Dive into the ESP8266/ESP32 Automatic Download Circuit

Background

Recently, I needed to create an ESP32 board by myself. Considering cost and packaging, I planned to choose CH340E as the USB-to-serial chip. Generally, ESP8266/ESP32 boards have an automatic download circuit that allows users to enter download mode for firmware flashing without pressing a button. However, the automatic download circuit requires serial chip support for DTR and RTS, while CH340E only has an RTS signal and no DTR signal. Therefore, I researched the principle of the automatic download circuit and planned to use some clever tricks to solve the automatic download issue with CH340E.

Unfortunately, most of the explanations found on the Chinese internet regarding the automatic download principle of ESP8266/ESP32 are incorrect. A small error can lead to a big misunderstanding. If assumptions are made carelessly, one can only arrive at wishful conclusions.

Download Mode

The conditions for the ESP8266/ESP32 to enter download mode^[1] are quite simple:

EN (also known as RST) must be high while GPIO0 remains low, as shown in the figure below:

Analysis 1

The download circuit is shown below, its structure is quite similar to that of an RS flip-flop. Note that both EN and IO0 signals are connected to the collector of the transistor, controlling the transistor can only pull this signal low; if the transistor is off, the state of this signal is determined by other circuits (generally, such signals default to being pulled up to VCC with resistors).

The logical relationships are as follows:

DTR = 0; RTS = 0, at this point Q1 is off, Q2 is off, EN = 1; IO0 = 1
DTR = 0; RTS = 1, at this point Q1 is off, Q2 is on, EN = 1; IO0 = 0
DTR = 1; RTS = 0, at this point Q1 is on, Q2 is off, EN = 0; IO0 = 1
DTR = 1; RTS = 1, at this point Q1 is off, Q2 is off, EN = 1; IO0 = 1

Truth Table:

In summary: when DTR and RTS are both 0 or both 1, both transistors Q1 and Q2 are off, and the states of EN and IO0 are determined by other circuits (internal/external pull-up resistors).

When they are not simultaneously 0 or 1:

EN  = RTS
IO0 = DTR

Note that under this logic, EN and IO0 cannot both be 0. However, to enter download mode, the following sequence is required:

1.  IO = 0; EN = 0
2.  IO = 0; EN 0 -> 1

From the logical table, it is fundamentally impossible to enter download mode normally; this is the first doubt.

Analysis 2

Next, let’s continue analyzing the download-related code in esptool.py^[2].

 # issue reset-to-bootloader:
        # RTS = either CH_PD/EN or nRESET (both active low = chip in reset
        # DTR = GPIO0 (active low = boot to flasher)
        #
        # DTR & RTS are active low signals,
        # ie True = pin @ 0V, False = pin @ VCC.
        if mode != 'no_reset':
            self._setDTR(False)  # IO0=HIGH
        1)  self._setRTS(True)   # EN=LOW, chip in reset
            time.sleep(0.1)
        2)  self._setDTR(True)   # IO0=LOW
        3)  self._setRTS(False)  # EN=HIGH, chip out of reset
            time.sleep(0.05)
        4)  self._setDTR(False)  # IO0=HIGH, done

Note that True is low, and False is high. Moreover, although the two statements setDTR() and setRTS() in the code appear to be consecutive without delay, the delay between these two statements cannot be ignored due to the high-level programming language Python. Therefore, the analysis must be sequential, divided into four stages:

1. Set DTR = 1; RTS = 0, at this point Q1 is on, Q2 is off, EN = 0; IO0 = 1
2. Set DTR = 0; RTS = 0, at this point Q1 is off, Q2 is off, EN = 1; IO0 = 1
3. Set DTR = 0; RTS = 1, at this point Q1 is off, Q2 is on, EN = 1; IO0 = 0
4. Set DTR = 1; RTS = 1, at this point Q1 is off, Q2 is off, EN = 1; IO0 = 1

If we draw conclusions based on the code analysis above, it is impossible for the system to enter download mode: EN and IO0 cannot both be 0, and EN transitioning from 0 to 1 does not allow IO0 to be 0. This further confirms the previous doubt: how does the system enter download mode?

Answer

The answer to the question is actually in another part of the circuit; the principle is quite simple: the EN signal is connected to a capacitor charging and discharging circuit.

CHIP_PU is EN. After stages 2-3 in the code, there will be a delay. Since EN does not immediately change to high level due to capacitor charging, but rises slowly. Using the above parameters for calculation and referencing the chip’s electrical characteristics:

The high level is 0.75VDD, so the time to reach high level is calculated as follows:

Solving gives t = 14ms, meaning EN rises to level 1 after 14ms. In the actual code, a delay of 50ms is used to ensure that EN is in high state after the delay.

It’s also important to note that in stage 1, a waiting time is needed to allow the capacitor to discharge, ensuring EN drops to level 0. In the code, a waiting time of 100ms is reserved, and you can calculate the time needed to discharge to level 0 using the capacitor discharge formula. Interested friends can confirm by calculating based on the formula.

Thank you all for learning about ESP32, I hope you enjoy!

References