nRF9160 goes to sleep and becomes stuck in idle task

[NelsonGoncalves]

Hello,

I am using the Nordic SDK at v1.5.0, to create an application that runs on the Nordic nRF9160. 

In the typical use case scenario, my application is mains powered and once per day is contacted by our remote TCP client, for a readout or sensor data.

However I noticed that when left unattended, after about 1h30 ~2h it appears to go into some sort of power saving (or sleep ?) mode, enters the Zephyr idle task and remains there.

It is also not reachable by our remote client.

I have disabled all power saving options for the modem part, so I do not understand why or how this could be occuring. As far as I can tell, there are no power related registers on the user CPU of the nRF9160 that can be configured to prevent this sleep mode.

So my question is, how can I prevent the application from going into power saving (or sleep) mode ? 

Thanks in advance,

 Nelson Gonçalves

[Hakon]

Hello,

do you have code that I can use to reproduce the issue? It doesn't need to be the original code, you can just include the necessary code to reproduce the same behavior/bug.

[NelsonGoncalves]

Hello Hakon,

Sorry for the late reply, I was busy with other projects. To reproduce this issue I use this code 6472.tcp_listen.zip which starts a TCP server and listens for remote client connections. You might need to adapt the APN to which the modem connects, because I am using a different carrier the one use by the Nordic SDK board. In the zip file there is also a Tcl script that implements my remote client

Using the Segger Embeded Studio, I build, flashed and started the application. Then I started my remote client, which sent the same sentence 10 times to the server on the nRF9160. And the server would reply with the same sentence in upper case.

Then I waited a little over an hour, and tried again. According to the Wireshark capture that I also uploaded, the TCP server accepted the connection, and it read the data sent by the client. The server then sends an ACK to the client, but does not push any data.

On the debugger, the application appears to be stuck in some sort of low power, inside the idle task. My guess is that the TCP traffic at 9:53:38 is being handled by the modem, but for some reason the application the TCP events (new client, read data) are not given to the application.

Here is the Wireshark capture in_low_power_mode_capture.pcapng

and also a screenshot of the debugger, showing the location in the code where it is stuck  

I am not sure why this is occuring. Maybe I need to setup a handler for modem events or there is a specific IRQ that is raised by the modem, but I cannot find any information on it.

Also, there does not seem to be any information about disabling the low power mode for the user CPU of the nRF9160.

[EDIT] I forgot to mention the software versions I am using, they are:

• the NCS v1.5.0 for the application
• the nRF9160 modem has firmware version mfw_nrf9160_1.2.3

Also, this issue might be related to this one wich I am also having: devzone.nordicsemi.com/.../how-to-detect-that-the-peer-closed-a-tcp-socket

[NelsonGoncalves]

Hello Didrik,

Thanks for the update. Is there a way to prevent the network from disconnecting the device, or at least auto-reconnecting ?  Is re-open the listening socket sufficient for causing the device to re-register on the network ?

I had tried to use v1.7.0 on my acutal project (not this demo application) but I could not build my project. So I kept to v1.5.0.  I will use v1.7.0 for this demo app and also fix the handling of the socket events. I will then report back on what happended.

[NelsonGoncalves]

Dirdrik,

A followup question. In LTE networks, 58 min is a typical value for the Traffic Area Update (TAU) timer (T3412). That aligns neatly with the aproximately 50 minutes of inactivity.

So if the TAU is rejected with code 9, the UE should automatically initiate the attach procedure (see 3GPP TS 24.301). Is that attach failing as well? Why?

[Didrik Rokhaug]

Here's what the modem team says happens on the LTE network:

Attach was done to network 206 20 but the cell was lost later. UE searched the same network but it was not anymore found. Instead, modem found network 206 10. Because the network changed and TAI was not in TAI list, modem had to initiate TAU which was then rejected with cause #9. This is normal, the second network did not recognize the UE due to lack of inter-working between the two networks.

So I was a bit wrong in my interpretation.

NelsonGoncalves said:

Is there a way to prevent the network from disconnecting the device, or at least auto-reconnecting ?

You can't prevent it from disconnecting (as it shouldn't disconnect in the first place). But the modem will automatically try to reconnect. In fact, in the trace you provided, it does reconnect to the network. However, as the TCP socket is already closed by the modem, the application doesn't recover.

Closing the socket you had, and opening a new socket (after reconnecting to the network) should be sufficient for recovering.

I am still waiting for their analysis of why the POLLIN flag was set.

[Didrik Rokhaug]

Hi,

Have you had any success reproducing the POLLIN with NCS v1.7.0?

Best regards,

Didrik

[NelsonGoncalves]

Hello Didrik,

Sorry for the late reply. I am now busy with another project, and I could not yet test the POLLIN in v1.7.0

I will try to do it this week and report back. Sorry again for the delay.

BR,

Nelson

[NelsonGoncalves]

Hello Didrik,

I changed my test application a little, to fix the issues that you pointed out, and also I build it using NCS v1.7.0. 

I left the application running for about 6h30, and the listening socket was always on. It seems that whatever issue was occurring, it got fixed in v1.70.

For the record, this is the setup on which I tested:

• nRF9160 SoC
• HW revision: nRF9160 SICA B0A
• FW version (modem): 1.3.0
• NCS v1.7.0

With this setup, running this demo application 6886.tcp_listen.zip, I never had any connectivity issues. There is a small TCL test client in the ZIP file, which I used to connect to the server running on the nRF9160, throughout the day.

The longest period without any communication between the client and the server was 3hrs, and again there were no connectivity issues. It seems moving to v1.7.0 fixed the issue.