Unable to receive responses from PLS62-W when restarted | Thales IoT Developer Community
April 9, 2020 - 6:18pm, 1835 views
Hi,
I am currently using a Nordic microcontroller and developing with it an AT driver to control the PLS62-W to have it connect to a cloud service using MQTT.
I have manged to successfully establish effective communication between my micrcontroller and the modem using a serial link. I can send any AT command , receive modem responses and parse the responses appropriately.
However, my issue is that as soon as I send the AT+cfun=1,1\r command to restart the modem, I am unable to read any responses from the modem. I have made sure to send an AT\r after 20s for the modem to set the correct baudrate. After which I try to get response from the modem but with no luck. To make sure that the commands are being sent correctly, I have used a digital analyser. Strangely ,the Saleae logic analyser software shows the AT commands were sent properly with all the correct responses being sent back including all the startup strings below.
I am unable to receive "^SYSLOADING ","^SYSSTART ","+PBREADY" when the modem restarts. When I try to Printf characters received from the serial interface, its only shows empty blank lines.
Thanks
Hello,
Are you able to at least receive 'OK' to 'AT+CFUN=1,1' command? Do you use hardware flow control on both sides? I would suggest to monitor also different serial port lines than rx / tx - especially rts and cts. I assume you use autobauding feature (AT+IPR=0). Maybe you can for testing purpose set the module's baudrate that is used by your MCU? You can set it by AT+IPR command.
Are you able to connect the module to some other host, e.g. PC and repeat the test?
Best regards,
Adam
Hi Adam,
Yes I am able to receive 'OK' from the modem when I send the restart command 'AT+CFUN=1,1'. I do not use hareware flow control, and I have it disabled in the MCU. Can you please clarify which rts and cts lines to inspect? I am assuming the modems flow control wires.
I have setup a simple sniffer circuit to be able to see all serial exchange between the MCU and the modem using a FTDI TTL USB serial cable. The FTDI cable allows me to open a COM port in the PC, set the correct baudrate and see all the data being exchanged between MCU and the modem.
As stated before, after restart the modem sends all the start-up strings such as "^SYSLOADING " but the MCU is unable to see any of the output from the modem.
I have tried to set the baudrate using the 'AT+IPR=115200/r' command, after waiting 21s when modem restarts but with no luck. The MCU strangely seems to receive 'no' data even though there is definitely responses coming from the modem upon start-up. I have also tried to send 'AT/r' then use my get response function but with no luck (even though it works perfectly fine if AT commands are sent after the modem is ready).
I am trying to setup the MCU to wait for 'PBReady+', before commencing with initialising the PLS62-W modem and opening a TCP socket connection.
Thanks in advance
Hi,
Thanks for the answers! That's very strange...
Yes, exactly by rts and cts lines I mean flow control lines. Have you also disabled hw flow control on the module side? Could you please show response to AT&V command? What uart lines do you have connected between the MCU and the module? Only rx, tx and gnd? Or something more?
Regarding the baudrate change, I'm sorry for not being precise. What I meant is to send 'AT+IPR=115200/r' before module restart, when everything works fine. I think thanks to it we will see whether autobauding feature somehow influences on this issue.
Does your MCU perform some special operations after AT+CFUN command? Maybe it also reboots or changes some uart parameters?
Would it be possible to perform following test:
-send AT^SMSO to power the module down
-power on the module by Ignition signal.
I'm curious whether after this test you still will be able to communicate with the module.
Another question, maybe a bit silly. Have you considered a possibility that your sniffer has impact on this issue? Have you checked the behavior with the sniffer disconnected?
Last thing, do you use the module itself or the terminal?
Many thanks,
Adam
EDIT
Just to clarify, we are talking about ASC0 serial port, right?
Please also show the response to 'AT^SPOW?' command.
Hi
No I am currenly using the ASC1 serial interface. It works as expected most of the time. After alot of testing, I have learnt that the issue was actually the delay function that I was using to synchornise the communication. It sends the processor to sleep for too long which in turn caused all the issues I was having.
Many thanks Adam