We are working on implementing asynchronous variable-length UARTE reception using frame timeouts. However, we’re encountering an issue: when UART frames are transmitted with uneven spacing, and the interval between the end of one frame and the start of the next is close to the configured frame timeout, we experience framing errors and lose a few bytes.
We understand why this happens and also it seems that stopping and restarting the RX takes a few hundred microseconds. This makes it difficult to calibrate the frame timeout to a value that avoids framing errors reliably.
We’ve explored several workarounds, but none have been successful due to the following observations:
- The `
RXDRDY`event only indicates that a byte is present in the RX FIFO, which isn’t particularly useful at the application level. - The `DMA.RX.AMOUNT` register is only updated after the `
DMA.RX.END`event. - EasyDMA operates on word-length data, and any remaining bytes smaller than a word are not transferred to RAM, even after waiting for long. Stopping RX is required to flush these remaining bytes.
- Triggering the `
FLUSHRX`task appears to have no effect unless RX is stopped. We had hoped to use this task to retrieve remaining bytes on a frame timeout without stopping RX.
We’re aware that hardware flow control would solve this issue, and we would use it if we were designing a new product. However, we’re extending support for an existing product, originally built on the nRF52 series (uses UART without EasyDMA) to the new nRF54 series. Due to backward compatibility constraints, implementing hardware flow control is not a neat option for us.
Is there any reliable way to handle this without stopping RX, or are there alternative approaches we could consider for solving this differently?
