ATCMD Stucked without return

Dear,

I am working with RG255C
I issue some at command such as

# atcmd 'AT+CPIN?'
smd port: /dev/smd11, at cmd: AT+CPIN?

^Z[5]+  Stopped                    atcmd "AT+CPIN?"

And got stuck until manually “ctr-Z” to terminate the process.

Please let me know how to fix this.

BR
MEQ

Seems like that it is not accessible,
Maybe you can try another smd port such as smd7/8/9.

Yes, it works with the new smd port.

However, it seems the connection got stuck after failing. It works back after reboot.
I don’t want to change my scripts every failure to connect. Is there any other way to reset/kill the failed connection?

smd is the Qualcomm share memory device.
If it failed, can you open another terminal and kill it?

Yes, killing the process is one way I have tried. But it is easy to get stuck, just for example as below.
I can’t develop the scripts in the way that retry with another line without knowing the error with using one.

Just let me know if you have any good way without killing processes.

root@OpenWrt:/# atcmd -p /dev/smd7 'AT+QCFG=?'
smd port: /dev/smd7, at cmd: AT+QCFG=?

AT+QCFG=?
+QCFG: "rrc",(0-5)
+QCFG: "pdp/duplicatechk",(0,1)
+QCFG: "risignaltype",("respective","physical")
+QCFG: "lte/bandprior",(1-43),(1-43),(1-43)
+QCFG: "diversity/config",(0,1),(1,2),(0)
+QCFG: "div_test_mode",(0,1)
+QCFG: "usbnet",(0-3)
+QCFG: "data_interface",(0,1),(0,1)
+QCFG: "pcie/mode",(0,1)
+QCFG: "wifi/model",("fc60e","fc08e","fc64e")
+QCFG: "sms_control",(0,1),(0,1)
+QCFG: "call_control",(0,1),(0,1)
+QCFG: "netmaskset",(0,1)[,<netmask>]
+QCFG: "clat",(0,1),(0,1),<prefix>,(0,32,40,48,56,64,96),<fqdn>,(0,1),(0,1,2,4,8),(0,1),(0,1),(0,1,2),(0,1,2)
[2]+  Stopped                    atcmd -p /dev/smd7 "AT+QCFG=?"

root@OpenWrt:/# ps w |grep smd7
  966 root      6572 S    /usr/bin/port-bridge smd7 mhi_pipe_32 1
 1057 root       664 T    atcmd -p /dev/smd7 AT+QCFG=?
 1136 root       664 T    atcmd -p /dev/smd7 AT+QCFG=?

stopped means that the proccess is stopped but not terminated.
You can try
kill -9 PID

It seems the current implementation is not applying timeout, right?

Normally there will only one proccess that open the smd port.
And the smd port is not uart feature fully implemented.

Thanks for your answers Bean.Wang-Q