SLM modem sometimes doesn't process AT#XSEND

RE: SLM modem sometimes doesn't process AT#XSEND

Konstantin Klitenik — Fri, 14 Nov 2025 21:07:20 GMT

That seems to have fixed it. I'll keep monitoring to see if the issue comes back.

Please make sure this config makes it into the new SLM repo: https://github.com/nrfconnect/ncs-serial-modem

Thanks.

RE: SLM modem sometimes doesn't process AT#XSEND

Øyvind — Wed, 12 Nov 2025 07:37:25 GMT

Hello,

do you have the following settings in prj.conf? If not could you please try adding and test your application?

CONFIG_UART_2_NRF_HW_ASYNC_TIMER=2
CONFIG_UART_2_NRF_HW_ASYNC=y

Kind regards,
Øyvind

RE: SLM modem sometimes doesn't process AT#XSEND

Konstantin Klitenik — Mon, 10 Nov 2025 22:38:49 GMT

I don't have traces but I did more digging and it seems to be related to the timing between sending AT#XSEND and the EOL (\r\n). Zephyr's `modem_cmd_handler.c` handles this as 2 writes

iface->write(iface, buf, strlen(buf));

iface->write(iface, data->eol, data->eol_len);

So, depending on what else is happening in the application, there could be a meaningful delay between the two. I noticed that when the delay is right around 2ms, the last byte of the EOL (\n) is missed.If the delay is shorter or longer (>3ms), then everything works fine. 2ms just happens to be the UART_RX_TIMEOUT_US on the SLM.

In this case, note that the logic analyzer shows \r\n being sent. But only \r is received. I'll post the AI assessment of the UART issue below.

AI assessment:

The Race Condition

When the delay is just over 2ms:

First part of command arrives (e.g., AT#XSEND=...)

Timer starts counting down from 2000us

At ~2000us: timeout fires → rx_timeout() executes

At ~2000us: RXDRDY is checked → likely false (no new byte yet)

At ~2001us: \n byte arrives on UART line

At ~2001us: STOPRX is triggered (from step 4)

Result: \n may be missed because:

It arrives after the timeout check

STOPRX may interrupt an in-flight byte

The ENDRX event may fire before \n is fully received

Why Shorter/Longer Delays Work

Shorter delay (< 2ms): All bytes arrive within the timeout window → batched together → \n included

Longer delay (>> 2ms): First part times out and is sent → \r\n arrives later as a separate transmission → gets its own event

RE: SLM modem sometimes doesn't process AT#XSEND

Øyvind — Mon, 10 Nov 2025 15:43:43 GMT

Hello,

From the added HOST (nrf54) logs we can see the following:

[00:00:17.735,136] <wrn> comms: Not connected to AWS, waiting 5 seconds
[00:00:18.192,960] <err> modem_nrf91: AT#XSEND failed or timed out (err -116)
[00:00:18.192,992] <err> net_sock_tls: TLS handshake error: -0x4e

Are you able to share modem traces from the nRF91, and full logs from both HOST and NRF91?

Thanks

Kind regards,
Øyvind