ESP32: calling uart_configure causes a falling- and raising-edge on the UART Tx Pin

[SamsonBox]

Describe the bug

Calling uart_configure on a ESP32 UART2 device causes a falling- followed raising-edge (negative pulse, white line in the picture) on the UART Tx line. This leeds, depending on the configuration of the receiver to a read of 0xFF. Also running the w1 protocoll, using the UART, is not possible. This negative pulse completly destroys the w1 protocol, as the baudrate need to be reconfigured between the reset and the normal operation.

Regression

• This is a regression.

Steps to reproduce

1. Use the ESP32 blinky example.
2. Add &uart2 { status = "okay";}; to the devicetree.
3. Add / {aliases {myuart = &uart2;}; to the devicetree.
4. Add #include <zephyr/drivers/uart.h> to the main.c.
5. Add #define DEV_UART DEVICE_DT_GET(DT_ALIAS(myuart )) before main.
6. Add struct uart_config uart_cfg; uart_cfg.baudrate = 9600u; uart_cfg.parity = UART_CFG_PARITY_NONE; uart_cfg.data_bits = UART_CFG_DATA_BITS_8; uart_cfg.stop_bits = UART_CFG_STOP_BITS_1; uart_cfg.flow_ctrl = UART_CFG_FLOW_CTRL_NONE; uart_configure(DEV_UART , &uart_cfg); in the main loop.
7. Use a logic analyzer or a oszilloscope observe the UART2 Tx Line (Tx2 on the devkit eval board)

Relevant log output

Impact

Major – Severely degrades functionality; workaround is difficult or unavailable.

Environment

• OS: Windows
• Toolchain: Zephyr SDK
• Commit: 2c851d9

Additional Context

"zephyr,w1-serial" driver is not working due to this.

[sylvioalves]

Which pins are you using? Is there any pull-up enabled (internal or external) for any reason?

[sylvioalves]

The reason why the TX pin is toggling happens because pin is reconfigured as you requested.
Pinctrl apply() is called, which triggers esp_rom_gpio_matrix_out(). The last one makes the pin in high-Z (...)
Before we proceed defining a patch, do you really need to call uart_configure() at all? What changes you need in the uart like baudrate or so?

[SamsonBox]

@sylvioalves Thank you for the quick answer.
I'm using UART2 on GPIO16 and GPIO17. No ther is no external pull-up. I don't have an internal pull-up configured, but I can't tell you if this in done by the esp32 uart layer.
The reason why uart_configure() is that the baudrate need's to be changed. actually I like to run a DS18b20 w1 teperatur sensor. This is a very common sensor. But I would like to run it via the uart implementation (drivers\w1\w1_zephyr_serial.c), not the bit bang implementetion. The later one disables the interrupts to hold the timing requirements. The uart implementation dosen't have this short commings. But it needs two baudrates. It uses a baudrate of 9600 for the bus reset and than switches to 115200 for the later communication. But any falling edge of the Tx initiates a transfer on the bus. So this completly detroys the protocol.

So comming from the API, the the uart_configure is called with a struct uart_config:

struct uart_config {
	uint32_t baudrate;  /**< Baudrate setting in bps */
	uint8_t parity;     /**< Parity bit, use @ref uart_config_parity */
	uint8_t stop_bits;  /**< Stop bits, use @ref uart_config_stop_bits */
	uint8_t data_bits;  /**< Data bits, use @ref uart_config_data_bits */
	uint8_t flow_ctrl;  /**< Flow control setting, use @ref uart_config_flow_control */
};

So these are the only parameters that can be changed during runtime. So I can imagine, that there is no need to change the complete gpio matrix every time. But not too deep into the chip and the zephyr API to judge this. But it would be nice to get the w1_zephyr_serial running.

[sylvioalves]

@SamsonBox Fix submmited.

[SamsonBox]

@sylvioalves It works. Thank you!