We have a simple embedded application compiled with OAT 3.10 running on an 1206B with OS 6.55. The application sends data packets via GPRS periodically. If the data packet cannot be sent over the predefined period of time (10 minutes or more), an AT+CFUN=1 command is issued to reset the modem.
This ‘soft’ resetting the modem works for most of our installations, but not for all of them. We’ve found quite a few modules unoperational after they’ve been working for weeks.
The study showed these ‘locked’ modems had their LEDs lit constantly; they did not register with the GSM network. And the most disappointing thing was that the embedded application did not run on them. The AT+WOPEN? command reported +WOPEN: 1, but the application clearly was not running as there was no greeting string it should spit upon startup, and none of its own custom commands worked (namely AT+INFO that should report embedded applications’ internal settings).
Most of native AT commands worked, like AT+WDWL? or ATI3. Funny enough, the AT+WIND? command did not work properly: it only reported OK, without showing +WIND: xxxxx.
Giving the ‘locked’ modem AT+CFUN=1 by hand seemed to reset the modem, as the LED turned off for the fraction of second and then went back on. Then +WIND: 3 and +WIND: 13 messages were received, and that was it. The embedded application did not start (although the AT+WOPEN? would still respond with +WOPEN: 1).
The only way to completely reset the module was to turn power off and back on again, after which the embedded application started normally. This makes me think the AT+CFUN=1 is not the most reliable way to reset the modem; and it is quite frustrating to have this type of behaviour for remote autonomous systems.
While I am trying to reproduce this behaviour and to get any useful traces, what can be done to filter this problem out? Any feedback would be greatly appreciated.