esp32-s3: When using USB CDC, UART 0 will still print console output.

[xlin350]

Checks

• I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.

• I've searched for existing issues matching this bug, and didn't find any.

Port, board and/or hardware

esp32 port, ESP32_GENERIC_S3, ESP32-S3-WROOM-1-N16R2 WIFI Module with Quad SPIRAM

MicroPython version

MicroPython v1.22.2 on 2024-02-22; Generic ESP32S3 module with ESP32S3

IDE: Thonny

Reproduction

I'm currently using the built-in usb peripheral in the esp32s3 to connect to my pc, and connecting gpio1 and gpio2 ((which are not, in fact, specified)) to a ch340-based usb-ttl converter that connects to my pc to use as a debugger：

# The codes below raised error
from machine import UART
uart = UART(0, baudrate=115200, tx=1, rx=2)  # UART0
uart.write('Hello, UART!')

I then also tested the adoption of uart1 as follows：

# The codes below run well
from machine import UART
uart = UART(1, baudrate=115200, tx=1, rx=2)  # UART1
uart.write('Hello, UART!')

Expected behaviour

They have completely different phenomena. When I used UART1, no matter which two GPIOs I used for tx and rx (in this sample, I still used GPIO 1 and 2), the serial commands I sent were printed correctly on the serial port monitor like following:

Observed behaviour

When I initialize the UART instance, if I use UART0, then no matter which two GPIOs I use for tx and rx, the serial monitor will show some garbled code and will not show the serial commands I send, like:

It looks like the gibberish is some Thonny IDE information printed by UART0, I don't know why this is happening as I am currently using the built-in USB connection and using CDC for debugging, and I have looked at the micropython source code, and it looks like UART0shouldn't be used to output debugging information in this case.

Additional Information

I looked at the micropython source code and there are these macro definition lines in port/esp32/uart.h:

#ifndef MICROPY_HW_ENABLE_UART_REPL
#define MICROPY_HW_ENABLE_UART_REPL (!CONFIG_USB_OTG_SUPPORTED && !CONFIG_ESP_CONSOLE_USB_CDC && !CONFIG_ESP_CONSOLE_USB_SERIAL_JTAG)
#endif

It looks like if I use USB_CDC, CONFIG_ESP_CONSOLE_USB_CDC will be set to 1, and then MICROPY_HW_ENABLE_UART_REPL will be set to 0, so it shouldn't print the REPL message inside UART0?
And, it is also defined in port/esp32/boards/ESP32_GENERIC_S3/mpconfigboard.h as follows:
#define MICROPY_HW_ENABLE_UART_REPL (1)
I'm wondering if I try to set this to 0 and then recompile the micropython firmware, will the bug or problem I described above be fixed?

[felixdoerre]

Yes, configuration in mpconfigboard.h usually overrides the default logic. I believe compiling with this setting set to 0 will solve the behavior you are observing.

It looks like the gibberish is some Thonny IDE information printed by UART0,

The output you are showing looks very plausible to be the current REPL-output that Thonny creates.

[jd3096-mpy]

I change
#define MICROPY_HW_ENABLE_UART_REPL
to 0
UART 0 don't print anything and it doesn't seem to affect other features

[projectgus]

Yes, setting MICROPY_HW_ENABLE_UART_REPL explicitly to 0 should work.

I'm not sure if this is something we should change in MicroPython, as there's no way for MicroPython to tell if a generic ESP32-S3 module will be connected via USB or plain UART. Providing both by default seems more usable than splitting into two build variants (ESP32_GENERIC_S3_USB and ESP32_GENERIC_S3_UART) and making people choose at download/flashing time.

We could add a feature to disable the UART0 REPL at runtime, but I think this might lead to more problems that are harder to debug: because after a reset, some MicroPython output would still appear on the UART REPL before it's disabled, and this would be sent to whatever device is connected to UART0.

(BTW just in case anyone is reading this thread without being aware, ESP32-S3 has three hardware UARTs so you should be able to use both UART1 and UART2 without running into this problem. A custom build should only be needed if you're using all three.)

[wangshujun-tj]

thonny在连接到micropython设备时，有一些操作，比如校正时间，还加入了一些驻留的后台程序，这时重定向会有问题

[projectgus]

When Thonny connects to a MicroPython device, there are some operations, such as correcting time, and adding some resident background programs, which can cause redirection issues

(Baidu Translate of the above post, as GitHub somehow still doesn't have a translate button.)