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

  • Hi,

    As mentioned by Håkon here, this was an issue with the NCS codebase. Let me know if updating your codebase to NCS v1.1.0 does not fix the issue.

  • We are using NCS 1.1.0. Do you know what part of the NCS code base was the cause of this?

  • mlang3440 said:
    Do you know what part of the NCS code base was the cause of this?

     The issue in the post you linked to, was fixed as part of this PR: https://github.com/NordicPlayground/fw-nrfconnect-nrf/pull/1242

    some situations where putting the modem into offline mode

     How often does this happens ? 

    Could you upload the log output from LTE-Link monitor when the issue happens?

  • 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.

1 2