I’ve run into a rather interesting problem. I’m running a GPRS- and TCP-dependent application that performs its duties in cycles.
In a cycle, it acquires a GPRS registration, does some internal stuff, sends up some data over TCP, then shuts down GPRS and goes into slow idle mode (AT+W32K=1).
All of this seems to work normally. However, under two conditions I run into a problem. The conditions are:
- a moderate number of cycles (usually no fewer than 4 cycles and no more than 20) have passed, or…
- I power off while in slow idle and then power on again
If one of these conditions are met, the next cycle’s GPRS registration fails because I cannot poll CREG.
“AT+CREG?” responds with nothing, although as far as I can tell the command is being sent.
I did some forum searching and ran into at least one other report of this problem, but it seemed to be just a symptom of a bigger problem for that poster, so I’m hoping someone has some ideas.
Is there, perhaps, a mode or an AT command I can turn on and then back off that might trigger this one to start responding again? Other AT commands do go through in this problem state, and sending the +CREG? with no response does not seem to delay or otherwise stop other AT functionality.
Thank you very much.
-Glen and Keith
EDIT: Manually entering “AT+CREG?” during this problem condition responds with “+CREG: 0, 1” which I believe means that the module has service and unsolicited responses are not being sent.
EDIT 2: In light of the supposedly good registration when I manually input the AT command, I had the application just give up on polling CREG if it didn’t respond for long enough (under the assumption that it would’ve responded with 0,1 again). Sadly GPRS fails to start in this case. Also, other issues arise under this condition. Namely, I can no longer switch UART 2 to AT mode nor unsubscribe from it (which I need to do in order to successfully slow idle).