Stopping GPS makes lte_lc_connect() hang

[Oskar]

Hi!

Since I do not have a SIM card that provides support PSM or eRDX I need to switch the system mode manually.

In my config I have CONFIG_LTE_NETWORK_MODE_LTE_M=y

I do this as follows:

// To lte mode
gps_stop(device);
lte_lc_offline();
lte_lc_connect();

// To GPS mode
lte_lc_offline();
lte_lc_system_mode_set(LTE_LC_SYSTEM_MODE_GPS);
lte_lc_normal();
gps_start(device, &config);

With some additional error handling and stuff, but this is the essence of it. But when I stop the GPS and then try to enable LTE mode the modem never manages to connect to LTE.

I have seen from some other posts about the need to close all sockets before trying to connect, so I have tried both with and without closing the GPS socket after disabling the GPS, but I end up with the same issue.

Switching from LTE to GPS works fine.

I use v1.3.0 of the SDK and have a modem running firmware v1.2.0.

Is there something I am missing that makes the connect not work?

[Oskar]

I run the nrf9160_gps driver from the SDK v1.3.0 and disabling the AT_HOST_LIBRARY sadly had no effect.

[Oskar]

I am doing more digging, from what I have gathered the issue is that after the AT+CFUN=1 command is sent to the modem it seems like none of the work submitted to the work queue on line 216 in this file https://github.com/nrfconnect/sdk-nrf/blob/master/lib/at_cmd/at_cmd.c is actually executed causing the callback function in the lte_lc_control library to never be called so we never get to actually see that we have been sucessfully registered.

What causes the callback work to never finish I haven't figured out yet. Do you have any tips or clues on this at the top of your head?

[Martin Lesund]

Hi Oskar,
If the at_cmd is the issue, I would advise you to apply this "at_rewrite PR": https://github.com/nrfconnect/sdk-nrf/pull/2264

# get PULL request
cd <your NCS folder>/nrf
git fetch ncs pull/2264/head:pr-2264
git checkout pr-2264
west update

(switch out "ncs" with "origin" if you have named the remote that)

This PR has fixed at_cmd "deadlocks" before.

[Oskar]

I will check this out!

I have also found that this problem can be worked around by having the at_cmd library have its own separate work queue, though this might have some side effects that I cannot predict.

[Martin Lesund]

Sounds good. 
Let me know how the PR works out.