[SL6087] GPRS connection loss issue

Legacy Legacy AirPrime modules
1

Hi everyone,
I’m developing an application with SL6087 and I have a strange issue apparently regarding the loss of GPRS signal.
My application stores GPS positions and every X seconds sends the data to a remote server. The application works perfectly until I go under tunnels, the network is lost and the module restarts.
I made some investigation, as suggested by some of you in similar threads, monitoring unsolicited responses (WIND, CREG, CGREG and off course the bearer events) and the results seem a little strange to me.
I made about 30 tests and I’ve had different behaviours for similar situations. Generally the sequence is:

[gprs_unso_hdl] - AT+WIND: 8
[gprs_unso_hdl] - AT+CREG: 2
[gprs_unso_hdl] - AT+CGREG: 0
[GPRS_bearer_event_handler]  - <WIP_BEV_ME_UNREG>
[...]
Binary header at 002A0000   <--REBOOT

If there is no channel established nothing strange happens (and there is no WIP_BEV_ME_UNREG event off course).
If the events above occur while there is a data channel established ( created using wip_getFileOpts() with WIP_HTTP_METHOD_POST ) generally the module reboots (I say “generally” because the module’s behaviour seems not to be deterministic - off course it is…).
I must specify a thing, given that it’s not clear what to do in reception of event WIP_BEV_ME_UNREG (the documentation only says that the ME is not registered so I assume there is nothing I must do…), I tried several alternatives:

  1. a simple TRACE for debug purposes has different results, sometimes the module restarts, sometimes after a while it receives the WIP_BEV_CONN_FAILED event, sometimes it stops receiving channel events and the whole mechanism remains stuck;
  2. wip_bearerStop() returns -27;
  3. any combination of wip_close() on the data or context channel reboots the module,always.

The most frequent behaviour is this (sorry for the “non-standard” traces):

2015/03/04;16:33:55:507;001;ADL;30;[GPRS_connect_and_execute] Success starting bearer
2015/03/04;16:33:55:507;002;ADL;16;[ADL port] IsAvailable(80) : 1
2015/03/04;16:33:58:176;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:60
2015/03/04;16:33:58:178;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:3
2015/03/04;16:34:01:182;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:92
2015/03/04;16:34:01:184;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:4
2015/03/04;16:34:04:174;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:129
2015/03/04;16:34:04:177;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:5
2015/03/04;16:34:05:171;001;ADL;1;[gps_simpleInfoHandler]  GPS_POS_FIX_LOST_EVENT
2015/03/04;16:34:05:341;001;ADL;30;[gprs_unso_hdl] - AT+WIND: 8
2015/03/04;16:34:05:342;001;ADL;30;[gprs_unso_hdl] - AT+CREG: 2
2015/03/04;16:34:05:343;001;ADL;30;[gprs_unso_hdl] - AT+CGREG: 0
2015/03/04;16:34:05:343;002;ADL;30;[GPRS_bearer_event_handler]  - <WIP_BEV_ME_UNREG>
2015/03/04;16:34:07:192;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:172
2015/03/04;16:34:07:193;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:6
2015/03/04;16:34:10:205;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:216
2015/03/04;16:34:10:205;002;ADL;8;[gps_simplePvtHandler] - nofix_counter:7
2015/03/04;16:34:12:849;001;ADL;9;[GPRS_checkBuffer] Buffer empty!
2015/03/04;16:34:13:186;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:264
2015/03/04;16:34:13:187;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:8
2015/03/04;16:34:16:168;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:315
2015/03/04;16:34:16:169;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:9
2015/03/04;16:34:19:201;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:369
2015/03/04;16:34:19:202;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:10
2015/03/04;16:34:22:195;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:426
2015/03/04;16:34:22:196;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:11
2015/03/04;16:34:25:176;001;ADL;8;[gps_simplePvtHandler] sat_n:10 sat_used:0 max_dBHz:0 mindBHz:0 hpe:485
2015/03/04;16:34:25:179;001;ADL;8;[gps_simplePvtHandler] - nofix_counter:12
2015/03/04;16:34:32:800;001;ADL;1;Binary header at 002A0000
2015/03/04;16:34:32:800;002;ADL;16;[ADL PORT] subs (0033F42D) : 0
2015/03/04;16:34:32:801;001;ADL;16;[ADL PORT] subs (003410C5) : 1

and as you can see the reboot can happen even almost 30 seconds after the WIP_BEV_ME_UNREG event.

I’ve been searching forum and documentation for similar situations but no one seems to have issues when loosing network while a channel is established…

Am I missing something? Is there a more effective way of debugging network issues?
At this point any kind of suggestion would be really appreciated!

Thanks in advance!
Mattia

Open AT Application Framework package: 2.52.0.201405121558
Firmware Package: 7.52.0.201404040850
Internet Library Package: 5.56.0.201305170830

2

Hi,
wip_bearerStop() returns -27 means bearer connection in progress…
But regarding module reboot… are you getting any back traces?

Regards,
Alex

3

Hi Rex_alex, thank you for your reply!

For now I worked around the problem by starting the bearer when application starts (and keeping it alive) instead of starting and closing the bearer each time I need to send data. This way I minimize the “vulnerable” time to few seconds at startup time.
I’m also ignoring WIP_BEV_ME_UNREG event and it works just fine.
My question is: is this the way it’s meant to be?! I mean: is it normal that the module restarts if I try to start the bearer when the ME isn’t registered to the network?
And is this the right use of the library? I don’t think so, why should I be connected the whole time if I only need to send few data every once in a while?

About the -27 error: it means “operation already in progress” so I assume that the bearer is already being stopped but no other bearer event is generated…
About the reboot error is there a way I can find the reason in the traces? Now I’m tracing the ADL (everything but6,15,18,20 and 22), LLH and HLH (only 1,2 and 4) flows, is there some other flow I should be aware of? and what should I be looking for in the traces?

Thank in advance for any help!
Kind regards.

Mattia