C-GPS fails upon opening TCP socket

Legacy Open AT
1

Hi all,

My app is experiencing C-GPS failure just after a TCP socket is being opened.

WIP Plug-in Package: 5.40.0.201007290812
C-GPS-OPUS-III Open AT Plug-in Package: 3.10.0.2003
Open AT Embedded Software Suite package: 2.34.0.201009161320
Q52Omni Open AT Plug-in Package: 2.6.0.2020
Firmware: 7.44.0.201008311212

All code, WIP and C-GPS and UART, runs in one task. Stack size is set to 128K.

C-GPS plug-in works with eRide GPS module connected to UART2. UART2 connection is configured and opened properly, and shortly after startup the application gets GPS data just fine. UART2 data traces look like this:

11/10/03,16:39:46:54 - 001;ADL;1;------ UART2 data: 8
11/10/03,16:39:46:54 - 002;ADL;1;00 00 00 08 E7 29 8B ED 
11/10/03,16:39:46:54 - 003;ADL;1;------ UART2 data: 16
11/10/03,16:39:46:54 - 004;ADL;1;8B DD FC 2B 00 00 04 01 0B 00 00 FF 02 36 0A 8B 
11/10/03,16:39:46:54 - 005;ADL;1;------ UART2 data: 1
11/10/03,16:39:46:54 - 006;ADL;1;ED 
11/10/03,16:39:46:164 - 001;ADL;1;GPSLoop
11/10/03,16:39:46:164 - 002;ADL;1;GPSLoop: rx_bytes_in: 516 
11/10/03,16:39:46:164 - 003;ADL;1;+++ ER_PVT_AVAIL
11/10/03,16:39:46:164 - 005;ADL;1;+++ ER_SVSTAT_AVAIL
11/10/03,16:39:46:164 - 006;ADL;1;+++ ER_FIXSET_AVAIL
11/10/03,16:39:46:179 - 001;ADL;1;+++ ER_LCTIME_AVAIL

When later a TCP socket is being opened to the server, UART2 seems to be flooded with some good amount of garbage:

11/10/03,16:45:00:351 - 003;ADL;1;------ UART2 data: 6
11/10/03,16:45:00:351 - 004;ADL;1;E0 E0 00 00 E0 00 
11/10/03,16:45:00:445 - 002;ADL;1;------ UART2 data: 120
11/10/03,16:45:00:461 - 001;ADL;1;00 00 00 00 E0 E0 F0 E0 00 E0 00 00 E0 E0 00 00 E0 F0 00 E0 00 00 E0 E0 00 E0 00 E0 00 00 00 E0 00 E0 E0 00 E0 F0 00 E0 E0 F0 E0 00 E0 F0 00 E0 00 00 00 00 E0 00 00 E0 00 00 00 E0 F0 00 E0 00 E0 E0 E0 00 E0 00 00 00 E0 F0 00 E0 E0 00 E0 E0 ...
11/10/03,16:45:00:492 - 001;ADL;1;E0 00 00 E0 E0 00 E0 E0 00 E0 00 00 E0 E0 F0 E0 00 E0 00 E0 E0 E0 00 00 E0 F0 00 E0 00 00 E0 00 E0 00 00 00 E0 F0 00 E0 
11/10/03,16:45:00:492 - 004;ADL;1;------ UART2 data: 120
11/10/03,16:45:00:507 - 001;ADL;1;E0 00 E0 E0 E0 00 E0 E0 E0 00 E0 E0 00 E0 00 E0 00 E0 F0 00 E0 00 E0 00 00 00 E0 F0 00 E0 00 00 E0 F0 00 E0 E0 00 E0 E0 E0 F0 00 E0 E0 00 E0 00 00 00 E0 00 00 E0 F0 00 E0 E0 00 E0 00 E0 00 E0 00 E0 E0 F0 00 E0 E0 F0 E0 E0 E0 F0 E0 00 E0 F0 ...
11/10/03,16:45:00:507 - 002;ADL;1;E0 00 E0 F0 E0 00 E0 00 E0 00 E0 00 E0 00 E0 E0 F0 00 E0 E0 00 E0 E0 E0 F0 00 00 E0 F0 E0 00 E0 F0 E0 00 E0 00 E0 00 E0 
11/10/03,16:45:00:507 - 005;ADL;1;------ UART2 data: 120
11/10/03,16:45:00:570 - 001;ADL;1;00 E0 E0 00 E0 E0 E0 F0 E0 00 E0 00 E0 E0 00 00 E0 F0 E0 00 00 E0 00 00 00 00 00 00 00 E0 E0 F0 E0 00 E0 00 00 E0 E0 00 00 E0 F0 00 E0 00 00 E0 E0 F0 00 E0 E0 00 E0 00 E0 00 E0 F0 00 00 00 00 E0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 00 00 E0 F0 ...
11/10/03,16:45:00:570 - 002;ADL;1;00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 
11/10/03,16:45:00:601 - 001;ADL;1;------ UART2 data: 120
11/10/03,16:45:00:601 - 003;ADL;1;E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 E0 00 E0 F0 00 E0 F0 00 E0 F0 E0 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 00 E0 E0 E0 F0 00 E0 F0 00 E0 00 00 E0 F0 E0 00 00 E0 E0 00 00 00 00 E0 00 00 E0 F0 E0 E0 F0 00 E0 F0 00 E0 ...
11/10/03,16:45:00:617 - 001;ADL;1;F0 00 E0 F0 00 E0 F0 E0 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 F0 00 E0 00 00 E0 F0 00 E0 00 
11/10/03,16:45:00:648 - 002;ADL;1;------ UART2 data: 120

