Great, thank you very much!

Hi,

Some news on this bug?

Thanks!

Ok, what exactly do you need to agree with me? What it's clear is that, sending about 60 frames per second of 8-byte each, this fails once before one minute:


timeout_ticks = 1;
int32_t rx_cnt = uart_read_bytes(m_uart_device.uartInstance, m_rx_buff, 256, timeout_ticks);


And without ANY other ...

I think I found the issue, I'd say it's a tick boundary race condition due to timing granularity. I send 60 frames per second, so the probability of getting this issue over 1 minute is high, but this could happen to anyone when "ticks_to_wait == 1" in the uart_read_bytes function, like in our case ...

Hi!

Our tick rate is 1000Hz:


#define CONFIG_FREERTOS_HZ 1000
#define configTICK_RATE_HZ CONFIG_FREERTOS_HZ
#define portTICK_PERIOD_MS ( ( TickType_t ) 1000 / configTICK_RATE_HZ )


And we have your "0" case into account in here:


timeout_in_ticks = (timeout_us) / (portTICK_PERIOD_MS * 1000 ...

More info: I found out that the function "uart_read_bytes" also returns when there is some UART error. I know the UART data is OK because as seen in the oscilloscope capture, the data is correctly parsed. But just to make sure it was not the case, I added this code:


uart_read_bytes(static_cast ...

Thanks for your fast response :)

Seeing this:


b) wait for exactly that length and only timeout if that couldn't be accomplished, returning whatever it has received?
Yes, b) is how it works.


I'm not sure if you understood exactly our problem. The previous quoted case is not our case, we are ...

Hi!

We are using an ESP32-WROVER together with ESP-IDF 5.3, and the problem is we are loosing some messages in a stress test due to a non-desired frame splitting, where it seems clear the ESP-IDF function is not respecting the desired RX timeout. What we do:

1) Check if the UART has some ...