Bug in nRF UARTE driver, async Rx buffer handling

RE: Bug in nRF UARTE driver, async Rx buffer handling

Kazi Afroza Sultana — Mon, 20 Jul 2026 16:04:48 GMT

Hello,

Thanks for sharing the fix of this bus fault issue.

I will report and let relevant team to know about this.

By the way, the github link does not show any information.

BR
Kazi

RE: Bug in nRF UARTE driver, async Rx buffer handling

BrotherBear — Fri, 17 Jul 2026 11:28:25 GMT

I found an issue with the same root cause (NULL async_rx->buf), but a more severe manifestation — and still present in NCS v3.3.0 / Zephyr 4.3.99.

We hit what looks like the same underlying defect described in this thread — async_rx->buf becoming NULL while the RX machinery still runs — but on the count-bytes-with-timer (cbwt) path and with a worse outcome. Instead of uart_rx_buf_rsp() returning -EACCES, the driver dereferences the NULL buffer and takes a precise bus fault.

Environment

nRF54L15, NCS v3.3.0 (Zephyr 4.3.99)
CONFIG_UART_ASYNC_API=y, cbwt path active (CONFIG_UARTE_NRFX_UARTE_COUNT_BYTES_WITH_TIMER — DT node has a timer property + frame-timeout support)
9600 8N1, no hardware flow control; the attached device begins streaming bytes at power-up
Low-power RX off; RX enabled once and left running; two ping-pong buffers handed back via uart_rx_buf_rsp() from UART_RX_BUF_REQUEST

Trigger (different from the high-baud / short-timeout case in this thread): we hit it when uart_rx_enable() is called on a line that is already receiving bytes (a peripheral that streams immediately at power-up). It is intermittent — only a minority of resets. Delaying RX-enable until the line is idle hides it, consistent with the NULL-buffer window being entered when the first buffer completes almost immediately at enable.

Fault (captured against the exact flashed ELF)

***** BUS FAULT *****
  Precise data bus error
  BFAR Address: 0x2
r0/a1:  0x00000002   ...   r14/lr: 0x00011403
EXC_RETURN: 0xfffffff1        (fault taken in handler / ISR mode)
Faulting instruction address (r15/pc): 0x00024b56
FATAL: reason 25 (K_ERR_ARM_BUS_PRECISE_DATA_BUS)

addr2line against the flashed ELF:

$ arm-zephyr-eabi-addr2line -f -i -e zephyr.elf 0x24b56 0x11402
memcpy
??:?
fill_usr_buf
zephyr/drivers/serial/uart_nrfx_uarte.c:1113

So the PC is the memcpy byte-copy store, called from fill_usr_buf(), and the memcpy destination register is 0x2, i.e. &async_rx->buf[usr_wr_off] with async_rx->buf == NULL and usr_wr_off == 2 (hence BFAR = 0x2). The fault is taken in ISR context (EXC_RETURN 0x...f1).

Root cause (cbwt path)

fill_usr_buf() copies into the user buffer with no NULL check:

/* uart_nrfx_uarte.c:1106 */
memcpy(&async_rx->buf[cbwt_data->usr_wr_off], &buf[cbwt_data->bounce_off], cpy_len);

async_rx->buf can be NULL here for exactly the reason described in this thread — notify_rx_rdy() shifts async_rx->buf = async_rx->next_buf (uart_nrfx_uarte.c:1010), which is NULL if no next buffer was supplied in time. The drain paths that reach update_usr_buf() → fill_usr_buf() (the timer byte-count ISR and the RX timeout) do not guard against a NULL async_rx->buf; only cbwt_rxto_isr() does (if (async_rx->buf), uart_nrfx_uarte.c:1441 and :1445).

In other words, the -EACCES from uart_rx_buf_rsp() reported here and this bus fault look like two faces of the same NULL-buffer window: the buf_rsp path returns an error, but the cbwt drain path dereferences the NULL instead.

Suggested fix

Mirror the guard cbwt_rxto_isr() already has: bail out of update_usr_buf() / fill_usr_buf() (skip the memcpy and the buffer-full handling) when async_rx->buf == NULL, so a drain event that lands in the "buffer released, next not yet supplied" window is a no-op instead of a NULL dereference.

Happy to share the full ESF dump and a minimal reproducer. I've also opened a Zephyr GitHub issue for the driver fix: github.com/.../113812.

RE: Bug in nRF UARTE driver, async Rx buffer handling

Kazi Afroza Sultana — Thu, 28 May 2026 13:12:35 GMT

Hello,

it is fixed here https://github.com/nrfconnect/sdk-zephyr/commit/7979d37f42b23e50cf0999fbf714414ab3c54317

RE: Bug in nRF UARTE driver, async Rx buffer handling

sread — Tue, 26 May 2026 19:54:31 GMT

Hello, any update on this issue?

We had been working around a similar issue by enabling HW byte counting Kconfigs but were not able to use this with sdk-nrf version v3.2.4.

RE: Bug in nRF UARTE driver, async Rx buffer handling

Kazi Afroza Sultana — Fri, 07 Nov 2025 09:09:32 GMT

Hello,

we are working on this bug. I will let you know if there is an update.

RE: Bug in nRF UARTE driver, async Rx buffer handling

Tom Weber — Fri, 31 Oct 2025 15:46:20 GMT

Same here. I increased the timeout to 200 us (about 20 bytes) as a workaround.

RE: Bug in nRF UARTE driver, async Rx buffer handling

ahmed-dl — Fri, 31 Oct 2025 11:30:00 GMT

Hi, is there any work towards fixing this bug? We are using high baudrate of 1M without flow control and low timeouts of 100us and see this problem. When increasing the timeout to 1ms we don't see this problem anymore.

RE: Bug in nRF UARTE driver, async Rx buffer handling

ahmed-dl — Fri, 31 Oct 2025 10:42:53 GMT

I'm currently experiencing the same bug when using no HW flow control. I also saw that the problem goes away when using higher timeouts.

Did you find a better workaround or solution for this problem?

RE: Bug in nRF UARTE driver, async Rx buffer handling

Kazi Afroza Sultana — Wed, 24 Sep 2025 12:24:33 GMT

Hello,

It looks like a bug in the driver; the driver intentionally handle the ENDRX first before UART_RX_BUF_REQUEST (RXSTARTED event) for other reasons. In case of short buffer that event order may happen and that is unexpected. I think you have used high baud rate?

RE: Bug in nRF UARTE driver, async Rx buffer handling

Tom Weber — Mon, 15 Sep 2025 11:02:02 GMT

What baud rate and Rx timeout are you using?

My workaround for now is to use a longer timeout, it means the bug will not get triggered.

RE: Bug in nRF UARTE driver, async Rx buffer handling

helpfulchicken — Sat, 13 Sep 2025 22:59:15 GMT

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.

RE: Bug in nRF UARTE driver, async Rx buffer handling

Kazi Afroza Sultana — Mon, 25 Aug 2025 14:11:01 GMT

Hello,

The UARTE peripheral on Dks is known to have limitations in signaling partial buffer fills. I am not aware if we have some woraround for nRF54L15.

I have asked team. I will come back to you later.

Thanks.

Kazi