nrf9160 modem not responding after switching to offline mode

RE: nrf9160 modem not responding after switching to offline mode

Håkon Alseth — Tue, 28 Jul 2020 14:15:32 GMT

My apologies for the late response.

This sounds a bit more complex in terms of execution (several things happening at the same time), and will likely depend on how you handle events from mqtt as well. Could you create a new thread with detailed information related to how you reproduce this locked scenario?

Kind regards,

Håkon

RE: nrf9160 modem not responding after switching to offline mode

af2377 — Tue, 07 Jul 2020 04:25:03 GMT

I am seeing a similar issue and reproduces rather easily for me. I am using ncs1.3 and modem v1.2.

Here are the steps:

Go online:

lte_lc_init();
lte_lc_system_mode_set(LTE_LC_SYSTEM_MODE_LTEM_GPS);
lte_lc_connect_async();

Once network is connected, connect to AWS MQTT using mqtt lib. Then send some data. Then disconnect by calling mqtt_disconnect. Once disconnected call lte_lc_offline(). This call never returns.

Here is the at_cmd trace after calling lte_lc_offline:

[00:00:20.072,967] <dbg> at_cmd.at_write: Sending command AT+CEREG=5
[00:00:20.073,211] <dbg> at_cmd.at_write: Awaiting response for AT+CEREG=5
[00:00:20.073,364] <dbg> at_cmd.socket_thread_fn: at_cmd_rx 5 bytes, OK

[00:00:20.073,394] <dbg> at_cmd.at_write: Bytes sent: 10
[00:00:20.073,425] <dbg> at_cmd.at_write: Sending command AT+CEREG?
[00:00:20.073,486] <dbg> at_cmd.socket_thread_fn: Allocating memory slab for AT socket
[00:00:20.073,486] <dbg> at_cmd.socket_thread_fn: Allocation done
[00:00:20.073,638] <dbg> at_cmd.at_write: Awaiting response for AT+CEREG?
[00:00:20.073,883] <dbg> at_cmd.socket_thread_fn: at_cmd_rx 62 bytes, +CEREG: 5,1,"D6E0","084C890D",7,,,"11100000",~
[00:00:20.073,944] <dbg> at_cmd.at_write: Bytes sent: 9
[00:00:20.078,430] <dbg> at_cmd.at_write: Sending command AT+CFUN=4
[00:00:20.078,491] <dbg> at_cmd.socket_thread_fn: Allocating memory slab for AT socket
[00:00:20.078,521] <dbg> at_cmd.socket_thread_fn: Allocation done
[00:00:20.078,674] <dbg> at_cmd.at_write: Awaiting response for AT+CFUN=4
[00:00:20.335,266] <dbg> at_cmd.socket_thread_fn: at_cmd_rx 58 bytes, +CEREG: 0,"D6E0","084C890D",7,0,0,"11100000",~
[00:00:20.335,357] <dbg> at_cmd.socket_thread_fn: Allocating memory slab for AT socket
[00:00:20.335,357] <dbg> at_cmd.socket_thread_fn: Allocation done
[00:00:21.673,126] <dbg> at_cmd.socket_thread_fn: at_cmd_rx 12 bytes, +CSCON: 0

[00:00:21.673,187] <dbg> at_cmd.socket_thread_fn: Allocating memory slab for AT socket

RE: nrf9160 modem not responding after switching to offline mode

Håkon Alseth — Tue, 19 May 2020 11:19:10 GMT

Hi Marcus,

The former issue was confirmed, and seems to be slightly different in behavior compared to your issue, but that specific should have been fixed (on tag v1.1.0 and newer, should have been fixed by this PR). If the issue is not fixed on newer bsdlib versions, I think we should look into taking a modem trace, but I would first recommend that you try to reproduce this on a newer branch of nrf and bsdlib v0.7.1 to see if the problem still exist there.

Kind regards,

Håkon

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Tue, 19 May 2020 10:27:28 GMT

Thanks for your answer. I will try it with the master branch of the SDK.
Unfortunately this issue is not so easy to reproduce, as it happens sporadically, but mostly after the modem appears to have lost the connection. It does not happen every time I turn the modem off or offline.
It seems like I am not the only one having that problem: mlang3440 and lobaro-theo saw this issue too, and there are some more threads reporting on this issue.
Best regards,
Marcus

