AT Command interface hangs

[kt1024]

Hi,

without providing too much code right away, I would like to ask how I could circumvent AT command interface hangups. My current test application calls AT commands like

static const char cereg[] = "AT+CEREG?";

static const char cesq[] = "AT+CESQ";

static const char vbat[] = "AT%XVBAT";

I just modified lte_lc. for this

in the main loop with an interval of 10s by calling k_sleep(K_MSEC(10000)); in between. So the commands are sent to the modem via the socket, the results are received and evaluated and then sent to our cloud via UDP. Between each command passed to the modem lie 10 seconds.

What I would like to know is how I can prevent the AT command interface hangup, and if it happens anyway how can I reset the modem separately from the Cortex-M33.

Typically I can go through the above sequence 4 times and then the AT Command interface hangs. This is not acceptable, so I have to find a way to prevent this from happening.

Best Regards,

KT

[awneil]

The commonest mistake people make with AT commands is failing to wait for and pay attention to the responses from the modem - instead just relying upon blind delays:

https://www.avrfreaks.net/comment/2209136#comment-2209136

https://www.avrfreaks.net/comment/2139451#comment-2139451

[kt1024]

Well that makes sense, I could just port one of the multiple thousand lines of state machine code we have for our other projects to really pay attention to the modem. That state machine would probably run but it also has the ability to reset the modem - just in case.

What I should do, is scrap the lte_lc.? code that just writes something, reads without paying much attention and closes the interface socket again, and replace it with a reader writer task based on nonblocking sockets and fill the results into a queue. That should present a nice facade of attention and caring to the modem.

I don't feel like I'm being paid to do this right now so it will have to wait until later.

Regards,

KT

[kt1024]

I tried the at_client example with TeraTerm and AT%XVBAT for a while and I couldn't hang up the modem yet so it is capable of answering AT commands for longer than 2 minutes. So there is a way to make it work properly. Ok I guess I know enough for now lets close this issue, the modem reset is worth its own question.

[awneil]

Rather than keep polling the interface, can you just use unsolicited responses ... ?

[kt1024]

If I run my own lte_lc.? this could work, but I've had bad experiences with URCs elsewhere so polling is ok for me. I could imagine that powerconsumption and used interface bandwidth could be reduced if polling is avoided but sometimes I just have to get a piece of information at a certain time.

Another issue arises if URCs are your only means of getting information from the modem, then you can't decide whether a process on the modem isn't working or whether it just has no reason to generate a URC.

So while I'm at it, if you have a flakey modem only providing URCs and no means to poll for that information is a bad idea.

Regards,

KT

[awneil]

kt1024 said:

polling is ok for me

I was thinking of the impact on the modem.

kt1024 said:

if URCs are your only means of getting information from the modem, then you can't decide whether a process on the modem isn't working or whether it just has no reason to generate a URC.

Fair point.

Maybe a combination of URCs and the occasional poll as a "sanity check" ... ?

[kt1024]

I expressly do not think about the impact on the modem. How would you treat an output buffer overrun ? Is there any reason not to just empty it and dump more stuff in. There are perfectly good ways of being responsive about it. There is no reason to go into a corner and sulk forever.

Regards,

KT

[awneil]

kt1024 said:

I expressly do not think about the impact on the modem

I was referring to your opening question:

kt1024 said:

how I can prevent the AT command interface hangup

which seemed to be a "modem impact" thing.

I think I've lost track of where you're at/going - if I ever understood it in the first place.

[kt1024]

Appearently I changed from proactive to grumpy. In conclusion I would say that I have no problem switching to better socket handling than is done now. Since this is only an evaluation project I could also do without polling, but there are enough good reasons to use it in the end product to not yield on this.

Thanks for your help,

KT