NRF9160 infinite nrf_connect blocking behavior post LTE PSM wakeup

[GJSea]

Hi,

I've noticed several times now when the NRF9160 comes out of a PSM sleep cycle that when a call to an underlying socket connect(), or nrf_getaddrinfo() call (whether it be from a socket connect at the app level, or the connect() within sntp_init) that the underlying nrf_connect/nrf_getaddrinfo blocks forever.

So my first question is

- Why would the nrf_connect/nrf_getaddrinfo block indefinitely, even if there is a strange state issue with DNS or other with the provider iBasis or otherwise, a failure timeout should occur.

- Can either of those functions within nrf91_sockets be non-blocking enabled with O_NONBLOCKING? This is assuming there isn't an internal K_FOREVER lock state within the modem firmware which would lock it all up regardless.

I'm using the latest modem firmware and V1.0.0 tag

Thanks!

[Håkon Alseth]

GJSea said:

Somewhat related is there away to determine when the system/modem has re-established a connection to the network/provider when it comes out of sleep, or a reasonable number of seconds period after waking, or is it assumed the connection is always valid (DNS, etc) once the initial registration after bootup to the network provider has occurred?

This behavior heavily depends on what mode you're currently in. Since you mention sleep, the most common one is PSM (power saving mode).

If you are in PSM, its the application that triggers a "wakeup" by issuing a socket operation (send/recv/getaddrinfo etc), then the modem starts communicating with the cell tower again, and you perform the operations that is specified, before eventually going back to PSM mode.

 

Kind regards,

Håkon

[GJSea]

Hi Håkon,

Is there a way to turn on more Modem Firmware tracing to understand why something like getaddrinfo would either block or return -10 on a well known, always-up endpoint such as microsoft.com. I'm trying to understand if it is between app/modem firmware and the network provider, or between network provider and internet. The device becomes connectionless from 2 to 40+ sleep cycles where only a reboot fixes the situation, the first connection after reboot works 100% of the time.

Thanks

[Håkon Alseth]

Hi,

 

-10 resolves to ECHILD (defined in errno.h), and it sounds like the device is having issues reconnecting to the cell tower.

Have you checked what the reported RSRP (received strength) is in your environment? If you run the at_client, and connect, you should get this by running "AT+CESQ"

The last number is then the RSRP, given in units from -140 dBm, so if you get "60" back, it indicates -80 dBm signal strength.

 

If the signal strength is good (better than -100 dBm), I'd recommend that you enable modem traces, as described in this blog post:

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/how-to-get-modem-trace-using-trace-collector-in-nrf-connect

 

Note the AT command "AT%XMODEMTRACE=1,2" needs to be enabled prior to tracing. The .bin file should be several hundred kB (in a matter of ~30 secs) when its working.

 

Kind regards,

Håkon

[jlangballeswift]

I've seen this issue using LTE-M without PSM also. I'm having a very tough time reproducing it exactly though.