RE: nrf9160 modem not responding after switching to offline mode

Håkon Alseth — Tue, 19 May 2020 08:33:04 GMT

Hi Marcus,

My apologies for the late reply. I have checked around in R&D, and we have not seen this behavior before. This could be a side-effect of another issue, as we have done several bug fixes in bsdlib lately: https://github.com/NordicPlayground/nrfxlib/blob/master/bsdlib/doc/CHANGELOG.rst

Could you try to rebase your current project on master, to see if this issue still occurs?

Could you explain a bit more about the issue at hand, is it easily reproducible, or is this something that can happen after days of running?

Kind regards,

Håkon

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Fri, 15 May 2020 15:50:35 GMT

Hi, any update o this issue?

Now I'm working with modem firmware 1.2.0 and nRF SDK version 1.2, and I still have the same issue occasionally. It usually happens when the signal is rather weak, the modem probably lost connection (without notifying me about it by CEREG) and I turn the modem off with AT+CFUN=0. Then the modem does not respond. I implemented a timeout in the at_cmd_write() function, so that the driver does not hang forever. Any subsequent commands also hang / time out. Then I close and reopen the AT socket. Does not help. So a reset is the only way to get the modem working again.

The peculiar thing is, that the modem in the background still shows 4 short moments of activity each 82 seconds, which is our eDRX interval. So it's definitely not turned off, but it's stuck.

Out in the field, we cannot do a hard reset to bring our devices back online. Please help us with this issue.

Best regards,

Marcus

RE: nrf9160 modem not responding after switching to offline mode

lobaro-theo — Wed, 15 Jan 2020 10:50:41 GMT

We have the same issue as mlang3440.

https://devzone.nordicsemi.com/f/nordic-q-a/56167/nrf9160-modem-frozen-after-put-into-offline-mode

RE: nrf9160 modem not responding after switching to offline mode

Håkon Alseth — Mon, 06 Jan 2020 14:05:38 GMT

this was an issue in the ncs codebase, not on the modem side, and should be fixed now.

Are you running ncs v1.1.0 or newer?

RE: nrf9160 modem not responding after switching to offline mode

mlang3440 — Thu, 02 Jan 2020 22:18:58 GMT

I just saw this issue on my board with modem firmware 1.1. Went to set the modem into Offline mode and the command never returned, freezing my application. We aren't using eDRX.

Is this still a known issue? Is there any way to stop this from happening?

RE: nrf9160 modem not responding after switching to offline mode

Håkon Alseth — Tue, 08 Oct 2019 13:25:50 GMT

Its the at_host / at_cmd that misbehaves. There's something with the UART handling, where the interrupt is kept disabled after this happens.

Haven't figured out the details yet.

Kind regards,

Håkon

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Tue, 08 Oct 2019 13:07:59 GMT

Thanks for reproducing the issue. Btw, even without registering any unsolicited notifications I am able to send the modem into Nirwana...

RE: nrf9160 modem not responding after switching to offline mode

Håkon Alseth — Tue, 08 Oct 2019 12:30:05 GMT

Hi,

Sorry for me being a bit slow. I see what you're saying now and I see the same behavior.

So, if you get a notification or similar (Like registering AT%CESQ=1 or any other form of notification), then sending AT+CFUN=4 hangs the application afterwards.

Thanks again for the detailed description, I'll make sure that this is reported back to the developers.

Kind regards,

Håkon

RE: nrf9160 modem not responding after switching to offline mode

jbrzozoski — Fri, 04 Oct 2019 17:28:18 GMT

Yep. This is surprisingly easy to reproduce. I rebuilt at_client with debug logging enabled, loaded it on my dev kit, and did this on my second try (leftmost timestamps from TeraTerm):

