• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 75 subscribers
  • Views 2630 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

    Let me add:

    For me, the modem nRF9160 and the nrflib are "blackboxes". Trying to test the behavior is somehow limited. You never know, if there are cases (... if ...) you not aware of and so you never will have a really stable function. Also sometimes things are changing and with that, FMPOV, this requires to be specified by the manufacturer, as well, as I would assume that changes in the behavior (if at all in the future) must also be documented.

    Would it be possible, that the developers of these components check their implementation about that?

    What happens, if the modem lose the network?

    What happens, if the modem gets connected again?

    Is it right, that sockets are not longer usable, if that happens?

    Is reopening the socket the right thing to do?

    Are the cases, that after a network reconnect, more than just reopen the socket is required.  

Reply
  • 0

    Let me add:

    For me, the modem nRF9160 and the nrflib are "blackboxes". Trying to test the behavior is somehow limited. You never know, if there are cases (... if ...) you not aware of and so you never will have a really stable function. Also sometimes things are changing and with that, FMPOV, this requires to be specified by the manufacturer, as well, as I would assume that changes in the behavior (if at all in the future) must also be documented.

    Would it be possible, that the developers of these components check their implementation about that?

    What happens, if the modem lose the network?

    What happens, if the modem gets connected again?

    Is it right, that sockets are not longer usable, if that happens?

    Is reopening the socket the right thing to do?

    Are the cases, that after a network reconnect, more than just reopen the socket is required.  

Children
No Data
Related
Terms of service