How to gracefully shut down nRF9160 modem

Hi, we are using the nRF9160 in conjunction with the nPM1300. To power off the device, we call lte_lc_power_off() which sends the AT+CFUN=0 command to the modem and waits for a response. Immediately afterwards, the nPM1300 is put in ship mode to turn off the device's power circuitry.

We are observing that the modem does not send a data session ended event to our cell carrier when it is turned off this way. If the modem is simply put into flight mode (AT+CFUN=4) and the power is not removed, the data session ends gracefully.

Our cell carrier reached out to their Nordic FAE and got this response:

I am aware of a feature in later versions that have a ready flag for powering off the silicon where people have external FET’s to power off the nRF916x. This would indicate that the modem is disconnected and all the flash writes are complete.
The CFUN=0 command doesn’t automatically disconnect from what I know. It is supposed to go through a more graceful exit and finish by writing current settings to flash. If the customer goes through AT+CFUN=4 (airplane mode) then I believe we gracefully end the connection without the memory writes.
Is there any documentation of this 'ready' flag to indicate when it is safe to remove power from the nRF9160? Any other tips for gracefully shutting down the modem?
Thank you.

Parents Reply Children
  • Hi,

    When send() has returned that data has not been sent yet, it has only been queued to be sent. Sending happens usually shortly afterwards.
    Switching to CFUN=0 and powering off prevents the last message from going out. There is a proper way for data to be sent in modem firmware version 2.0.x but not in 1.3.x. Therefore, you would need to implement something at protocol level (e.g. waits for ack to the last message) or you would need to wait couple of seconds after the very last send() operation before switching to CFUN=0 and turning off the power. However, if by "modem does not send a data session ended event" you think about something LTE related, then we would need a modem trace for further investigation.

    Best regards,
    Dejan

  • Thank you. I was able to solve the issue on modem version 1.3.6 by introducing a short delay between calling CFUN=0 and powering off the device.

Related