[2019-10-04 12:54:35.031] ***** Booting Zephyr OS build zephyr-v2.0.0-875-gd6e67554cfeb *****
[2019-10-04 12:54:35.031] The AT host sample started
[2019-10-04 12:54:36.016] [00:00:00.270,935] <dbg> at_cmd.at_cmd_driver_init: Common AT socket created
[2019-10-04 12:54:36.016] [00:00:00.270,965] <dbg> at_cmd.at_cmd_driver_init: Common AT socket processing thread created
[2019-10-04 12:54:36.032] [00:00:00.273,437] <dbg> at_cmd.socket_thread_fn: AT socket thread started
[2019-10-04 12:54:37.329] AT
[2019-10-04 12:54:37.846] OK
[2019-10-04 12:54:38.033] [00:00:03.070,739] <dbg> at_cmd.at_write: Sending command AT
[2019-10-04 12:54:38.049] 
[2019-10-04 12:54:38.049] [00:00:03.079,467] <dbg> at_cmd.at_write: Bytes sent: 3
[2019-10-04 12:54:53.861] AT+CFUN?
[2019-10-04 12:54:53.877] +CFUN: 4
[2019-10-04 12:54:53.877] OK
[2019-10-04 12:54:54.049] [00:00:19.108,978] <dbg> at_cmd.at_write: Sending command AT+CFUN?
[2019-10-04 12:54:54.064] 
[2019-10-04 12:54:54.064] [00:00:19.117,828] <dbg> at_cmd.at_write: Bytes sent: 9
[2019-10-04 12:55:00.743] AT+CEREG=3
[2019-10-04 12:55:00.758] OK
[2019-10-04 12:55:01.071] [00:00:25.990,020] <dbg> at_cmd.at_write: Sending command AT+CEREG=3
[2019-10-04 12:55:01.071] 
[2019-10-04 12:55:01.071] [00:00:25.998,840] <dbg> at_cmd.at_write: Bytes sent: 11
[2019-10-04 12:55:05.292] AT%CESQ=1
[2019-10-04 12:55:05.308] OK
[2019-10-04 12:55:06.074] [00:00:30.533,386] <dbg> at_cmd.at_write: Sending command AT%CESQ=1
[2019-10-04 12:55:06.090] 
[2019-10-04 12:55:06.090] [00:00:30.542,175] <dbg> at_cmd.at_write: Bytes sent: 10
[2019-10-04 12:55:10.404] AT%XSYSTEMMODE=1,0,0,0
[2019-10-04 12:55:10.420] OK
[2019-10-04 12:55:11.092] [00:00:35.654,785] <dbg> at_cmd.at_write: Sending command AT%XSYSTEMMODE=1,0,0,0
[2019-10-04 12:55:11.107] 
[2019-10-04 12:55:11.107] [00:00:35.665,130] <dbg> at_cmd.at_write: Bytes sent: 23
[2019-10-04 12:55:15.952] AT+CEDRXS=2,4,"0101"
[2019-10-04 12:55:15.952] OK
[2019-10-04 12:55:16.108] [00:00:41.190,765] <dbg> at_cmd.at_write: Sending command AT+CEDRXS=2,4,"0101"
[2019-10-04 12:55:16.108] 
[2019-10-04 12:55:16.108] [00:00:41.199,645] <dbg> at_cmd.at_write: Bytes sent: 21
[2019-10-04 12:55:21.844] AT+CFUN=1
[2019-10-04 12:55:21.891] OK
[2019-10-04 12:55:22.125] [00:00:47.093,719] <dbg> at_cmd.at_write: Sending command AT+CFUN=1
[2019-10-04 12:55:22.125] 
[2019-10-04 12:55:22.125] [00:00:47.133,117] <dbg> at_cmd.at_write: Bytes sent: 10
[2019-10-04 12:55:31.753] AT
[2019-10-04 12:55:32.065] OK
[2019-10-04 12:55:32.127] [00:00:57.311,767] <dbg> at_cmd.at_write: Sending command AT
[2019-10-04 12:55:32.143] 
[2019-10-04 12:55:32.143] [00:00:57.312,103] <dbg> at_cmd.at_write: Bytes sent: 3
[2019-10-04 12:56:54.363] %CESQ: 34,1
[2019-10-04 12:56:54.363] +CEREG: 2,"0411","00F63F11",7,0,0
[2019-10-04 12:56:56.019] +CEREG: 5,"0411","00F63F11",7
[2019-10-04 12:56:56.035] +CEDRXP: 4,"0101","0101","0000"
[2019-10-04 12:57:07.841] AT+CFUN=4
[2019-10-04 12:57:08.153] [00:02:33.082,122] <dbg> at_cmd.at_write: Sending command AT+CFUN=4
[2019-10-04 12:57:08.153] 
[2019-10-04 12:58:05.442] 
[2019-10-04 12:58:05.886] at
[2019-10-04 12:58:09.858] AT
[2019-10-04 12:58:10.427] AT