No wonder C-GPS fails to find anything eRide-ish in this mess:

11/10/03,16:45:01:382 - 002;ADL;1;GPSLoop
11/10/03,16:45:01:398 - 001;ADL;1;GPSLoop: rx_bytes_in: 2046 
11/10/03,16:45:01:398 - 003;ADL;1;No GPS data available

Closing the TCP socket doesn’t help. Even detaching the modem from GPRS network does not fix the problem; the UART2 communication with eRide module stays spoiled with this garbage flood till the modem is reset.

So my question is, what can be the cause of this behaviour?

2

You’ve not got WIP Traces enabled on UART2, have you…?

3

Currently I just call wip_netInit (). Previously, I’ve been routing WIP traces either to WIP_NET_DEBUG_PORT_TRACE or to WIP_NET_DEBUG_PORT_UART1:

r = wip_netInitOpts (
	      WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART1, // WIP traces on UART1
//	      WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_TRACE,
	      WIP_NET_OPT_END);

I have commented out the code that starts TCP connection, and get the same result. Seems like garbage starts arriving at UART2 shortly after the GPRS bearer is up and running.

11/10/03,17:46:59:7 - 002;ADL;1;[evh_bearer] WIP_BEV_IP_CONNECTED
11/10/03,17:46:59:70 - 001;ADL;1;------ UART2 data: 5
11/10/03,17:46:59:382 - 001;ADL;1;------ UART2 data: 6
11/10/03,17:46:59:382 - 002;ADL;20;[ADL] tmr subs ; id 20 ; hdlr 002C44D5 ; val 50 ; cycl 0
11/10/03,17:46:59:429 - 002;ADL;1;------ UART2 data: 120
11/10/03,17:46:59:476 - 002;ADL;1;------ UART2 data: 120
11/10/03,17:46:59:507 - 002;ADL;1;------ UART2 data: 120
11/10/03,17:46:59:539 - 002;ADL;1;------ UART2 data: 120
11/10/03,17:46:59:570 - 002;ADL;1;------ UART2 data: 120
11/10/03,17:46:59:632 - 002;ADL;1;------ UART2 data: 120
11/10/03,17:46:59:695 - 001;ADL;1;GPSLoop
11/10/03,17:46:59:695 - 002;ADL;1;GPSLoop: rx_bytes_in: 731 
11/10/03,17:46:59:695 - 003;ADL;1;No GPS data available
4

I have noticed also that receiving WIP_BEV_IP_CONNECTED event not necessary marks the moment UART2 corrupts. Serial data gets corrupted after two indications received, +CREG and +CGREG:

11/10/03,18:42:50:945 - 001;ATI;2;Rec I_MMT_MM_SERVICE_IND
11/10/03,18:42:50:976 - 001;ATI;1;
+CREG: 1,"1E83","5A3E"
11/10/03,18:42:50:992 - 004;ATI;3;Snd AT_APPLI_UNSOLICITED_IND
11/10/03,18:42:50:992 - 007;ATI;2;Rec MMT_GM_SERVICE_IND
11/10/03,18:42:51:7 - 004;ATI;1;
+CGREG: 1,"1E83","5A3E"
11/10/03,18:42:51:7 - 008;ATI;3;Snd AT_APPLI_UNSOLICITED_IND
11/10/03,18:42:51:7 - 010;ATI;2;Rec AT_APPLI_SEND_UNS_EXTERNAL
11/10/03,18:42:51:23 - 004;ADL;1;-------- (ADL_GPRS_EVENT_ME_ATTACH)
11/10/03,18:42:51:23 - 005;ADL;1;[WIP] CID NOT FOUND[5]

Note the famous [WIP] CID NOT FOUND[5] message.

A bit more of traces:

