Chapter 4. API Guides
Once the option is enabled, build the project as usual.
4.32.3 Uploading the Application
Initial Upload
If the ESP32-S2 is not yet flashed with a program which enables USB console, we can not use idf.py flash
command with the USB CDC port. There are 3 alternative options to perform the initial upload listed below.
Once the initial upload is done, the application will start up and a USB CDC port will appear in the system.
Note: The port name may change after the initial upload, so check the port list again before running idf.py
monitor.
Initial upload using the ROM download mode, over USB CDC
• Press ESP32-S2 into download mode. To do this, keep GPIO0 low while toggling reset. On many development
boards, the“Boot”button is connected to GPIO0, and you can press“Reset”button while holding“Boot”
.
• A serial port will appear in the system. On most operating systems (Windows 8 and later, Linux, macOS)
driver installation is not required. Find the port name using Device Manager (Windows) or by listing /dev/
ttyACM* devices on Linux or /dev/cu* devices on macOS.
• Run idf.py flash -p PORT to upload the application, with PORT determined in the previous step
Initial upload using the ROM download mode, over USB DFU
• Press ESP32-S2 into download mode. To do this, keep GPIO0 low while toggling reset. On many development
boards, the“Boot”button is connected to GPIO0, and you can press“Reset”button while holding“Boot”
.
• Run idf.py dfu-flash.
See Flashing the Chip with the DFU Image for details about DFU flashing.
Initial upload using UART On development boards with a USB-UART bridge, upload the application over UART:
idf.py flash -p PORT where PORT is the name of the serial port provided by the USB-UART bridge.
Subsequent Usage
Once the application is uploaded for the first time, you can run idf.py flash and idf.py monitor as usual.
4.32.4 Limitations
There are several limitations to the USB console feature. These may or may not be significant, depending on the type
of application being developed, and the development workflow. Most of these limitations stem from the fact that
USB CDC is implemented in software, so the console working over USB CDC is more fragile and complex than a
console working over UART.
1. If the application crashes, panic handler output may not be sent over USB CDC in some cases. If the memory
used by the CDC driver is corrupted, or there is some other system-level issue, CDC may not work for sending
panic handler messages over USB. This does work in many situations, but is not guaranteed to work as reliably
as the UART output does. Similarly, if the application enters a boot loop before the USB CDC driver has a
chance to start up, there will be no console output.
Espressif Systems 1512
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General