Use DTR/RTS upload control in products?
Posted: Sat Oct 22, 2022 5:42 pm
Hello,
I've been playing with the ESP32-PICO kit for some time now and always attached it to the PC with its provided USB port. Uploading new firmware including the automatic reset was never a problem here. Now, in preparation of custom PCBs with just the ESP32-WROOM module, I built up such a reset and boot circuit myself. I used an FTDI232 module that exposes the DTR and RTS lines and built the two-transistor circuit that is shown in the PICO kit schematic. I also followed the signals and included the two capacitors to ground for EN and IO0.
This setup generally works with ESP-IDF (using PlatformIO). I noticed that the pio serial monitor (like any other terminal application) activates the DTR and RTS lines when connecting, so that I observed a reset when closing the monitor. The pio serial monitor has options to prevent that, PuTTY doesn't. Also, the DTR and RTS lines still jump around for a brief moment after attaching the USB serial module to the PC.
I understand that the transistors should avoid unintended resets in common situations. But it's not very stable and still requires custom terminal app configuration. That all leads me to believing that this whole circuit is just a cunning hack to make firmware uploads easier during development. After all, all of these ESP-based modules are called "development kits", which probably means that they should not be used as-is in final product designs.
I'm currently designing two different kinds of product devices. One that is meant to be used primarily via USB (for power and communication with a host, later maybe also just for power using Bluetooth communication) and one that usually doesn't have any USB connectivity. Both devices should not regularly need firmware uploads.
So would it be advisable to simply leave away those DTR/RTS connections to EN/IO0 and use other means to allow firmware uploads? Or is it still seen as good practice to include such circuits and allow the user to upload the firmware without any hardware interaction?
For example, I see that the Shelly devices (based on ESP8266/ESP32) have both EN and IO0 pins on their debugging connector, but that's only serial, not USB.
Without these connections, I'd probably place a jumper on the PCB that pulls IO0 to GND when closed. It can also be operated with a screwdriver or other tools. (For more closed devices, an externally accessible push button would do.) To upload new firmware, the device must be detached from the computer, the jumper must be closed (or button pressed) and it then needs to be attached again. It will always boot in download mode. The firmware tool cannot reset the device but shouldn't need to and can directly upload the firmware. When done, the device remains in download mode and must be detached by the user, pull the jumper and attach again to boot regularly.
The other device without USB would look like this: I'd expose the RX and TX lines (and VDD and GND) and still pull the IO0 line to GND with a jumper (or part of a custom connector). The USB serial adapter is provided externally, any model will do. No USB chip will be in the device itself.
I've been playing with the ESP32-PICO kit for some time now and always attached it to the PC with its provided USB port. Uploading new firmware including the automatic reset was never a problem here. Now, in preparation of custom PCBs with just the ESP32-WROOM module, I built up such a reset and boot circuit myself. I used an FTDI232 module that exposes the DTR and RTS lines and built the two-transistor circuit that is shown in the PICO kit schematic. I also followed the signals and included the two capacitors to ground for EN and IO0.
This setup generally works with ESP-IDF (using PlatformIO). I noticed that the pio serial monitor (like any other terminal application) activates the DTR and RTS lines when connecting, so that I observed a reset when closing the monitor. The pio serial monitor has options to prevent that, PuTTY doesn't. Also, the DTR and RTS lines still jump around for a brief moment after attaching the USB serial module to the PC.
I understand that the transistors should avoid unintended resets in common situations. But it's not very stable and still requires custom terminal app configuration. That all leads me to believing that this whole circuit is just a cunning hack to make firmware uploads easier during development. After all, all of these ESP-based modules are called "development kits", which probably means that they should not be used as-is in final product designs.
I'm currently designing two different kinds of product devices. One that is meant to be used primarily via USB (for power and communication with a host, later maybe also just for power using Bluetooth communication) and one that usually doesn't have any USB connectivity. Both devices should not regularly need firmware uploads.
So would it be advisable to simply leave away those DTR/RTS connections to EN/IO0 and use other means to allow firmware uploads? Or is it still seen as good practice to include such circuits and allow the user to upload the firmware without any hardware interaction?
For example, I see that the Shelly devices (based on ESP8266/ESP32) have both EN and IO0 pins on their debugging connector, but that's only serial, not USB.
Without these connections, I'd probably place a jumper on the PCB that pulls IO0 to GND when closed. It can also be operated with a screwdriver or other tools. (For more closed devices, an externally accessible push button would do.) To upload new firmware, the device must be detached from the computer, the jumper must be closed (or button pressed) and it then needs to be attached again. It will always boot in download mode. The firmware tool cannot reset the device but shouldn't need to and can directly upload the firmware. When done, the device remains in download mode and must be detached by the user, pull the jumper and attach again to boot regularly.
The other device without USB would look like this: I'd expose the RX and TX lines (and VDD and GND) and still pull the IO0 line to GND with a jumper (or part of a custom connector). The USB serial adapter is provided externally, any model will do. No USB chip will be in the device itself.