ESP32 Forum

Hello,

I'm working on placing the ESP32-WROOM-32E onto an existing PCB design. The device will be powered from existing onboard 3.3V, and will not be featuring a USB connector/USB5V/onboard USB-UART converter. Currently, I'm referencing both the ESP32-WROOM-32E data sheet section 6 "Peripheral Schematics", as well as the ESP32-DeVKitC_V4 schematic.

We would like to have multiple interfaces available to use:

A) External UART interface for serial communications/debugging/programming, likely with an external UART/USB converter such as: https://ftdichip.com/products/ttl-232r-3v3/

B) External JTAG programming/debug interface

C) Onboard UART interface for programming and communication with an existing master MCU. Our master MCU will have access to IO0 and EN to set the boot mode for this use case.


I have a few questions regarding proper configuration of the device programming and boot modes.:

1) Can any UART port be used for programming, or just UART0 (U0RXD/U0TXD)? Meaning, can separate UART interfaces be provided to the onboard master MCU and offboard for programming? If so, how is this configured?

2) How can an external UART device control the boot mode automatically for UART programming? I see that on the ESP32-DeVKitC_V4, DTR/CTS flow control signals generated by the UART converter set the Boot setting pins EN/IO0, but I'm a bit confused by this implementation. How can an external UART/USB converter be used, and are transistors Q1/Q2 required? As I understand boot configuration, would it be acceptable just to leave EN high (device on/not in reset) and hold IO0 low with a pushbutton or ICT fixture, or is there some sequencing required that I'm missing?

3) Is there any onboard configuration required to setup the device for JTAG programming, or is this automatic? In most documentation I read, UART appears to be the preferred programming method, is there a reason for this? We intend to use JTAG possibly for programming during assembly, as well as for in-circuit debugging for design.

Thank you

Looking to bump and clarify some revised requirements

I've removed the requirement for UART firmware programming from our internal interface (though if it's possible, we'd like the option).

Questions 2 and 3 are still remaining, though #2 is the current priority

The ESP32 needs a certain dance on the IO0/enable lines to go to programming mode. The two-transistor-network is there to allow that, but not accidentally keep the ESP32 in reset or accidentally boot into programming mode if you use a standard terminal emulator to look at the serial port.

Serial programming is the better tested of the two, and given the auto-reset circuit works, it can always bring an ESP32 out of whatever state it is in into programming mode. JTAG is also possible, but if there's e.g. a program in the flash that reconfigures those pins, JTAG alone is not usable to get it out of that mode.

Thanks for the reply sprite.

It looks like many standard USB-UART cables (including the FT232 that we plan to use) don't feature the DTR line that is leveraged on the EVAL board. Any recommendations for how to work around this?

Also, can this boot procedure be simply coordinated with a button press procedure for the EN and IO0 lines?

Yep, a reset and IO0 button would be a proper workaround.

Thank you.

If we were to try to implement a more automated programmed method with an external UART, how would we deal with the DTR issue described above? This solution would definitely be preferred, so any information you can provide would be very helpful

A button based procedure is not preferred, but could be an option if it is simple enough. However, we may need techs to perform this procedure in the field, so simple is much better. As I see it, the procedure would be the following, which is doable but definitely a bit complicated for a field process. Please let me know if I have anything wrong here (buttons active low):

Hold both IO0 and EN buttons simultaneously
Release EN button - Device powers on into Download boot mode
Release IO0 Button shortly after, as it should now be latched
Transmit the new device firmware via UART
Press and release EN button - Device restarts into SPI boot, loading the new firmware

That is the correct procedure. If you need something automated, I suggest you use something that does have DTR/RTS signals to do the reset/io0 dance automatically. It's a little bit overkill if you don't need JTAG, but perhaps our ESP-Prog board can help you out there?