• State Verified Answer
  • Replies 6 replies
  • Subscribers 74 subscribers
  • Views 552 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 346470
Options

nRF9160 SLM with SLM Shell communication issues

JackT

Hello everyone,

I previously posted about issues with SLM and the SLM shell, but I have made further progress. However, I now have a new problem.

I am still using the nRF9160DK and have tried with both the supported nRF53DK and added my files for the nRF54L15DK. both have the same results.

I can set up a UART and communicate with the nRF9160 modem via an external MCU.

I have changed the .overlay and .conf files on the SLM sample accordingly and followed the pinout mentioned in the SLM sample.

I can use some SLM commands like toggling GPIO so I can toggle the LED from the external MCU.

I can also use "slm AT+CFUN=1" to start the modem and see that a connection has been setup with "slm AT+CGDCONT?"

The problem is that when I try to use AT#XPING to test the connection it get an error.

Also setting eDRX or PSM settings gives an error as seen in in the code below.

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***

uart:~$ > slm AT+CFUN=1
slm AT+CFUN=1

OK

uart:~$ > slm AT+CGDCONT?
slm AT+CGDCONT?

+CGDCONT: 0,"IP","globaldata.iot","10.160.165.74",0,0

OK

uart:~$ > slm AT#XPING="5.189.130.26",45,5000,5,1000
slm AT#XPING="5.189.130.26",45,5000,5,1000

ERROR

uart:~$ > slm AT+CPSMS=1,,,"00000001","00000011"
slm AT+CPSMS=1,,,"00000001","00000011"

ERROR

uart:~$

On the nRF9160DK side I have connected the RTT to see more details.

Here the AT#XPING results in failed: -77.

and AT+CPSMS results in error type: 1

-77 indicates NRF_EBADMSG, which is not listed as one of the return values in the nrf_modem_at.h

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***
[00:00:00.255,187] <inf> at_cmd_custom: Custom AT commands enabled with 64 entries.
[00:00:00.260,955] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.260,986] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:00.260,986] <inf> fs_nvs: data wra: 0, 0
[00:00:00.497,924] <inf> slm: lib_modem init: 0
[00:00:00.497,985] <inf> mcuboot_util: Image index: 0, Swap type: none
[00:00:00.498,016] <inf> slm: Serial LTE Modem
[00:00:00.591,583] <inf> nrf_cloud_info: Device ID: 50525631-3738-4671-808a-1116e2648cee
[00:00:00.596,923] <inf> nrf_cloud_info: IMEI:      351901936411895
[00:00:00.689,270] <inf> nrf_cloud_info: UUID:      50525631-3738-4671-808a-1116e2648cee
[00:00:00.694,976] <inf> nrf_cloud_info: Modem FW:  mfw_nrf9160_1.3.7
m
[00:00:49.061,676] <err> slm_at_host: AT command failed: -77
[00:00:55.410,919] <err> slm_at_host: AT command error, type: 1

I have tried on both my nRF54DK and nRF53DK, with and without flow control. (I see that in NCS V3.1.0-preview1 SLM shell is now mentioned with flow control)

But I keep getting this error. When I change the overlay to slm-uart back to uart0 (so PC) and the pins in .conf, everything works fine when sending directly over uart 0 via PC. That is the only difference.

Has anybody got any idea what It could be?

Kind regards,

Jack

  • 0

    Hello Jack, 

    Could you share your SLM and SLM shell project for me to reproduce? This is only when sending commands over UART from e.g. nRF5340DK, but not when sending directly to nRF9160DK from PC?

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    I just copied the SLM and SLM shell from the NCSV3.0.1 examples. In the SLM SHell zip is also the nrf54l15 board files that i tried and the nrf53dk should be these orginal. 

     And yes PC works everytime. Sending from DK results in some commands working (ie. AT+CFUN=1) but others not (i.e. AT+CPSMS=1,,,"00000001","00000011" or AT#XPING)

     serial_lte_modem_1.zipslm_shell.zip

  • 0 in reply to JackT

    Hello, and thanks for sharing. I've had some more time to review the issue and this looks like an issue with the escape characters that are needed when sending these commands over UART. This is typical for the misc shell programs i.e. AT#XPING=\"5.189.130.26\",45,5000,5,1000

    Could you also include CONFIG_SLM_LOG_LEVEL_DBG=y in your SLM application?

    Kind regards,
    Øyvind

  • 0 in reply to Øyvind

    Yes, that was it! Many thanks! In the screenshot, you can see the first original message and after with the added \. I had a feeling it was something to do with a character, but I couldn't figure out which one. Debugging would have helped me here Sweat smile.

    Is this because of the terminal? 

    Or, if I send commands directly from code, do I need to add these backslashes as well?

    And are there any other escape characters I should be wary of?

    Also extra question, since in the newer V3.1.0 SLM and SLM Shell both mention with flow control, is this now recommended and maybe in the future required? my setup has no flow control, but does still work.

  • +1 in reply to JackT
    JackT said:
    Yes, that was it! Many thanks!

    I'm glad we were able to find the culprit! Happy to help! Slight smile

    JackT said:
    Is this because of the terminal? 

    No, this is part of the Shell, have a look at this Reddit thread

    JackT said:
    Or, if I send commands directly from code, do I need to add these backslashes as well?

    Yes, have a look at Sending AT Commands in our NCS documentation. 

    JackT said:
    Also extra question, since in the newer V3.1.0 SLM and SLM Shell both mention with flow control, is this now recommended and maybe in the future required? my setup has no flow control, but does still work.

    Could you please point me to where this is stated? The nRF9160DK has virtual serial ports that uses Request to Send (RTS)/Clear to Send (CTS)-style Hardware Flow Control (HWFC). This may be the reason it states this, and most likely actually include HWFC in your applications.

    Kind regards,
    Øyvind

Related
Terms of service