nRF9160 - sent UDP message do not longer reach destination after 4 weeks

[Achim Kraus]

Running a Thingy:91 now for 4 weeks from batter with one message exchange per hour, it stopped working (NB-IoT mode).

The client (Thingy:91) uses "sendto" and that function returns success.

The client's log:

[18:01:38.586,822] <inf> COAP_CLIENT: CoAP request prepared, token 0xfbe72850, 139 bytes
[18:01:38.594,146] <inf> COAP_CLIENT: send_to_peer 175
[18:01:38.618,927] <inf> COAP_CLIENT: LTE modem wakes up
[18:01:40.208,496] <inf> COAP_CLIENT: RRC mode: Connected
[18:01:40.594,757] <inf> COAP_CLIENT: 1/1/729-1621 ms: connected => sent
[18:01:44.595,489] <inf> COAP_CLIENT: CoAP request resend, timeout 6
[18:01:44.596,832] <inf> COAP_CLIENT: resent_to_peer 175
[18:01:51.597,991] <inf> COAP_CLIENT: CoAP request resend, timeout 12
[18:01:51.607,635] <inf> COAP_CLIENT: resent_to_peer 175
[18:02:04.609,924] <inf> COAP_CLIENT: CoAP request resend, timeout 24
[18:02:04.619,537] <inf> COAP_CLIENT: resent_to_peer 175
[18:02:17.364,807] <inf> COAP_CLIENT: RRC mode: Idle after 37156 ms (12745 ms inactivity)
[18:02:25.377,655] <inf> COAP_CLIENT: LTE modem sleeps
[18:02:32.625,030] <inf> COAP_CLIENT: 729/-1ms/-1ms: failure

It starts with passing the message to "sento", which returns success with 175.

Then the modem wakes up and reports RRC connected. Though no response is received, the modem resends the message also with "sendto", which also returns success with 175.

On the server side the ip-capture shows, that no UDP traffic form that modem comes in, but from other clients it is still working.

The status page of the SIM-card provider shows as last event "PDP Context deleted".

For me this look like the modem seems to have trouble with the "PDP Context deleted" but didn't report that in the return code of "sendto".

Any proposal how to overcome that?

(And no, I'm not able to provide a capture of a 4 weeks run ;-)! But I hope, that the Nordic development team does also long term tests and so have already the experience with that.)

[Achim Kraus]

As I wrote in my first comment:

> (And no, I'm not able to provide a capture of a 4 weeks run ;-)! But I hope, that the Nordic development team does also long term tests and so have already the experience with that.)

So, no I don't plan to apply memfault for that.

It may be a bug on my side, but I see the probability more on Noridc's side.

Isn't the simple call to the function "sendto" a robust thing? And this call doesn't report an error, but I think it should have in the described scenario.

[Achim Kraus]

I have no concers, I just don't think that it's the right thing for this case.

So, your modem experts are not sure, what "PDP Context deleted" means?

Was my issue never forwarded to them? After that weeks?

I see two ways to go:

- consider, it's a bug in my application, then we can close it. For prod-mode my app will just reboot.

- consider, the modem should have detected the error and report that as error-code, then it may be of interest for your modem developer. And for me, if the outcome is, that the next firmware version will report that.

[helsing]

Collection of modem trace via UARTE1 or SEGGER RTT might not be possible in all cases. Nordic is working on new functionality for capturing modem trace through custom trace backends. Fore example, storing modem trace to flash could help us learn more in case messages are lost in the future.

[helsing]

Hi Achim,

helsing said:

In order to investigate furter,

• which hardware version of the Thingy:91 are you using?
• which nRF Connect SDK version?
• which mfw?

Would you would be able to disclose this information?

[Achim Kraus]

Hi Helsing,

did you forward the information:

- no error code returned from sendto

- no message received at the server with 2 retransmissions

- "PDP context delete" on the status page of the SIM card provider

---------------------

Thingy HW version: 1.0.0, 1.4.0, and 1.5.0 (it occurred once with the 1.0.0 device)

mfv: all 1.3.2

nrf Connect 2.0.1