Embedded application doesn't restart after +CFUN=1

Legacy Open AT
1

Hi all,

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.

2

You can try adding the at+cfun=0 command, before the at+cfun=1.
Or use the at+wrst (it has different logic).

The problem is that these kids of problems are difficult to recreate …

3

sefer,

Thank you for prompt reply.

Indeed, the AT Command Guide recommends issuing AT+CFUN=0 command before +CFUN=1 to save some vital E2P and/or SIM parameters. I will definitely try using this sequence. I only wonder if Wavecom really recommends resetting module this way.

AT+WRST seems also worth trying. I couldn’t help but notice the timer remains active after reset, that could make it a nice watchdog, too - if only it resets the modem in a more brute manner than AT+CFUN=1 does.

Thanks again!

4

Well, I’ve just caught the same very behaviour by simply fiddling with modem’s power supply unintentionally. After I have re-plugged power cord back again, the modem came into exactly that position I have described before.

It responds to AT commands, reports +WOPEN: 1, but clearly the embedded application is not running. The LED stays lit all the time.

I have tried to first reset modem using AT+WRST command - no luck. It did reset, however, to only be stuck at the same position again, no embedded app running.

Then I thought I’d give it an AT+CFUN=0 followed by AT+CFUN=1. Unfortunately, the AT+CFUN=0 seemed to occupy the modem completely. It kept responding to any command I’d give to it since by ERROR. Had to AT+CFUN=1 it out of pity. Again, it gave me +WIND: 3 followed by +WIND: 13, and that was it. No embedded app, no registering with the network.

If there are any special tricks to get those debug traces correctly, I’d be more than willing to apply them. I already can see plenty of them debug messages in Target Monitoring Tool, all sorts but not my CUS4 1 one.