In my case, it actually froze up when I was trying to send it the CFUN=4 to disconnect. Based on the log messages, it looks like the call to send() the command over the socket never returned. (I let it sit for tens of minutes...)

I've never been able to prove it, but I've always been suspicious that the AT send command will lockup if there is data coming back the other way from a modem status message at exactly the wrong time. Early on in our development, while we were still deciding which messages were useful or interesting, we enabled *every* unsolicited message for the modem and just logged everything. Things used to lock up all the damn time. Over time, we turned off most of the messages and things got more stable. Admittedly, this was also as we were moving up through modem firmware versions, so it's likely the fixes in there also resolved most of the lockups, but I'm still suspicious...

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Fri, 04 Oct 2019 13:56:43 GMT

Also in Tera Term the following sequence of AT commands results in modem hang-up:

AT+CFUN?
AT+CEREG=3
AT%CESQ=1
AT%XSYSTEMMODE=1,0,0,0
AT+CEDRXS=2,4,"0101"
AT+CFUN=1
<<< wait until +CEREG: 1 (or 5) shows >>>
AT+CFUN=4
AT+CFUN=1
<<< wait until +CEREG: 2 shows >>>
AT+CFUN=4

AT_CMD debug messages in the application do not show anything out of the ordinary...

Could you please try to reproduce it? Maybe you can see what's happening here.

Our use case does not allow power cycling the device, so a hung up modem is a No-Go for our application. We really need to know what's going on here and how to prevent modem hang-up.

RE: nrf9160 modem not responding after switching to offline mode

Håkon Alseth — Fri, 04 Oct 2019 12:21:23 GMT

Hi,

Cycling between CFUN=1 and CFUN=4 shouldn't be a problem. But, as jbrzozoski mentions, please update to the latest modem fw on all boards.

I have seen behavior like this in LTE Link Monitor, if I get many debug prints incoming and also sending commands back-and-forth, where the GUI can drag on, but haven't seen this sort of behavior when using a terminal (putty, teraterm etc).

I would recommend checking the return value for the at_cmd calls, in case any of them fail.

Also try setting CONFIG_LOG=y, and CONFIG_AT_CMD_LOG_LEVEL_DBG=y to get debug logs from the at_cmd module.

Kind regards,

Håkon

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Fri, 04 Oct 2019 07:37:44 GMT

Yes, signal strength is rather low in here. I get RSRP values of 24 and 28, that's around -120 dBm. But anyway, that shouldn't not hang up the modem FW... Maybe I should record a modem trace, so a Nordic engineer can look into what's going on

RE: nrf9160 modem not responding after switching to offline mode

jbrzozoski — Thu, 03 Oct 2019 18:59:52 GMT

[quote userid="83854" url="~/f/nordic-q-a/52819/nrf9160-modem-not-responding-after-switching-to-offline-mode/213260"]In my simplified program I do not open any other sockets as far as I see. And I see the same behavior also with the AT_CLIENT sample.[/quote]

Can you run AT%CESQ=1 to enable RSRP reports before trying it again in at_client? I'm wondering if your modem is right on the fringe of unusable signal strength. That still shouldn't be causing this issue, but it would be interesting to know.

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Thu, 03 Oct 2019 17:56:09 GMT

I just checked, I am using MFW 1.0.1 on our custom board and 1.0.0 on the demo board.

I now updated also the demo board to 1.0.1, and I still see the same behavior. Thanks for pointing that out!

According to the AT Command Manual, the modem must be switched to OFFLINE when the XSYSTEMMODE is changed. I guess the issue is somehow connected to the eDRX mode. I also tried the CEDRX command after going ONLINE, but I does not make a difference.

