ESP32 Forum

Hi,

I have a question regarding the UART ROM Download Mode → Permanently Switch to Secure Mode setting.

I have an ESP32-S2-MINI-2 custom board, with all security features enabled (Secure Boot V2, Flash Encryption, Release Mode (using my own encryption key)), and everything works correctly in this configuration.

I recently enabled Security Features → UART ROM Download Mode → Permanently Switch to Secure Mode

After booting the device, the eFuse was successfully burned, and the behavior initially matched my expectations:
- espefuse.py summary no longer worked
- I could still communicate with the device through Download Mode
- I was able to read the device's MAC address using esptool.py

However, after approximately 10 seconds, the USB COM port disappeared from Device Manager and I could no longer communicate with the chip through Download Mode.

The application itself continues to boot and run normally, and all application functionality is working as expected.

I am using a native USB (USB D+/D- connected directly to the ESP32-S2) connection and no external UART connected (GPIO43/GPIO44 are not exposed).

My expectation was that enabling Secure Download Mode would restrict available ROM commands, but not completely remove access to Download Mode over USB.

Is this expected behavior on ESP32-S2 when using native USB, or could there be another eFuse or security setting interacting with Secure Download Mode? I looked in the code (esp-idf 5.5.1), but I don't see any additional fuse burned.

Thank you

I don't recall the exact efuse situation, but it could be you're hitting intended behaviour. USB-OTG (as the ESP32-S2 has) needs a large driver to work as a serial port, and as a large driver also gives a large attack surface, it's disabled if you go into secure boot mode. I think this affects both download mode as well as using the chip for CDC-ACM console logging (but you can switch to TinyUSB to get around this). Note later chips have USB-serial-JTAG which does not need a driver and as such is not affected by this quirk.

Thank you. I will assume that the USB driver is being deactivated, and I will try using the UART pins (GPIO43/GPIO44) to see if that works.

Unfortunately, I will not be able to provide feedback soon, since those pins are not exposed on the sample boards I currently have.