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

nrf9160 modem not responding after switching to offline mode

My application uses the nrf9160 in eDRX mode. I regularly have the problem, that when switching the modem to OFFLINE mode (same for POWER-OFF mode), the modem is not responding anymore to any AT commands. I need to switch to OFFLINE mode for battery saving and for switching between Cat-M1 and Cat-NB1.

I wrote a minimalistic application for the demo board (PCA10090 0.8.5, modem Firmware 1.0.0), where I can reproduce the problem.

First the modem is configured to LTE Cat-M1 mode with an eDRX intervall of 82 seconds. Then it is set so ONLINE mode. After a connection is established or a timeout of 100 seconds expires, the modem is set to OFFLINE mode. Then this sequence is repeated.

For the application to run, the AT Command Driver and Logging with synchronous processing must be configured.

Here is the application code for the demo board:

After the second connection cycle, when setting the modem to OFFLINE mode, the modem is not responding anymore.

Here is the output:

Any suggestions?

Parents
  • modem Firmware 1.0.0

    There is a MFW 1.0.1 out now for a while.  I don't know of any specific mentions in the changelog related to this, but you should probably try it out just in case.

    And I agree that this should not happen when you go OFFLINE and back, but it's actually the behavior I would expect going to POWER-OFF and back.  Nordic has confirmed that once you put a modem in POWER OFF mode you shouldn't expect it to do *anything* until after the next reboot.  Putting the modem into POWER OFF is a one-way trip.

    EDIT: We are using EDRX in our application and can go online/offline repeatedly without issue.  I'm wondering if it's somehow related to the CEDRXS or XSYSTEMMODE swtiching while offline.  We rarely do either.  The CEDRXS you can actually do while online.  One possibly related issue I've seen is that if you have other sockets open to the modem for things like TCP/UDP traffic and are not servicing them, they can block the whole subsystem and cause the AT socket to block.  But it doesn't look like you have other sockets open in this case...

  • I just checked, I am using MFW 1.0.1 on our custom board and 1.0.0 on the demo board.

    I now updated also the demo board to 1.0.1, and I still see the same behavior. Thanks for pointing that out!

    According to the AT Command Manual, the modem must be switched to OFFLINE when the XSYSTEMMODE is changed. I guess the issue is somehow connected to the eDRX mode. I also tried the CEDRX command after going ONLINE, but I does not make a difference.

    In my simplified program I do not open any other sockets as far as I see. And I see the same behavior also with the AT_CLIENT sample.

    Another Observation maybe worth noting is that for some time I still get CEREG notifications occasionally in multiples of the eDRX interval (82 seconds). So the modem is still running somehow and occasionally switches to a different cell, but is not responding…

  • Hi,

     

    Sorry for me being a bit slow. I see what you're saying now and I see the same behavior.

    So, if you get a notification or similar (Like registering AT%CESQ=1 or any other form of notification), then sending AT+CFUN=4 hangs the application afterwards.

     

    Thanks again for the detailed description, I'll make sure that this is reported back to the developers.

     

    Kind regards,

    Håkon

  • Thanks for reproducing the issue. Btw, even without registering any unsolicited notifications I am able to send the modem into Nirwana...

  • Its the at_host / at_cmd that misbehaves. There's something with the UART handling, where the interrupt is kept disabled after this happens.

    Haven't figured out the details yet.

    Kind regards,

    Håkon

  • I just saw this issue on my board with modem firmware 1.1. Went to set the modem into Offline mode and the command never returned, freezing my application. We aren't using eDRX.

    Is this still a known issue? Is there any way to stop this from happening?

  • this was an issue in the ncs codebase, not on the modem side, and should be fixed now.

    Are you running ncs v1.1.0 or newer?

Reply Children