In my simplified program I do not open any other sockets as far as I see. And I see the same behavior also with the AT_CLIENT sample.

Another Observation maybe worth noting is that for some time I still get CEREG notifications occasionally in multiples of the eDRX interval (82 seconds). So the modem is still running somehow and occasionally switches to a different cell, but is not responding…

RE: nrf9160 modem not responding after switching to offline mode

jbrzozoski — Thu, 03 Oct 2019 16:04:34 GMT

[quote userid="83854" url="~/f/nordic-q-a/52819/nrf9160-modem-not-responding-after-switching-to-offline-mode"]modem Firmware 1.0.0[/quote]

There is a MFW 1.0.1 out now for a while. I don't know of any specific mentions in the changelog related to this, but you should probably try it out just in case.

And I agree that this should not happen when you go OFFLINE and back, but it's actually the behavior I would expect going to POWER-OFF and back. Nordic has confirmed that once you put a modem in POWER OFF mode you shouldn't expect it to do *anything* until after the next reboot. Putting the modem into POWER OFF is a one-way trip.

EDIT: We are using EDRX in our application and can go online/offline repeatedly without issue. I'm wondering if it's somehow related to the CEDRXS or XSYSTEMMODE swtiching while offline. We rarely do either. The CEDRXS you can actually do while online. One possibly related issue I've seen is that if you have other sockets open to the modem for things like TCP/UDP traffic and are not servicing them, they can block the whole subsystem and cause the AT socket to block. But it doesn't look like you have other sockets open in this case...

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Thu, 03 Oct 2019 11:10:20 GMT

Our application is battery constrained, so the device is in eDRX mode as long as it is connected to the network.

RE: nrf9160 modem not responding after switching to offline mode

MJD093 — Thu, 03 Oct 2019 08:33:24 GMT

Have you considered only using eDRX when your device is going to be idle for a reasonable period and disabling eDRX when activily using the modem?

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Wed, 02 Oct 2019 18:42:41 GMT

Thank you for your sample. It seems to work as expected. But I don't think there's a problem with the sockets, but with the specific sequence of commands and the state the modem is in at that instant. The problem occurs when the modem is in eDRX mode, has no active connection (network status == 2) and is then set to OFFLINE or POWER_OFF.

No issue when not in eDRX, as in your example.

BTW, I see the same behavior with the AT_HOST sample, as I posted above.

RE: nrf9160 modem not responding after switching to offline mode

MJD093 — Wed, 02 Oct 2019 18:12:12 GMT

That's fair enough.

main.c:

/*
 * Copyright (c) 2018 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
 */

#include <zephyr.h>
#include <stdio.h>
#include <uart.h>
#include <string.h>
#include <bsd.h>
#include <net/socket.h>

#define AT_XSYSTEMMODE_GPS 			"AT\%XSYSTEMMODE=0,0,1,0"
#define AT_MAGPIO_GPS      			"AT\%XMAGPIO=1,0,0,1,1,1574,1577"
#define AT_CFUN_ON        			"AT+CFUN=1"
#define AT_XSYSTEMMODE_LTE			"AT\%XSYSTEMMODE=0,1,0,0"
#define AT_CFUN_OFF							"AT+CFUN=4"
#define AT_MAGPIO_CLEAR					"AT\%XMAGPIO"
#define AT_CEREG_LVL1						"AT+CEREG=1"
#define AT_CEREG_CHECK					"AT+CEREG?"

static const char			at_commands_LTE[][31]  = { AT_CFUN_OFF, AT_XSYSTEMMODE_LTE, AT_MAGPIO_CLEAR, AT_CFUN_ON };

#if defined(CONFIG_BSD_LIBRARY)

/**@brief Recoverable BSD library error. */
void bsd_recoverable_error_handler(uint32_t err)
{
	printk("bsdlib recoverable error: %lu\n", err);
}

/**@brief Irrecoverable BSD library error. */
void bsd_irrecoverable_error_handler(uint32_t err)
{
	printk("bsdlib irrecoverable error: %lu\n", err);

	__ASSERT_NO_MSG(false);
}

