Is lockout of uart0 intentional?

[kbanks-krobotics]

This is on esp32s2 build, Saloa_1_WROOM board but likely applies to others.
I don't have the code in front of me, but roughly:

import board
import busio

uart = busio.UART(board.TX, board.RX, baudrate=115200)

It complains about the RX pin being busy.

Thinking you might at least be able to transmit, you try

uart = busio.UART(board.TX, None, baudrate=115200)

Now it complains about the TX pin being busy.

In ports/esp32s2/boards/espressif_saola_1_wroom/board.c there are these two lines:

// Debug UART
common_hal_never_reset_pin(&GPIO_43);
common_hal_never_reset_pin(&GPIO_44);

If you build with these two lines commented out, then you can access the UART from Python as expected (TX and RX both work over the debugger/bootloader serial port).

What is the reason for the "never_reset_pin" calls?

Should I have tried to instantiate the UART a different way?
(What is the normal/correct way to leverage that extra serial port?)

[skieast]

I'm wondering if its so you can log through a circuitpython reset from modules internal to circuitpython. The native esp logging facility sends everything out here. When I connect to these pins i see the esp32s2 bootup and debug messages (if enabled in the build)

[tannewt]

This isn't intentional. I think we'll want to guard that with #ifdef DEBUG because that's when we enable UART logging for the IDF.

[kbanks-krobotics]

That seems reasonable. If you explicitly turn on DEBUG logging, don't allow Python to "steal" the UART, but otherwise allow it.

[BennyE]

Hi @kbanks-krobotics , if you navigate through the latest builds and choose d076296 or d6ee17c from "Absolute Newest" on Amazon S3 - you can validate the above merged fix. :)

[tannewt]

This should be fixed by #3817. Thanks @BennyE