11/10/03,18:42:52:7 - 001;ATI;2;Rec AT_TIM_REQ
11/10/03,18:42:52:195 - 001;ADL;1;------ UART2 data: 16
11/10/03,18:42:52:211 - 004;ADL;1;------ UART2 data: 3
11/10/03,18:42:52:304 - 001;ADL;1;GPSLoop
11/10/03,18:42:52:320 - 001;ADL;1;GPSLoop: rx_bytes_in: 19 
11/10/03,18:42:52:320 - 002;ADL;1;No GPS data available
11/10/03,18:42:52:320 - 003;ADL;20;[ADL] tmr subs ; id 7 ; hdlr 00260519 ; val 50 ; cycl 0
11/10/03,18:42:52:539 - 001;ATI;2;Rec RR_RXLEV_IND
11/10/03,18:42:52:586 - 001;ADL;20;[ADL] tmr subs ; id 8 ; hdlr 002C5491 ; val 50 ; cycl 0
11/10/03,18:42:53:226 - 003;ADL;1;------ UART2 data: 16
11/10/03,18:42:53:226 - 008;ADL;1;------ UART2 data: 3
11/10/03,18:42:53:242 - 001;ADL;1;GPSLoop
11/10/03,18:42:53:242 - 002;ADL;1;GPSLoop: rx_bytes_in: 19 
11/10/03,18:42:53:242 - 003;ADL;1;No GPS data available
11/10/03,18:42:53:242 - 004;ADL;20;[ADL] tmr subs ; id 9 ; hdlr 00260519 ; val 50 ; cycl 0
11/10/03,18:42:53:320 - 001;ATI;2;Rec AT_TIM_REQ
11/10/03,18:42:53:320 - 004;ATI;3;Snd I_MMT_STLK_RSP
11/10/03,18:42:53:523 - 001;ATI;2;Rec I_MMT_STLK_END_SESSION_IND
11/10/03,18:42:53:539 - 001;ADL;20;[ADL] tmr subs ; id 10 ; hdlr 002C5491 ; val 50 ; cycl 0
11/10/03,18:42:53:945 - 001;ATI;2;Rec AT_TIM_REQ
11/10/03,18:42:54:148 - 001;ADL;1;GPSLoop
11/10/03,18:42:54:148 - 002;ADL;20;[ADL] tmr subs ; id 11 ; hdlr 00260519 ; val 50 ; cycl 0
11/10/03,18:42:54:320 - 003;ADL;1;------ UART2 data: 5
11/10/03,18:42:54:445 - 001;ADL;20;[ADL] tmr subs ; id 12 ; hdlr 002C5491 ; val 50 ; cycl 0
11/10/03,18:42:54:648 - 003;ADL;1;------ UART2 data: 6
11/10/03,18:42:54:695 - 004;ADL;1;------ UART2 data: 120
11/10/03,18:42:54:726 - 004;ADL;1;------ UART2 data: 120
11/10/03,18:42:54:773 - 001;ADL;1;------ UART2 data: 120
5

Are you using the standard aided C-GPS sample - that uses C-GPS and WIP…

If not, have you tried it… :question:

6

Nope, I have hacked my own mess of code based on samples from Q52Omni plug-in distribution. I will check if there’s a C-GPS/WIP combo there although I don’t recall any.

7

C-GPS OPUS III samples from plug-in distribution seem to use different GPIO lines for resetting and powering attached GPS module as opposed to Q52Omni plug-in sample (Q52OmniSoft).

C-GPS sample:

#define GPS_POWER_SIGNAL (ADL_IO_GPIO | 22)

Q52OmniSoft sample:

#define GPS_POWER_SIGNAL (ADL_IO_GPIO | 48)

I’ve ran across this here: http://forum.sierrawireless.com/viewtopic.php?f=118&t=5572&start=0&hilit=q52omni
Don’t know if this resets modem when it comes to GPS init in C-GPS aiding sample. I will try to fix this in Q52OmniSoft way as it works.

However, I have noticed that there are two calls for wip_netInit in C-GPS sample: one inside the cfg_gprs.c file, another within cgpsaiding.c file. Only the first call is followed by opening and starting bearer. Does this mean I will have to call wip_netInit in all my tasks?

8

Yes, you must call wip_netInit from all tasks using WIP functions. In my application I have it called from the main task for the GPRS bearer, and then from TCP and FTP client tasks.

9

Thank you, I will give it a try; although the single task app still fails. I wonder what are the reasons for doing so. Has this been covered somewhere in the darkest corners of documentation?

10

So, I’ve managed to compile and run aided C-GPS sample. GPS core runs OK, and whatever bearer activity is, everything runs smoothly. It is worth mentioning that this sample uses Open Device interface to UART, not FCM.

11

That’s fairly recent: they used to use FCM, and I’ve had them working with FCM & WIP.

But it is, as you say, an interesting observation…

12

Yet even the aided GPS sample suffers from similar problem. After the TCP connection is opened and some data being transferred back and forth, C-GPS core seems to get out of sync:

2011/10/06;13:35:26:562;001;ADL;1;[TAG] ERideAppLoop () NMEA frames WD detected() : 3581124321 
2011/10/06;13:35:26:562;002;ADL;1;**OPUS RESET INITIATED FOR WATCHDOG_NMEA_FRAME, 5 RESET EVENTS SO FAR

Resetting it works, and then it continues running… till the next TCP connection. Continuous watchdogging and resetting might be a good workaround, but would hardly suit everyone.