Hi Nordic Team,
long story short: I get a
[10:04:59.928,985] <err> nrf_modem: Modem error: 0x4, PC: 0x7ef22
and after that the modem does not allow me to open a socket anymore.
ncs v2.1.2
modem fw: nrf9160_1.3.3 (on SICA B1)
Any ideas of how to prevent this?
Any ideas of how I could detect this and how to act on it to recover and beeing able to send data again?
The long story:
Modem is running in LTE-M + GPS.
Modem is in PSM (no eDRX).
The application (test setup) sends data via UDP every 5 Minutes (thus waking the modem up from PSM).
Each time the aplication opens a new socket, sends one or more udp packets, listens a few seconds for
an answer and closes the socket afterwards.
The sim card allows roaming and I have seen the modem changing cells and networks for time to time
(not shure if it happend during this power up but can look it up if it helps)
Single GPS fixes are done normally when the modem is in PSM.
[10:04:59.832,763] <dbg> llp: llp_transmit: 1 measurement packets sent
[10:04:59.928,985] <err> nrf_modem: Modem error: 0x4, PC: 0x7ef22
[10:04:59.929,107] <err> llp: recvfrom error: 11
[10:05:06.034,271] <dbg> tbws: main: Updating timing (waited 5000 ms)
[10:05:06.034,332] <inf> tbws: Updating time
[10:05:06.046,447] <err> lte_lc: Could not get registration status, error: -1
- "Updating time" is triggering a date_time_update_async(). So the "lte_lc: Could not get registration status, error: -1" might come from there.
- recvfrom error is the errno variable (11: EAGAIN)
After that (5 minutes later, when trying to do the next upload) calling socket() gives:
[10:10:00.277,374] <err> llp: socket: 110
110 is the errno: ESHUTDOWN
After quite some more tries to send (can count them if it helps you):
[10:50:00.262,969] <err> llp: socket: 105
110 is the errno: ENOBUFS
The modem does not seem to recover.
What would be the apropriate way to handle this?
Shutting down the modem and reregister after getting an ESHUTDOWN?
Resetting the system (I'd like to avoid this as I would loose my saved data)?
What pops into my mind: the recvfrom returning EAGAIN in this situation seems to be dangerous.
When I would handle that case I might call recvfrom again, maybe in a loop, and thus locking up.
My current implemntation luckily just bails out an any error. But might be a trap for others.
And: Sorry, no modem traces.
Regards,
Clemens
