UART receive in 5.5.1 not working ?

[TerryBarnaby]

Hi,

I am working on code that is running on a Waveshare ESP32-S3 4.3. This has the ESP32-S3 CPU on it. In general I have things working well while using IDF 5.4.2 with lvgl display, I2C touch and RS485 communications at 9600 Baud. However there were some occasional issues (crashes, probably due to threads and memory issues) and I thought I would try IDF 5.5.1 marked as the latest stable release. In general my program works with 5.5.1 (GUI displays etc) but there is no RS485 reception over the UART at all, no bytes received.

To test I tried building and using the simple uart_echo_rs485 example, modifying it a touch to just transmit a short string or receive a short string from another system at 9600 Baud. When built with IDF 5.4.2 everything works fine. With IDF 5.5.1 sending from the ESP32 to the remote system works fine, but on receive I do get bytes, but I get random bytes, even if the remote side isn't sending anything. I get as shown below, 23 bytes received immediately, then random lengths no matter if my remote program is sending or not.

I am using a GIT IDF download on Fedora41.
Is the UART driver actually working in 5.5.1 (I also tried 6.0 and that failed as well) ?

Code: Select all

while (1) {
        //Read data from UART
        int len = uart_read_bytes(uart_num, data, BUF_SIZE, 2000 / portTICK_PERIOD_MS);
	
	printf("Read: len: %d first bytes: 0x%2.2x '%c'\n", len, data[0], data[0]);
	printf("Hexdump: "); bhd8(data, len);
}

Code: Select all

I (286) RS485_ECHO_APP: UART start receive loop.
I (296) main_task: Returned from app_main()
Read: len: 23 first bytes: 0x00 ''
Hexdump: 00 df a7 ef 98 01 88 f7 7d a8 30 9b 04 fe 11 bd 
5b 29 46 9c 52 05 e9 
Read: len: 10 first bytes: 0x0a '
'
Hexdump: 0a c6 3c 11 ce 85 86 ce 94 21 
Read: len: 7 first bytes: 0x62 'b'
Hexdump: 62 c6 74 10 8e 18 fd 
Read: len: 6 first bytes: 0x0a '
'
Hexdump: 0a 85 94 38 90 fc 
Read: len: 6 first bytes: 0x14 ''
Hexdump: 14 c6 97 98 21 f6 
Read: len: 6 first bytes: 0x62 'b'
Hexdump: 62 91 9d 29 a4 fc 
Read: len: 5 first bytes: 0x0a '
'
Hexdump: 0a 85 94 18 10 
Read: len: 6 first bytes: 0x14 ''
Hexdump: 14 c6 97 98 21 fc 
Read: len: 6 first bytes: 0x62 'b'
Hexdump: 62 91 9d 29 a4 fc 
Read: len: 5 first bytes: 0x0a '
'
Hexdump: 0a 85 94 18 10 
Read: len: 6 first bytes: 0x14 ''
Hexdump: 14 c6 97 98 21 fc

[TerryBarnaby]

One thing to note is that the Waveshare ESP32-S3 4.3 hardware uses the following pins for RS485:

RS485_RX: GPIO43
RS485_TX: GPIO44

It has a hardware circuit so no RS485 TX enable line is needed.
In the ESP32-S3 documentation under pinmux, it does say these lines could be used for debugging over U0 (with reversed pins).

[TerryBarnaby]

I have narrowed my issue down to a change in the function uart_set_pin() in esp_driver_uart/src/uart.c from 5.4.2 to 5.5.1.
If I replace the uart_set_pin() in 5.5.1 with the 5.4.2 version the uart_echo_rs485 test example program (with my mods) works fine with UART RX.

Specifically if I add the gpio_func_sel() call from 5.4.2 after the io_reserve_mask statement on line 871 like:

Code: Select all

            io_reserve_mask &= ~BIT64(rx_io_num); // input IO via GPIO matrix does not need to be reserved
            gpio_func_sel(rx_io_num, PIN_FUNC_GPIO);

Then the 5.5.1 UART driver works for RX on by system.
Now I am not conversant with the ESP32 IDF, so anyone any idea on what may be happening and/or is this a bug in the 5.5.1 (and later 6.0) code ?

[volcore]

Thanks for the detective work! I was running into the same issue. Interestingly, on the RX pin I was reading back whatever I wrote on the TX pin. It worked in v5.2.1, and then broke on some of our boards with this specific pin out with v5.5.1.

Thanks to you, ended up fixing it like this:

Code: Select all

  auto err = uart_param_config(uart_num, &uart_config);
  if (err != ESP_OK) {
    Debug::Error(kLogTag, "Failed to configure UART%d: %d", uart_num, err);
  }
  // Fix UART0 issues on 5.5.1
  if (uart_num == UART_NUM_0) {
    gpio_reset_pin(rx_pin);
    gpio_set_direction(rx_pin, GPIO_MODE_INPUT);
    gpio_iomux_in(rx_pin, U0RXD_IN_IDX);
  }

Hopefully fixed in future SDK versions.