Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] ESP32 DTR and RTS pins.

Status
Not open for further replies.

Jackob2001

Junior Member level 1
Junior Member level 1
Joined
Nov 3, 2024
Messages
17
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
186
Hello,

I've been trying to understand how this circuit works :

1731108649667.png


What do I mean by works is when and why DTR and RTS changes states during the programming.
I've failed to understand how they change states.

DTR as I understood means that PC is ready for communication,
RTS as I understood means that PC is ready to send data,

The thing is when I write a code in VS Code, and send it through USB to this USB-UART converter FT232RNL-REEL, then when and why DTR changes state from 1 to 0 and RTS as well from 1 to 0 during the time when I send the code from VS code ?

I tried to understand that when I send the code then does it mean that PC is not ready to communicate or is not ready to send data because it is already sending data so the pins are set to SET or RESET. I don't understand it.

Before hand I tried to read datasheet for both FT232RNL-REEL and ESP32-WROOM-32D which will be attached below, but I still failed to understand when do those pins change during the program sending from VS code to USB-UART converter.

If there is something I forgot to add, please tell me and I'll try to provide because I might not know everything what to provide.
 

Attachments

  • DS_FT232RN-3135636.pdf
    1.2 MB · Views: 13
  • esp32-wroom-32d_esp32-wroom-32u_datasheet_en.pdf
    654.9 KB · Views: 15

... and to note that it is only their states as the MCU comes out of reset that puts it in programming mode. At any other time, after normal start up, they work as handshaking signals.

Brian.
 

Hi,

=== ESP side
the ESP has several modes of operation:
* normal RUN (your code)
* RESET (halted, no code is executed)
* BOOTloader run (special code inisde the ESP is performed to communicate via UART and to write YOUR conde into the ESP .. to be run later)

Usually the ESP is in RUN mode
Now if you want to put new code on it the steps are
* RESET (for a short time, maybe 100ms)
* start BOOTloader
* communicate and program your code
* RESET (for a short time, maybe 100ms)
* RUN your code

==== UART side
UART is a serial communication.
In simplest case you need
* one signal line for [PC --> ESP] communication
* one signal line for [ESP --> PC] communication
* and GND

But there are additional signals for communication like DTR and RTS and the function is like you described.
These lines may be used or not.
And these signal states may be generated automatically be the UART hardware
...OR they may be controlled manually by PC software. And this is the case here.

And exactly this is the case here: These two signals are controlled manually in the PC by the ESP_programming_software.
But here they are NOT used in the original meaning of UART communication signals.
And - if I´m not mistaken - due to their wiring to the ESP, they can NOT be used in the meaning of UART_DTR and UART_RTS at all.

They use these two lines like GPIO signals ... just to be able to place the ESP into the desired operation modes:
(you may say they mis-use these lines)

==== Now ESP and control lines combined:
To put the ESP into RESET MODE, you need to get [EN = 0]
--> this is done by setting [DTR = 1] and [RTS = 0]. This is static.

To put the ESP into BOOTloader mode, you need to leave the RESET state [EN = 0 -> 1] while [GPIO0 = 0]
--> this is done by [DTR = 1-> 0] and [RTS = 0 ->1] (a small signal delay is generated with a capacitor on EN ... to be sure the signal at GPIO0 settled first)

To put the ESP into RUN mode, you need to leave the RESET state [EN = 0 -> 1] while [GPIO0 = 1]
(now you have two options you can randomly use)
--> this is done by [DTR = 1-> 0] while [RTS = 0] (a small signal delay is generated with a capacitor on EN ... to be sure the signal at GPIO0 settled first)
or
--> this is done by [DTR = 1] while [RTS = 0 -> 1] (a small signal delay is generated with a capacitor on EN ... to be sure the signal at GPIO0 settled first)

Note: [1 -> 0] means the edge, when the signal transitions from 1 to 0. Likewise [0 -> 1]

