ESP32 Forum

I'm running the application on a custom board using the ESP32-C3. This board connects a USB Type C connector the the standard GPIO18 and GPIO19 of the MCU without any UART bridge IC. This example application uses the console and linenoise components.

ESP32-C3 documentation https://docs.espressif.com/projects/esp ... nsole.html implies that this arrangement supports proper escape sequences to the serial monitor. I'm using a very common Linux OS that's newly installed and up to date, with several terminal applications like cu(1), screen(1), and minicom(1). Everywhere I try, I receive the error:
Does anyone understand if the above errors are expected on the ESP32-C3 (a chip without full USB protocol hardware) when routing to a USB connector without any UART bridge IC?

What other things can be causing this problem, is there some configuration variable in menuconf that enables USB escape sequence support?

I'm only modifying the sdkconfig by switching from UART to USB in Component config → ESP System Settings → Channel for console output.

What other things can be causing this problem, is there some configuration variable in menuconf that enables USB escape sequence support?

Apparently, the console performs a check to see if the terminal application responds properly to an escape-coded request; if it doesn't, it goes into "dumbMode".
So maybe the terminal application needs to be configured to properly respond to the request from the C3.
- Or, if the C3 starts its console before USB is connected and the terminal application is ready, its request is lost and consequently no 'smart' terminal is detected at that time.

If the ESP-IDF console component performs a check to see if the monitoring terminal application responds properly to an escape-coded request, then I wonder how the example can ever run correctly. I mean, unless the example code waits until a USB connection is detected, it would issue the check logic some microseconds after power is on the MCU. Typically the monitoring terminal application runs on a OS that populates a device tree according to the connected ESP MCU device being turned on.

In my case, the device tree node populated in GNU/Linux when the ESP32-C3 device is turned on is called: /dev/ttyACM0.

If the above is true, the user would need to type and execute the monitoring terminal application within microseconds of the device MCU turning on. Can you understand this, and is there some missing logic or an error in my understanding?

Can you understand this...?

Yup.
Notice though that the IDF monitor can and usually does reset the chip after connecting, without losing the USB connection. That's why we can see the boot logging long before the application has even had a chance to set up a console.
Did you try IDF monitor?

The $ idf monitor command always properly used escape codes, and did not exhibit the problem stated here. I have not been using that command much, in order to focus on the standard terminal applications most typically used like Winterm, Putty, Screen, Cu, Minicom, and similar.

Update

While switching between idf monitor and screen(1) I discovered by accident, that if a ESP32-C3 is powered on for the first time and then connects its console application (basic example) using idf monitor running on the downward facing port Linux host, that after quitting idf monitor all other serial terminal applications (screen, cu, minicom) are served escape codes correctly by the ESP-IDF console component. The problem does not appear in this strange situation.

Let me explain. The following failure and success sequences both use the same examples/system/console/basic firmware running on the same ESP32-C3 custom device connected with the same USB cable to the same Linux host.

Failure to serve escape codes

1. Plug ESP32-C3 device into the Linux host with a USB cable
2. Turn on the power of the ESP32-C3 device
3. Run a standard terminal application on the Linux host

Success to serve escape codes

1. Plug ESP32-C3 device into the Linux host with a USB cable
2. Turn on the power of the ESP32-C3 device
3. Run idf.py monitor on the Linux host
4. Wait to see the ESP32-C3 console application connect, showing esp32c3> prompt
5. Quit the idf.py monitor by typing Ctrl-]
6. Run a standard terminal application on the Linux host

Summary

Using the ESP-IDF console component with CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG fails to serve escape codes in all cases except when (1) the idf.py monitor is run first and (2) a standard terminal application is run afterwards.

Question

Is this realisation enough to conclude that the ESP-IDF console component is defective? It's clearly not serving escape codes in all the cases where it should do so. If anyone thinks this is a console component implementation flaw, then I will write a bug report on the ESP-IDF repository.

esp-idf/components/console/

Is this realisation enough to conclude that the ESP-IDF console component is defective?

Uhm, no?

When initializing, the console tries to detect if the terminal supports escape sequences, and if the terminal does not reply, because it is not yet connected at that point, the console goes into "dumbMode" - what else should it do?
If you want, you can call linenoiseSetDumbMode(0) later to enable "smart" mode again if you know/assume that the terminal actually does support escape sequences.

I think you are correct, the author of this example probably doesn't intend for runtime to execute without warnings or errors.

you can call linenoiseSetDumbMode(0) later to enable "smart" mode again

Another idea is to detect the USB connected state, and wait to run the console component until the connection is established. I don't know how this would work in the case of UART, but with a USB connection it seems possible:

• Detect USB serial/JTAG port connection: viewtopic.php?t=31293
• How to know if USB console plugged in: viewtopic.php?t=26380

...from the forum questions and answers it's clear that others have faced this common problem, I'll take a look at the suggested solutions.

Another idea is to detect the USB connected state, and wait to run the console component until the connection is established.

Unfortunately, the USB connection doesn't "know" if&when there's a terminal connected/listening at the other end.
Safest way would probably be to have the terminal send some special sequence when it is connected and ready to be queried for escape support. Only when data is received by the ESP you know that you are connected not only to USB but also to an application behind that. And even that is not universal: What if the terminal is exited and another one started?

You're right that it's not enough to simply wait for a USB connection to happen. That is easy to detect (see the two methods previously reported) but does nothing to ensure terminal emulation is executing.

have the terminal send some special sequence when it is connected and ready to be queried for escape support.

It's too much to expect a user to configure their terminal application with a special handshake or start sequence, but maybe a compromise would be to wait for a linefeed code which a user typically presses to test the connection before typing begins?

What if the terminal is exited and another one started?

I'm unaware if most terminal applications send codes when first connecting, maybe there is some standard start sequence that we can expect? That would be the right time to reset, detect escape codes, and print a welcome message.