• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 65 subscribers
  • Views 1912 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284977
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to recover a nRF9160 from sporadic ENETDOWN

Achim Kraus

Using a Thingy!91 (v1.0.0 and v1.4.0, firmware 1.2.3, 1.2.7) I get sometimes (every couple of days) a ENETDOWN when sending data out. Before that ENETDOWN, the device was usually able to exchange 100 and more UDP messages.

Currently I do a "sys_reboot(SYS_REBOOT_COLD)", but I'm wondering, if there are less massive ways to recover.   

I found other questions, but I'm still struggling to see an "useful" answer. e.g.

https://devzone.nordicsemi.com/f/nordic-q-a/57642/nrf9160-lte-modem-documentation

but the link at the end, ends in "NOT FOUND".

So, what is the recommended way to recover from ENETDOWN?

Parents
  • 0

    Hello Achim,

    Achim Kraus said:

    so, which events should be used for verification? Currently I use

    LTE_LC_EVT_RRC_UPDATE with LTE_LC_RRC_MODE_CONNECTED

    to adjust the time, when the message is really sent. 

    So, which event/value should be processed?

    You should use LTE_LC_EVT_NW_REG_STATUS, as demonstrated in this LTE handler.

    Achim Kraus said:

    If "+CFUN=4" is sued, what need to be called/executed, to have the modem stack working for UDP again?

    Starting again from "lte_lc_connect_async(lte_handler);"?

    Something before? After?

    Since you are using the LTE link controller library, you can use lte_lc_offline() instead of writing +CFUN=4 to the modem directly, but you might want to re-open the UDP socket again.

    If the modem looses its connection to the network, it will automatically retry to connect after a while, as long as there is an available network to connect to. So if flight mode is an appropriate choice or not depends a little bit on your use case.

    Regards,

    Markus

Reply
  • 0

    Hello Achim,

    Achim Kraus said:

    so, which events should be used for verification? Currently I use

    LTE_LC_EVT_RRC_UPDATE with LTE_LC_RRC_MODE_CONNECTED

    to adjust the time, when the message is really sent. 

    So, which event/value should be processed?

    You should use LTE_LC_EVT_NW_REG_STATUS, as demonstrated in this LTE handler.

    Achim Kraus said:

    If "+CFUN=4" is sued, what need to be called/executed, to have the modem stack working for UDP again?

    Starting again from "lte_lc_connect_async(lte_handler);"?

    Something before? After?

    Since you are using the LTE link controller library, you can use lte_lc_offline() instead of writing +CFUN=4 to the modem directly, but you might want to re-open the UDP socket again.

    If the modem looses its connection to the network, it will automatically retry to connect after a while, as long as there is an available network to connect to. So if flight mode is an appropriate choice or not depends a little bit on your use case.

    Regards,

    Markus

Children
No Data
Related