Zephyr uarte library missing UART_RX_BUF_RELEASED events

[Kyrre Aalerud]

I run newest nRF53 chip as of writing with 1.6.0 nRF Connect SDK from nRF Connect Toolchain manager 3.6.1 using SES 5.50c.

I use a array of 5 rx-buffers (Increased from 3 to figure out what was going on) and handle UART_RX_BUF_REQUEST and UART_RX_BUF_RELEASED events in the registered callback.
Most of the time it runs fine but during a continuous test I notice that at random intervalls it may skip a UART_RX_BUF_RELEASED event which leads my application to detect a request of using a buffer that is not yet freed. If these buffers had been allocated dynamically this would have caused a memory leak. Instead I catch it and log it while actually allowing the reassigning of already assigned buffer.

Since I use the buffers round-robin and process data (transfer to other threads) during any UART_RX_RDY events I do not miss data but this behavior is worrying.
Is there a race-condition in the library?

[Susheel Nuguru]

Hi Kyrre,

Sounds very much like a race condition. I need to understand more about the chain of events that happened before digging into the code. Could you please help me understand with these questions.

1. Your application seems to be tracking which buffer is free and not instead of relying solely on these events. Is it possible that the application tracking logic might have a race condition? Could you rule that out?
2. Could you provide me the chain of UART events that are received by your application (a log file with a way to see EVENTS/buffer mapping would help).
3. What other application peripheral interrupts are enabled and being used when your application detected that a request arrived for a buffer that is not yet free?

[Kyrre Aalerud]

For info, we have discovered some other anomaly with the rx events and the timeout system.

It appears that if a stream of data is received, spanning multiple rx buffers, depending on timing for processing the rx event caused by the first buffer end being reached, if the transmission stops in the second buffer during this time (speculation) an rx even based on the timeout may not be generated. Result is remaining data from the burst reception may sit in the second rx buffer and not generate any event. Only when a new burst of data (1 or more bytes) arrives later will the rx event be generated and it will also contain the missing data from the previous transmission.

When using a internal timeout to resynchronize packets this creates a very bad situation.

[Susheel Nuguru]

Kyrre Aalerud said:

if the transmission stops in the second buffer during this time (speculation) an rx even based on the timeout may not be generated.

 I think this should be the source of all the issue. If at any instance we can see that the timeout event is missing and did not fire at all, then that is a bug in the driver itself. The only issue before creating an internal ticket is that we need to prove it.