GPRS Registration tripping Watchdog

Legacy Legacy AirPrime modules
1

I have been seeing some issues lately with my application tripping the WatchDog while trying to bring up GPRS (I am sure it has happened before, just never noticed it). It is happening prior to accessing the WIP library and opening the bearer service.

I bring up GPRS as follows:
-subscribe to WIND: 4
-In my WIND: 4 Handler:
—setup my GPRS settings adl_gprsSetup() - (Not sure this is needed)
—subscribe to the gprs service events
—execute the command “AT+CGATT=1”

-In my gprs handler, I get the following events and unsolicited responses in order:
—ADL_GPRS_EVENT_SETUP_OK
—+CGREG: 2
—ADL_GPRS_EVENT_ME_UNREG_SEARCHING
—+CGREG: 2
—+CGATT=1 (Sent to terminal by application)
—+CGREG: 0 (I found this odd)
—ADL_GPRS_EVENT_ME_UNREG (based on the last +CGREG unsolicited response this makes sense)
—+CGREG: 0
—+CGREG: 1,“blah”, “blah”
—ADL_GPRS_EVENT_ME_ATTACH

I then proceed to open the bearer which almost always fails at first with the error:
WIP_BERR_OK_INPROGRESS
which is fine except that it hangs here for a while, proceeded by:
ADL_GPRS_EVENT_SETUP_OK
ADL_GPRS_EVENT_ACTIVATE_OK

That is the typical start-up process for the application. I use UDP to communicate to and from my server app. Occasionally the WatchDog will trip before I receive the ADL_GPRS_EVENT_ME_ATTACH event and open the bearer service. Any ideas why this happens or a better pseudo-code to bring up GPRS and open the WIP bearer service would be appreciated.

Thanks,
Scott

2

That’s not an error; that indicates success! The clue is in the OK in the middle of it…

It doesn’t hang - it’s busy doing doing stuff…

You’re not doing all this in a single pass through your handler, are you?

3

@ awneil - Thank you for your response

Yes, I understand that. By “error”, I meant it returned < 0
Although, occasionally it will “hang” at this point for quite some time. It shouldn’t take it that long to execute
that particular process thread. At one point, I had to reset the module after 5 minutes of it “doing stuff”.
At this point in the application, there is nothing else executing. Since I rely on UDP Sockets for communication,
the nuts and bolts of the program get kicked off upon the WIP Bearer event WIP_BEV_IP_CONNECTED. So I am
not quite sure why it “hangs” (I am using that term loosely) here.

Yes, I am. In the Wind 4 handler I am executing:
wip_netInit(), which responds immediately
adl_gprsSetup(), which responds immediately
adl_gprsSubscribe()
and then create the AT Command “AT+CGATT=1”

Should I create a timer to execute the AT Command “AT+CGATT=1” and give it 5 seconds or so to process some
of the gprs subscription events?

What are your thoughts?

Thanks,
Scott

4

I don’t think you should be “manuallly” issuing AT commands - that stuff is all handled by WIP.

Maybe that’s what’s confusing it?

5

Again, thank you for your prompt replys. Without sending it the +CGATT=1 command, the modem never attempts
to attach itself to the network. I set a timer for that command and let it run overnight. It registered fine, but at
some point something triggered the watchdog. Here is the responses from the modem ( Sorry it is so long ).

at+wopen=1
OK

+WIND: 3

+WIND: 13

+WIND: 12,0

+WIND: 12,1

+CREG: 0

+CGREG: 0

OverrideHandle Subscription Success

+WIND: 7

+WIND: 1

+CREG: 2

+WIND: 15,1,"AT&T",2,"AT&T",4,"08/04/01,21:38:15-20",6,"1"

+CREG: 1,"CB28","4F07"

+WIND: 16

Initialization of the TCP/IP stack Successful

+WIND: 4

+WIND: 10,"SM",0,"FD",0,"ON",0,"SN",0,"EN",0

+WIND: 11,,,"61DBE2BE9EEAD4BC9ECDBE0BE99E4167",,"C0E764CAFE8FF891FC0FB0C31CF7992
A",

GPRS Handler Event: 25  Cid: 1

+CGREG: 2

GPRS Handler Event: 29  Cid: 5

+CGREG: 2

+CGATT=1

+CGREG: 0

GPRS Handler Event: 28  Cid: 5

+CGREG: 0

+CGREG: 1,"CB28","4F07"

GPRS Handler Event: 27  Cid: 5

Opening Bearer Service

Bearer connect function failure Value: -27

GPRS Handler Event: 25  Cid: 1

GPRS Handler Event: 16  Cid: 1

Bearer Handler Event: 2

IP Address: xxx.xxx.xxx.xxx

Starting UDP Timer

UDP Channel Created

UDP Data Sent!

+CGREG: 0

GPRS Handler Event: 28  Cid: 5

+CGREG: 1,"CB28","4F07"

GPRS Handler Event: 27  Cid: 5

Opening Bearer Service

Bearer Open failure Value: -21

+WIND: 3

+WIND: 13

+WIND: 12,0

+WIND: 12,1

+CREG: 0

+CGREG: 0

OverrideHandle Subscription Success

+WIND: 7

+WIND: 1

+CREG: 2

+WIND: 15,1,"AT&T",2,"AT&T",4,"08/04/02,03:05:45-20",6,"1"

+CREG: 1,"CB28","4F07"

+WIND: 16

Initialization of the TCP/IP stack Successful

+WIND: 4

+WIND: 10,"SM",0,"FD",0,"ON",0,"SN",0,"EN",0

+WIND: 11,,,"61DBE2BE9EEAD4BC9ECDBE0BE99E4167",,"BB1CEB80AC76EA092B57BC413DF12CA
6",

GPRS Handler Event: 25  Cid: 1

+CGREG: 2

GPRS Handler Event: 29  Cid: 5

+CGREG: 2

+CGATT=1

+CGREG: 0

GPRS Handler Event: 28  Cid: 5

+CGREG: 0

+CGREG: 1,"CB28","4F07"

GPRS Handler Event: 27  Cid: 5

Opening Bearer Service

Bearer connect function failure Value: -27

GPRS Handler Event: 25  Cid: 1

The Watchdog was tripped at 22:00:53 CDT. The only reason I know that is that I have a cyclic timer that
sends udp packets to my server and that was the last communication. It is currently 09:14 CDT, so it has
been almost 12 hours. So, not only did it trip the watchdog, but it has been “hanging” for almost 12 hours.
Obviously I realize there are a lot of checks and balances I can implement in my application, but I don’t want
to plug a hole with my finger; I’d rather find out what caused the hole in the first place.

Thanks,
Scott