This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF9160 Modem Frozen after put into Offline Mode

I have seen some situations where putting the modem into offline mode (CFUN=4) will cause my application to lock up because the at_cmd never returns. It looks like this is a pre-existing problem as reported here https://devzone.nordicsemi.com/f/nordic-q-a/52819/nrf9160-modem-not-responding-after-switching-to-offline-mode. However we are using modem firmware 1.1 and not using eDRX.

Is there any solution to this issue? We are seeing it fairly frequently, and have to reset the device when it happens.


Thanks

Parents
  • Hello,

    we observed the same problem with modem FW1.1 and might supply some more information to find the issue:

    In our test setups the issue occurs quite seldom: once every 5-10 days or so with daily NB.IoT UDP socket uploads + CFUN=4 after jobs are done. 

    Looking at the connection log of our provider (1NCE.com) we see that the connection will simply not closed by the not returning CFUN=4 command. So CFUN=4 does not return and not iniate any connection disconnect on provider side. After some time (2h in our example case) the connection gets closed by the provider but the nRF9160 AT socket waits forever. Any UDP sockets are NOT closed before using CFUN=4  will be reused after wakeup in our implementation - this works most of the time.

    In our real implementation we use timeouts on waiting on the AT socket and so we know that the modem power domain flag is set to OFF (NRF_POWER->POWERSTATUS) after CFUN4 did timeout.

    For us it looks like the modem fw seems to "forget" to work on CFUN=4 and does consequently not answer to the AT command - BUT the modem power domain gets turned off..

    Hope this helps the modem devlopers to track down the issue.

    Greetings
    Theo

    P.S.:
    The problem was using BSD Lib 0.5.0 and our own NON ZEYPHER freeRTOS based interface. So the above mentioned pull request has no relevance to us.

  • We have not been able to reproduce this issue with NCS 1.1.0

    Any UDP sockets are NOT closed before using CFUN=4  will be reused after wakeup in our implementation

    Try closing all the UDP sockets before using CFUN=4

Reply Children
Related