***
So your state table could be added with the ESP states information:
Code:
DTR | RTS --> EN | GPIO0 | --> MODE
 1     1       1    1           RUN user code
 0     0       1    1           RUN user code
 1     0       0    1           RESET
 0     1       1    0           BOOTloader

Klaus
 
And exactly this is the case here: These two signals are controlled manually in the PC by the ESP_programming_software.
But here they are NOT used in the original meaning of UART communication signals.
And - if I´m not mistaken - due to their wiring to the ESP, they can NOT be used in the meaning of UART_DTR and UART_RTS at all.

They use these two lines like GPIO signals ... just to be able to place the ESP into the desired operation modes:
(you may say they mis-use these lines)

Very crucial information.
I understand now, thank you.


To put the ESP into BOOTloader mode, you need to leave the RESET state [EN = 0 -> 1] while [GPIO0 = 0]
--> this is done by [DTR = 1-> 0] and [RTS = 0 ->1] (a small signal delay is generated with a capacitor on EN ... to be sure the signal at GPIO0 settled first)

To put the ESP into RUN mode, you need to leave the RESET state [EN = 0 -> 1] while [GPIO0 = 1]
(now you have two options you can randomly use)

It left the Reset state once so twice ? EN = 1 after leaving once the Reset State, so DTR = 0 and RTS = 1 so to leave the BOOTloader mode to RUN mode shouldn't it be only RTS = 1 -> 0 ?
 

It left the Reset state once so twice ?

I wrote:
Now if you want to put new code on it the steps are
* RESET (for a short time, maybe 100ms)
* start BOOTloader
* communicate and program your code
* RESET (for a short time, maybe 100ms)
* RUN your code
here you see twice the RESET state ... and thus the reste state needs to be left twice.
1) to enter the BOOTloader mode
2) to RUN your code. For this you have two options, like I explained here:
--> this is done by [DTR = 1-> 0] while [RTS = 0] (a small signal delay is generated with a capacitor on EN ... to be sure the signal at GPIO0 settled first)
or
--> this is done by [DTR = 1] while [RTS = 0 -> 1] (a small signal delay is generated with a capacitor on EN ... to be sure the signal at GPIO0 settled first)

What exactly is unclear?

Klaus
 
What exactly is unclear?

My bad I thought this is step by step how it works.
So I thought when after entering the RESET mode in point.1 you've said, then entering Bootload is after exiting the point.1 reset, then entering the Run is when we leave bootload.

Like step by step but this is something else.
(now you have two options you can randomly use)

This one was also not clear because I thought it is predetermined how it works by the tool because I am not using DTR and RTS but the ESP tools.

The sequence to program ESP as I read is :

- press RESET
- While still on RESET, press BOOTLOAD
- Release RESET, while pressing BOOTLOAD
- Release BOOTLOAD
- UPLOAD PROGRAM
- Press and release RESET.

So it must work like that because both RESET and BOOTLOAD must be turned on the :

- [DTR = 1] and [RTS = 0] - press RESET
- [DTR = 1-> 0] and [RTS = 0 ->1] - RESET is still ON for shortwhile and BOOTLOAD is ON
- [DTR = 0-> 1] while [RTS = 1] - From BOOTLOAD to RUN (will quickly settle because EN is settled)
- [DTR = 1] and [RTS = 1 ->0] - From RUN to RESET, exiting BOOT mode (GPIO is settled so same thing)
- [DTR = 1 -> 0] and [RTS = 0] or anything. - From RESET to Run mode

all 6 stages in 5 line of sequence

Or perhaps it depends, but in some cases while EN is settled then GPIO can be switched on instant.
I understood that this EN was settling after GPIO to give it a moment where we have RESET and BOOT at the same time. Which happens once. The rest can work normally I guess.
--- Updated ---

Or I might know why it is like that the last part : - [DTR = 1 -> 0] and [RTS = 0] or anything. - From RESET to Run mode. Is determined by the tool so it can be this or another state.

I think I understand it now.
Thank you very much !!!!!

Now I will be hunting for the answer for the STM32 question ;>
 
Last edited:

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top