Unexpected UART errors on nRF54L15

[Konstantin Klitenik]

Summary

We are running on an nRF54L15 and receiving continuous NMEA output from a GNSS module over UART using UART ASYNC. After some time (30 minutes to hours) of normal operation, we intermittently hit:

Receive stopped for reasons: 4

Once it occurs, GNSS tracking/data reception halts because the UART is disabled. Looking at the logic analyzer, the RX data looks correct and logic analyzer is not flagging any errors (see images below). The GNSS module continues to send NMEA data.

Key observation: the event tends to happen right when there is an 8-10ms ms idle gap between two RX message bursts (NMEA sentences). Long continuous streams (no gap) can run indefinitely without errors. So this doesn't seem like clock drift See images below.

System Setup

SoC: Nordic nRF54 (exact SKU: [fill in: nRF54H20 / nRF54Lxx], dev kit or custom board)

SDK/RTOS: nRF SDK v3.2.1

UART peripheral: UARTE instance uart30 (see dts and pinctrl snippets below)

UART mode: Asynchronous UART API

UART settings used: 115200 baud, 8 data bits, no parity, 1 stop bit (8N1), no hardware flow control.

GNSS module: Telit SE868, driver based on modified `zephyr/drivers/gnss/gnss_quectel_lcx6g.c`

Current Configuration (relevant)

CONFIG_UART_ASYNC_API=y

CONFIG_UART_30_ASYNC=y

CONFIG_UART_30_INTERRUPT_DRIVEN=n

CONFIG_MODEM_BACKEND_UART_ASYNC_RECEIVE_IDLE_TIMEOUT_MS=30

CONFIG_PM_DEVICE_RUNTIME=y

CONFIG_PM_DEVICE_RUNTIME_DEFAULT_ENABLE=y

CONFIG_PM_DEVICE_RUNTIME_ASYNC=y

CONFIG_PM_DEVICE_RUNTIME_USE_DEDICATED_WQ=y

While PM RUNTIME is enabled, GNSS module power is requested on startup and it is never suspended.

Logic analyzer observations

We captured the UART around the failure with a logic analyzer triggered by a GPIO that toggles when we detect UART_RX_STOPPED. UART waveform and decoded bytes look normal around the trigger point (no visible line glitches, clean start/stop bits at 115200). Despite that, the driver reports reason=4.

Error happens 8 bytes in:

There was another NMEA message that ended 8.9ms before. Start of pervious message to when the error happens is 15ms.

This trace was a whole second earlier and it shows successfully processing many bytes without errors. It includes 2 successive NMEA messages.

What we’ve tried/verified

• Verified GNSS UART configuration and stable NMEA output.
• Logic analyzer shows clean UART at the pin (decoded data matches expected sentences) when the error fires.
• Confirmed the failure correlates with 8-10 ms idle gaps (we've seen 8.5ms, 9.5ms, 9.2ms); longer continuous streams do not show errors.

Device tree snippet for uart30 + pinctrl states (default/sleep):

&uart30 {

  compatible = "nordic,nrf-uarte";

  status = "okay";

  current-speed = <115200>;

  pinctrl-0 = <&uart30_default>;

  pinctrl-1 = <&uart30_sleep>;

  pinctrl-names = "default", "sleep";

  gnss: se868 {

    compatible = "telit,se868";

    status = "okay";

    pps-mode = "GNSS_PPS_MODE_DISABLED";

    mdm-power-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;

    mdm-reset-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;

  };

};

uart30_default: uart30_default {

  group1 {

    psels = <NRF_PSEL(UART_TX, 0, 1)>;

  };

  group2 {

    psels = <NRF_PSEL(UART_RX, 0, 0)>;

    bias-pull-up;

  };

};

uart30_sleep: uart30_sleep {

  group1 {

    psels = <NRF_PSEL(UART_TX, 0, 1)>,

            <NRF_PSEL(UART_RX, 0, 0)>;

    low-power-enable;

  };

};

 

[Vidar Berg]

Hello,

Please have a look at the additional driver configurations covered in the SDK documentation here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/drivers/uart.html#reliable_reception. This test also show how you can add a timer instance to your uart devicetree node: https://github.com/nrfconnect/sdk-zephyr/commit/64b7cabd61cd69dda6bbd8df50eda48c2168559a 

Best regards,

Vidar

[Konstantin Klitenik]

Before I go down this solution route, I want to clarify:

1. The link suggests that it's due to buffer swap, which may be triggered by CONFIG_MODEM_BACKEND_UART_ASYNC_RECEIVE_IDLE_TIMEOUT_MS (30ms, in our case). However, the error occurs 15ms since the start of the first reception (and only 9ms of idle)

2. Here's a recording of a continuous 44ms reception with no errors.

What I would like to understand is the explanation for the error that seems to be caused by the short 9ms idle period. What in the config causes the buffer swap to start if full idle timeout hasn't been reached?
 

[Vidar Berg]

Hello,

On the nrf54L we are using the FRAMETIMEOUT register to set the timeout, and this maxes out at 10 bits (1024 bauds). At 115200 that is 8.88 ms which seems to align with your observations.

Best regards,

Vidar