This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zephyr uarte library missing UART_RX_BUF_RELEASED events

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?

Parents
  • I upploaded an image with the packets colorized around where the timing issue happens here: https://ibb.co/FxHkKTs


    Each of the events are triggered in the driver which is running with 2ms on the timeout setting using 32 byte buffers to provoke it a bit.
    Data is sent as bursts (using dma from other mcu) of single packets with 20ms interval. After the last long packet there is a pause of 4.5 seconds before some shorter responses are sent and the long packets start again. The short packets are sent with 50 and 90ms intervalls and should have come as seperate clean rx events but it is like some internal alignment prevents this?

    Notice the RX timeout from my code discarding the end of the packet as it arrives 4.5s too late as part of next rx event triggered by the new shorter datapackets. Note the timestamps.

Reply
  • I upploaded an image with the packets colorized around where the timing issue happens here: https://ibb.co/FxHkKTs


    Each of the events are triggered in the driver which is running with 2ms on the timeout setting using 32 byte buffers to provoke it a bit.
    Data is sent as bursts (using dma from other mcu) of single packets with 20ms interval. After the last long packet there is a pause of 4.5 seconds before some shorter responses are sent and the long packets start again. The short packets are sent with 50 and 90ms intervalls and should have come as seperate clean rx events but it is like some internal alignment prevents this?

    Notice the RX timeout from my code discarding the end of the packet as it arrives 4.5s too late as part of next rx event triggered by the new shorter datapackets. Note the timestamps.

Children
Related