Zephyr async uart driver corrupts data on UARTE frame timeout

Related to the issue reported here:  RE: Framing Errors seen on nRF54L15 UART. Is it super sensitive to stop bit timing? 

If the UARTE FRAMETIMEOUT fires while new data is coming in then some bits of the new data is dropped, leading to corruption and potentially framing errors.

I've attached a loopback sample app that reliably reproduces this issue within seconds on the nRF54L15 DK. Simply connect a jumper wire between pins P1.11 and P1.12 then build and flash the image for the nrf54l15dk/nrf54l15/cpuapp board.

async_uart_echo.tar.gz

Parents
  • I had a similar issue (I think, I may be wrong in my understanding of your issue) where using the asynchronous UART driver I would get missed and corrupted bytes received.

    I stumbled on a solution to my issue in some sample code. 

    While using async UART API:

    CONFIG_UART_ASYNC_API=y
    CONFIG_UART_INTERRUPT_DRIVEN=n

    I would see corrupted and missed Rx bytes intermittently.

    I found that the issue went away if I added the following:

    CONFIG_UART_0_ASYNC=y
    CONFIG_UART_0_INTERRUPT_DRIVEN=n
    CONFIG_UART_0_NRF_HW_ASYNC=y
    CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2
    CONFIG_NRFX_TIMER2=y
    
    CONFIG_UART_1_ASYNC=y
    CONFIG_UART_1_INTERRUPT_DRIVEN=n
    CONFIG_UART_1_NRF_HW_ASYNC=y
    CONFIG_UART_1_NRF_HW_ASYNC_TIMER=3
    CONFIG_NRFX_TIMER3=y

    In my use case, I am using both uart0 and uart1.

  • Hello guys,

    I believe this is fixed in NCS 3.1 by enabling CONFIG_UARTE_NRFX_UARTE_COUNT_BYTES_WITH_TIMER. The drawback of this fix is that some dppi channels and timers are taken, and a bit higher power consumption (should be more or less +1-2% depending on CPU load).

    Regards,

    Elfving

Reply Children
Related