UART Async RX Latency When Using STOPRX Task on nRF5340

[manojv]

Hello,

I'm using the nRF5340 and have configured UART with EasyDMA to receive a variable number of bytes at 307200 baud. Our application has strict timing constraints, so we need to detect the end of a UART frame as quickly as possible.

To achieve this, I've implemented a timer that is reset on every RXDRDY event. If no new bytes are received within 50 µs, the timer triggers the STOPRX task to terminate the reception and signal the end of the frame.

While the timer logic works as intended, I’ve observed a significant delay between when STOPRX is triggered and when the ENDRX event is generated — up to 200 µs.

Upon reviewing the [nRF5340 Product Specification v1.6], I found a diagram that shows a "timeout" period between the STOPRX task and the ENDRX event. Here is a snapshot for reference:

This seems to explain the latency. Interestingly, I’ve found that this delay varies with baud rate — for instance, at 115200 baud, the delay increases up to 500 µs.

Questions:

1. Is the delay I'm observing directly caused by this documented timeout behavior?

2. Is there any way to reduce or eliminate this delay, so the data can be processed immediately after STOPRX is issued?

Thank you for your time and I would appreciate any guidance or workarounds.

Best Regards

[Håkon Alseth]

Hi,

 

Is the delay I'm observing directly caused by this documented timeout behavior?

Yes, there is a delay between the TASKS_STOPRX and the EVENTS_RXTO. This is to ensure any potential on-going transaction is completed before the UART receiver is fully stopped.

Is there any way to reduce or eliminate this delay, so the data can be processed immediately after STOPRX is issued?

Here's the chapter in question:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/uarte.html#ariaid-title5

 

You need to wait, as shown in the figure that you shared, and later on in the low power chapter:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/uarte.html#ariaid-title12

 

Kind regards,

Håkon

[manojv]

Hello Håkon,

Thank you for your response.

I do have a couple of follow-up questions:

1. In our setup, the delay from issuing STOPRX until ENDRX is generated is typically around 200 µs, which unfortunately exceeds our timing requirements. Is there any way to mitigate or reduce this latency, even partially?

2. You mentioned that this delay ensures any “potential on-going transaction” is completed before stopping the receiver. Could you elaborate on what qualifies as an “on-going transaction”? In my tests, the delay is consistently ~200 µs regardless of how long I wait after the last received byte before issuing STOPRX. Shouldn’t the receiver already be idle by then?

Additionally, I noticed that the documentation link you shared refers to the nRF54L15 product. Was that intentional, or should I refer instead to the nRF5340 documentation for this behavior?

Best regards,
Manoj

[Håkon Alseth]

Hi,

 

My apologies for the incorrect device link! I got my tabs mixed up, unfortunately. The UARTE peripheral in the different nRF52/53/54 devices is very similar in behaviour.

manojv said:

In our setup, the delay from issuing STOPRX until ENDRX is generated is typically around 200 µs, which unfortunately exceeds our timing requirements. Is there any way to mitigate or reduce this latency, even partially?

Unfortunately, the sequence is required, as stated in the datasheet:

https://docs.nordicsemi.com/bundle/ps_nrf5340/page/uarte.html#ariaid-title8

 

manojv said:

You mentioned that this delay ensures any “potential on-going transaction” is completed before stopping the receiver. Could you elaborate on what qualifies as an “on-going transaction”? In my tests, the delay is consistently ~200 µs regardless of how long I wait after the last received byte before issuing STOPRX. Shouldn’t the receiver already be idle by then?

The timeout scales accordingly towards the configured baudrate. As described in the datasheet, it can read up to 4 bytes during the timeframe from TASKS_STOPRX to EVENTS_RXTO has occurred:

UARTE can receive up to four bytes after the STOPRX task has been triggered, if these are sent in succession immediately after the RTS signal is deactivated.

This is the major contributor to the overall delay that you're seeing.

 

Kind regards,

Håkon