"\r\n" will crash the modem

[Siyou]

Hi 

We found the modem will crash when host issuing below commands to it:

"\r\n", "\r\r\n", "\n\r\n"

how to avoid this?

[Didrik Rokhaug]

Hi.

How do you know that the modem crashed?

What application was running on the application core?

Are you able to capture a modem trace?

How are the "commands" sent to the modem? Over UART via the at_client sample or at_host library? From the application using the at_cmd library? From the application using sockets directly?

Does it only happen when you end the "commands" with '\n', or does it also happen when you end them with '\r'?

If you do not know how to take a modem trace, you can follow this guide: https://devzone.nordicsemi.com/nordic/cellular-iot-guides/b/getting-started-cellular/posts/how-to-get-modem-trace-using-trace-collector-in-nrf-connect

Best regards,

Didrik

[Siyou]

Hi,

we tested it base on serial_lte_modem sample.

when we issuing AT cmd like "AT+CFUN?\r\n\r\r\n" or "AT+CFUN?\r\n\n\r\n" or "AT+CFUN?\r\n\r\n\r\n" (that is "\r\r\n", "\n\r\n" or "\r\n\r\n"), the modtem will not accept any command after these commands finished.

[Didrik Rokhaug]

After some testing, it seems like the problem is on the application side.

The logic that forwards the AT commands to the modem seems to be confused when \r and \n are mixed. It should handle a long string of \r followed by a long string of \n.

But, when it receives its "termination mode character" it will send what it has to the modem. The rest of the command will be interpreted as a separate command and sent to the modem by itself.

The application then gets stuck waiting for a response from the modem.

I have reported this internally.

For now, I would recommend that you don't mix \n and \r and don't send more than one "termination character" per command.

[Siyou]

Understand, thanks!