#endif /* defined(CONFIG_BSD_LIBRARY) */

static int send_at_command(int pSelector)
{
	int  at_sock;
	int  bytes_sent;
	int  bytes_received;
	char buf[20];
  char at_command[4][31];

	switch (pSelector)
	{
		case 0:
			memcpy(at_command, at_commands_LTE, sizeof(at_commands_LTE));
			break;
		default:
			printk("Error setting AT commands\n");
			break;
	}
	printk("Checking the network\n");
	at_sock = socket(AF_LTE, 0, NPROTO_AT);

	if (at_sock < 0) {
		printk("Socket failed to open\n");
		return -1;
	}
	printk("Socket ID: %d\n", at_sock);

	for (int i = 0; i < ARRAY_SIZE(at_command); i++)
	{
		printk("Sending AT command: %s\n", at_command[i]);
		bytes_sent = send(at_sock, at_command[i],
				  strlen(at_command[i]), 0);

		if (bytes_sent < 0) {
			close(at_sock);
			return -1;
		}

		do {
			bytes_received = recv(at_sock, buf, 50, 0);
		} while (bytes_received == 0);
		printk("Modem response: %s\n",buf);
		printk("Bytes received: %d\n",bytes_received);
		switch (bytes_received)
		{
			case 5:
				if (memcmp(buf, "OK", 2) != 0)
				{
					printk("Error with Modem Bytes received\n");
					close(at_sock);
					return -1;
				}
				break;
			default:
				printk("Invalid case for AT Check\n");
		}
	}
	close(at_sock);
	return 0;
}

void main(void)
{
	printk("Application started\n");
	while(1)
	{
		printk("Testing Modem\n");
		send_at_command(0);
		printk("Waiting 5 seconds\n");
		k_sleep(K_MSEC(5000));
	}
}

prj.conf:

# Use the development test RNG (not for production)
CONFIG_TEST_RANDOM_GENERATOR=y

# Networking, enable networking APIs
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_SOCKETS=y

# Allow Socket APIs to use POSIX names like socket(), send(), etc
# Careful with close(), close() only works on sockets when enabled
CONFIG_NET_SOCKETS_POSIX_NAMES=y

# BSD library
CONFIG_BSD_LIBRARY=y

# Main thread, reuse init stack
CONFIG_MAIN_THREAD_PRIORITY=7
CONFIG_MAIN_STACK_SIZE=4096

# Available memory for k_malloc
CONFIG_HEAP_MEM_POOL_SIZE=1024

# Enable stdout for printfs
CONFIG_STDOUT_CONSOLE=y

# Logging
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=4

# Build with newlib c library
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y

# Enable non-secure firmware as Normal mode
CONFIG_TRUSTED_EXECUTION_NONSECURE=y

CMakeLists.txt:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
#

cmake_minimum_required(VERSION 3.8.2)

set(BOARD nrf9160_pca10090ns)

include(../../../cmake/boilerplate.cmake NO_POLICY_SCOPE)
include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
project(Socket)

target_sources(app PRIVATE src/main.c)
zephyr_include_directories(src)

RE: nrf9160 modem not responding after switching to offline mode

Marcus_S — Wed, 02 Oct 2019 18:03:52 GMT

I'm afraid I cannot blindly install software from a source that is not validated - I would violate our company policy ;-)

But I will be happy to try it if you could send the source code, so I can check it out and compile it myself!

RE: nrf9160 modem not responding after switching to offline mode

MJD093 — Wed, 02 Oct 2019 17:53:48 GMT

Can you please flash this to your Development Kit witht the nRF Programmer application in the nRF Connect app, just want to check if this just a code issue or something related to the specific at commands you are sending.

This is a basic application I made a long time ago when I was new to socket programming that simply configures the modem for NB-IoT and repeats the process every 5 seconds. Tested this on my DK there and it still works. You won't get any CEREG notifications as it's not configured to do that but you should get the modem firing out AT commands happily.

The code is based off the source code for the at_client application. Do remove the numbers at the start of the file name, it's randomly added by the DevZone when I upload these hex files 😅

devzone.nordicsemi.com/.../5025.merged.hex