ESP-IDF v5.3 UART glitch (IDFGH-13373)

[andreyvoronko]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3

Espressif SoC revision.

ESP32

Operating System used.

macOS

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

Development Kit.

Custom board

Power Supply used.

External 3.3V

What is the expected behavior?

uart_driver_install(UART_NUM_1, UART_RX_BUF_SIZE * 2, 0, 0, NULL, intr_alloc_flags);
uart_param_config(UART_NUM_1, &uart_config);
uart_disable_tx_intr(UART_NUM_1);

uart_set_line_inverse(UART_NUM_1,UART_SIGNAL_TXD_INV); // inverse TX
uart_set_pin(UART_NUM_1, UART_GPIO_TX, UART_GPIO_RX, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);

What is the actual behavior?

The uart_set_pin function does not take into account the set inversion of the tx and rx pins. This causes a glitch (splash) to occur during initialization.

esp-idf/components/esp_driver_uart/src/uart.c

Line 743 in 41dd1a3

gpio_set_level(tx_io_num, 1);

Also, for the rx pin, it is necessary to have GPIO_PULLUP_ONLY or GPIO_PULLDOWN_ONLY set depending on the inversion.

esp-idf/components/esp_driver_uart/src/uart.c

Line 760 in 41dd1a3

gpio_set_pull_mode(rx_io_num, GPIO_PULLUP_ONLY);

Steps to reproduce.

...

Debug Logs.

No response

More Information.

No response

[songruo]

@andreyvoronko You are right, the driver didn't consider the signal inversion possibility in uart_set_pin. However, since the calling order of the two APIs, uart_set_pin and uart_set_line_inverse, is unknown, it is a bit hard to perfectly deal with the level at the pads.

For TX side, the gpio_set_level(tx_io_num, 1) was added to workaround an issue inside esp_rom_gpio_connect_out_signal ROM function on ESP32 and ESP32S2 (#12826 (comment)). We will take a look at if we can give a patch to the ROM function. If the ROM function behaves desirably, then gpio_set_level can be removed from the code.

For RX side, the pullup on the pad is weak. I guess it is fine to let the TX on the other side to drive it low if the signal is inversed. It shouldn't cause any problem.