PLS83-W Stops Responding | Telit Cinterion IoT Developer Community
August 19, 2022 - 7:35am, 599 views
We are looking to replace our PLS62-W modem with a PLS63-W or PLS83-W. During testing of the new modems, we have occasional seen the modems stop responding while on an active TCP call. When this happens, we cannot send any AT commands until the modem is restarted. We're using the same host board as our PLS62-W units, of which we have more than a thousand units running without issue.
Here's a simplified log of what we see. You'll see the modem start up and our connection get established. In this case the TCP connection is OK for 25 minutes, sending around 1 MB per minute and maintaining a moderate temperature around 42 degrees.
For no apparent reason we then see the modem assert its flow control line and stop responding. We turn off the DTR line to try and drop the data connection, but still no response. After 10 seconds we restart the modem and finally see CTS return to active and the modem start responding again.
^SYSSTART
AT&f
OK
ATI1
Cinterion
PLS83-W
REVISION 01.202
A-REVISION 01.000.04
OK
AT^SSET=1
OK
^SSIM READY
AT&S1
[DSR Off]
OK
AT+CPIN?
+CPIN: READY
OK
+CIEV: prov,1,"ROW_Generic_3GPP*"
AT^SICA=1,1
OK
AT^SISS=0,"srvType","Socket"
OK
AT^SISS=0,"conId","1"
OK
AT^SISS=0,"address","socktcp://***.***.***.***:***x;etx"
OK
[DTR On]
^SISW: 0,1
AT^SIST=0
CONNECT
[DSR On]
Online for 25 minutes. Sent 26 MB. Modem temperature 42 degrees. Modem voltage 3.8 V
[CTS Off]
[DTR Off]
[Delay 10 sec]
[Restart Modem]
[CTS On]
[Power Indicator Off]
[Power Indicator On]
^SYSSTART
This is not happening that often, but it is a concern that we'd like to address before switching modems. Do you know of any reason this could be happening, or if there is a newer version of firmware?
Thanks,
Tim
Hello,
Could you write some more information - which port is used for the data transmission? O which interface you tried to send AT commands?
Did you try to wait longer to check what happens?
Please also check the state of V180 line when this happens.
Best regards,
Bartłomiej
Thanks for the reply. To answer your questions:
- We are using ASC0 for the data connection. We also have ASC1 open for periodic status checks and ACM0 available over an external USB port. When the lock up occurs, the modem is also unresponsive over ASC1 and USB.
- We have waited longer and the modem does not appear to recover on its own. Under normal usage when we want to drop the connection we simply turn off the DTR line, which causes the modem to exist data mode. In this unresponsive state, the modem does not respond when we turn off DTR.
- Unfortunately, I don't have access to V180. I am monitoring the modem's CTS and DSR lines, and the modem power indicator, and only the CTS line changes when entering this non-responsive state.
I saw a V2 firmware mentioned on a recent firmware update. Is this something we can expect for this modem, or is that for a future hardware revision?
Hello,
So it seems that not only one interface is affected. If you waited for a few minutes (let's say 2-3) without any change, probably the reboot is the best solution. I think that some debug module traces would be necessary to further investigate it. So I would recommend you to report it to your FAE or distributor or directly to our support system.
The firmware that you have is the latest rel. 1.2 official version.
Best regards,
Bartłomiej
Hi Bartłomiej,
We have found a way to reliably reproduce this lock up.
1) Establish a transparent TCP socket on ASC0
2) Repeatedly send 1 byte packets with a gap of 0.2ms between bytes
3) No bytes are sent on the socket
4) The modem soon asserts CTS and becomes unresponsive
This also happens with larger packets, up to around 100 bytes, but with slightly longer delays between blocks. So it seems that if you interrupt the modem's stack at a certain point, it fails to send and then runs out of space.
I think this should be quite easy to reproduce, and hopefully the engineers can find a problem. We are working around this issue by adding a short delay after sending, and will see if this also addresses our original issue of lockups in the field.
Regards,
Tim