RE: RXTO not generated by Bluetooth LE UART service application. SDK v3.3.0

Susheel Nuguru — Mon, 01 Jun 2026 17:44:23 GMT

I am glad to be of some assistance, Jakub.

RE: RXTO not generated by Bluetooth LE UART service application. SDK v3.3.0

JakubSlota226 — Mon, 01 Jun 2026 09:56:17 GMT

Hello Suheel,

Thank you very much for the response! We'll use the option you suggested.

Best Regards,
Jakub

RE: RXTO not generated by Bluetooth LE UART service application. SDK v3.3.0

Susheel Nuguru — Fri, 29 May 2026 20:30:11 GMT

Hi Jakub,

Your diagnosis seems correct. This is a real race in the sample, not in your code. Calling uart_rx_disable() from UART_RX_RDY while still answering UART_RX_BUF_REQUEST with a fresh buffer races the driver's state machine: the new buffer rescues the receive operation that was about to stop. On older UARTE blocks the timing usually hid this; on the nRF54L15 the ordering is tighter, so it surfaces.

I would go with the if (disable_req) return; guard in UART_RX_BUF_REQUEST. Place it at the very top, before the k_malloc. Not responding to the buffer request is the documented Zephyr way to end reception: the driver completes the current buffer, fires UART_RX_BUF_RELEASED (your handler already pushes it to the FIFO), then fires UART_RX_DISABLED cleanly. Putting the guard before the allocation avoids leaking a buffer on the stop path.

Deferring uart_rx_disable() to a work item also works, but it does not fix the root cause. You still need a disable_req guard in UART_RX_RDY, and you add a context switch for no real benefit. The early-return in UART_RX_BUF_REQUEST is the cleaner change.

I will raise this internally , thanks for brining this to light.