ESP32-S3 Disable Firmware Download

[hardware_engineer]

Hi, I have an ESP32-S3 DevKitC module. This module has the USB-UART bridge, which I wanted to disable the DTR/RTS signal via hardware to prevent anyone from putting the device in download mode. I was thinking of routing these signals to a tri-state non-inverting buffer and controlling the enable pin via a microcontroller. Does anyone have any better suggestions or implementation?

[hardware_engineer]

the 10k after the transistors are 0 ohms.

[MicroController]

prevent anyone from putting the device in download mode

Do you mean to prevent anyone from accidentally putting the device in download mode?
It seems you actually still want to be able to download via UART.

routing these signals to a tri-state non-inverting buffer and controlling the enable pin via a microcontroller

Might be overkill only to override a single active-low signal (GPIO0)...

[hardware_engineer]

Yes, I still wanted to have a control to enable/disable the boot mode function.
Do you see any issues in this implementation?

I agree that this is an overkill. Do you have any better/simpler solution that you can think of?

[MicroController]

Yes, I still wanted to have a control to enable/disable the boot mode function.
Do you see any issues in this implementation?

No I'm only asking because you can also permanently disable the strapping pin's (GPIO0) "enter download mode" functionality, if you're after disabling download mode for security reasons; in that case, you'd also have to disable the USB/JTAG interface. Depends on what you want to protect against.

Do you have any better/simpler solution that you can think of?

Not sure about better, but simpler/cheaper could be a single 5-10k resistor in the "RTS" line after the transistor (where the "10k"/0 Ohms are now), with the other MCU's pin connected directly to GPIO0. This way, as long as the MCU outputs high, RTS cannot pull down GPIO0; tri-state the MCU's output to allow RTS to pull GPIO0 low again.

[hardware_engineer]

No I'm only asking because you can also permanently disable the strapping pin's (GPIO0) "enter download mode" functionality, if you're after disabling download mode for security reasons; in that case, you'd also have to disable the USB/JTAG interface. Depends on what you want to protect against.

Yes, you are right. We wanted to disable the download mode for security purposes but somehow, we wanted to have some flexibility on enabling it back again in case we need to upgrade the firmware. Interesting point on permanently disabling the download mode. Is this something to do with secure boot? Is there any way for us to reflash the board again in case there are some issues on the board that disabled the download mode? Do you have any references on disabling/enabling the download mode?

Not sure about better, but simpler/cheaper could be a single 5-10k resistor in the "RTS" line after the transistor (where the "10k"/0 Ohms are now), with the other MCU's pin connected directly to GPIO0. This way, as long as the MCU outputs high, RTS cannot pull down GPIO0; tri-state the MCU's output to allow RTS to pull GPIO0 low again.

This is a good point. I will take note of this one. Thanks.

[MicroController]

Is this something to do with secure boot? Is there any way for us to reflash the board again in case there are some issues on the board that disabled the download mode? Do you have any references on disabling/enabling the download mode?

It's at least related to secure boot and flash encryption, see e.g. https://docs.espressif.com/projects/esp ... om-dl-mode
Locking everybody out from UART and JTAG flash programming means that any firmware updates will have to be done via "OTA" update, i.e. from the application itself. How and over which communication channel the application accepts a new firmware is completely up to you (can be "over-the-air" (WiFi,BLE), or via any other interface).
However, if your ESP uses an external flash chip, it is almost trivial (needs physical access) to inject arbitrary altered code to be executed as part of your firmware; that's where flash encryption and secure boot come in to make sure the firmware only does what you want it to do.

[hardware_engineer]

I'm getting back to this topic again.

If we disable the Download Mode permanently, can we access the UART for debugging purposes if there's some field return that we want to investigate?