nRF91 modem watchdog fault when re-activating LTE

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Mon, 16 Feb 2026 08:52:43 GMT

Hi,

Thanks for the suggestion. The issue we observed was related to Windows symlink handling. If symlinks are not enabled before cloning the workspace, Git may check them out as regular files, which causes TFM include path issues during build. Enabling Windows Developer Mode and ensuring symlinks are properly created resolved the problem on our side.

We will review this further and consider contributing if needed.

Best Regards,
Syed Maysum

RE: nRF91 modem watchdog fault when re-activating LTE

JordanYates — Thu, 12 Feb 2026 23:54:12 GMT

Hi Syed,

Thank you for persisting with getting the reproducing sample working and for escalating internally.

The Windows error is interesting, it would be amazing if you could submit a PR upstream to update https://docs.zephyrproject.org/latest/services/tfm/overview.html with the error that can occur on Windows and how to fix it, as I am certain you will not be the only person to run into it.

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Thu, 12 Feb 2026 15:20:53 GMT

Hi,

I’ve now been able to reproduce the behavior on our side using the provided nrf91_modem_fault example on nrf9161dk.

(For transparency: on Windows we initially hit a TF-M build issue related to symlink handling in the Zephyr workspace. After enabling Windows Developer Mode and ensuring Git symlinks were properly supported, the project built correctly.)

The sequence behaves as you described:

LTE connects correctly on boot then entering shipping mode works fine
If LTE is reactivated within ~1 minute, it reconnects successfully
If LTE is reactivated after ~60+ seconds of deactivation, the modem consistently crashes with:
```
[00:01:23.234,283] <err> nrf_modem: Modem has crashed, reason 0x2, PC: 0x467da
```

The issue is fully reproducible and occurs consistently with the same fault reason and program counter. Since this appears to be modem-side behavior during functional mode reactivation, we are escalating this internally for further investigation.

I will update you as soon as we have feedback from the modem team.

Best Regards,
Syed Maysum

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Wed, 11 Feb 2026 16:37:28 GMT

Hi,

Thanks for sharing your build steps.

On my side (Windows environment), I set up a clean workspace and followed essentially the same flow as you:

mkdir fault_demo
cd fault_demo
west init -m https://github.com/Embeint/infuse-sdk.git
west update
cd infuse-sdk
git checkout example/nrf91_modem_fault
west update
west build -b nrf9161dk/nrf9161/ns samples/nrf91_modem_fault -p always

However, the build fails during the TF-M stage with:

zephyr/modules/trusted-firmware-m/nordic/include/RTE_Device.h:14:10:
fatal error: zephyr/devicetree.h: No such file or directory

The file does exist in the workspace, so it appears that the TF-M compile step is not picking up Zephyr’s include path on my host. I’m checking this internally to proceed with reproducing the watchdog issue and will get back to you by tomorrow.

Best Regards,
Syed Maysum

RE: nRF91 modem watchdog fault when re-activating LTE

JordanYates — Tue, 10 Feb 2026 23:55:52 GMT

> I are currently trying to build and run the exact minimal sample you shared, using your west workspace. While setting this up in a clean environment, I am hitting a TF-M build error on nrf9161dk/nrf9161/ns.

Can you share the build error? A clean environment build works fine locally for me.

(.zephyr_venv) jordan@TAURUS:~/code$ mkdir fault_demo
(.zephyr_venv) jordan@TAURUS:~/code$ cd fault_demo/
(.zephyr_venv) jordan@TAURUS:~/code/fault_demo$ west init -m git@github.com:Embeint/infuse-sdk.git
(.zephyr_venv) jordan@TAURUS:~/code/fault_demo$ cd infuse-sdk/
(.zephyr_venv) jordan@TAURUS:~/code/fault_demo/infuse-sdk$ git checkout example/nrf91_modem_fault
(.zephyr_venv) jordan@TAURUS:~/code/fault_demo/infuse-sdk$ west update
(.zephyr_venv) jordan@TAURUS:~/code/fault_demo/infuse-sdk$ west build -b nrf9161dk/nrf9161/ns ./samples/nrf91_modem_fault/
...
[506/506] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      193308 B       704 KB     26.81%
             RAM:       79684 B       168 KB     46.32%
     RetainedMem:          0 GB        256 B      0.00%
        IDT_LIST:          0 GB        32 KB      0.00%
Generating files from /home/jordan/code/fault_demo/infuse-sdk/build/zephyr/zephyr.elf for board: nrf9161dk

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Tue, 10 Feb 2026 12:30:10 GMT

Hi,

Thanks for the detailed feedback. I understand your point, and I agree that reworking application architecture just to debug a modem fault isn’t ideal.

I are currently trying to build and run the exact minimal sample you shared, using your west workspace. While setting this up in a clean environment, I am hitting a TF-M build error on nrf9161dk/nrf9161/ns. I am checking it internally and once we have the sample building, we’ll proceed with reproducing the modem watchdog issue and report back.

Best Regards,
Syed Maysum

RE: nRF91 modem watchdog fault when re-activating LTE

JordanYates — Mon, 09 Feb 2026 22:58:20 GMT

> We tested the same shutdown, wait and re-initialization sequence in a clean nRF Connect SDK v3.1.0 environment on nRF9161DK. In this setup, the modem reliably re-initializes and reconnects after the wait period, and we do not see an NRF_MODEM_FAULT_HW_WD_RESET (0x2).

Was any attempt made to run the minimal reproducible sample that you asked for and I provided?

> This indicates the watchdog reset is not caused by the modem firmware or the shutdown delay itself, but is likely related to how LTE and the modem are being controlled in the application when using the connection-manager path.

That is not a surprise (in that extra work needs to happen to trigger the fault, e.g. UDP packets).

> As next steps to isolate the issue in your setup, we recommend first ensuring that all components that may access the modem are fully stopped before calling conn_mgr_all_if_down(). In particular, please verify that all LTE sockets are closed, any DNS/REST/HTTP clients are stopped, no AT commands are in progress, and modem tracing (if enabled) is idle.

So the suggestion is to throw out all the integrations with Zephyr APIs that Nordic has written? I have little interest in attempting to re-architecture my networking flow to diagnose a fault in a component I don't control and can't debug just because you haven't run the sample I have already spent time providing.

> We also recommend running the LTE down/up sequence from a dedicated application context (for example an application thread or work item), rather than directly from a network or connection-manager callback.

You can already see this is being done in the provided example.

> to confirm whether the watchdog reset is specific to the connection-manager integration.

This is a watchdog failure inside the modem core. How could it have anything to do with the connection manager? The modem literally faults before `nrf_modem_lib_init` even returns.

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Mon, 09 Feb 2026 16:32:28 GMT

Hi,

We tested the same shutdown, wait and re-initialization sequence in a clean nRF Connect SDK v3.1.0 environment on nRF9161DK. We have attached the main.c and prj.conf used for this test for your reference. The sequence was to connect LTE, bring LTE offline, call nrf_modem_lib_shutdown(), wait for more than 60 seconds, then call nrf_modem_lib_init() and reconnect LTE. In this setup, the modem reliably re-initializes and reconnects after the wait period, and we do not see an NRF_MODEM_FAULT_HW_WD_RESET (0x2).

*** Booting nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
[00:00:00.406,127] <inf> app: Init modem library (boot)
[00:00:00.653,900] <inf> app: nrf_modem_lib_init() err=0
[00:00:00.653,930] <inf> app: Enable LTE for first time
[00:00:07.089,691] <inf> app: lte_lc_connect() err=0
[00:00:07.089,721] <inf> app: Waiting 15 seconds to enter shipping mode...
[00:00:22.089,782] <inf> app: Bring down LTE for shipping mode
[00:00:22.549,072] <inf> app: lte_lc_offline() err=0
[00:00:22.549,072] <inf> app: Shutting down modem library...
[00:00:22.566,162] <inf> app: nrf_modem_lib_shutdown() err=0
[00:00:22.566,162] <inf> app: 65 seconds to exit shipping mode
[00:00:27.566,253] <inf> app: 60 seconds to exit shipping mode
[00:00:32.566,345] <inf> app: 55 seconds to exit shipping mode
[00:00:37.566,436] <inf> app: 50 seconds to exit shipping mode
[00:00:42.566,528] <inf> app: 45 seconds to exit shipping mode
[00:00:47.566,619] <inf> app: 40 seconds to exit shipping mode
[00:00:52.566,711] <inf> app: 35 seconds to exit shipping mode
[00:00:57.566,802] <inf> app: 30 seconds to exit shipping mode
[00:01:02.566,894] <inf> app: 25 seconds to exit shipping mode
[00:01:07.566,986] <inf> app: 20 seconds to exit shipping mode
[00:01:12.567,077] <inf> app: 15 seconds to exit shipping mode
[00:01:17.567,169] <inf> app: 10 seconds to exit shipping mode
[00:01:22.567,260] <inf> app: 5 seconds to exit shipping mode
[00:01:27.567,352] <inf> app: Re-init modem library...
[00:01:27.815,948] <inf> app: nrf_modem_lib_init() err=0
[00:01:28.016,052] <inf> app: Exiting shipping mode: reconnect LTE
[00:01:34.214,813] <inf> app: lte_lc_connect() err=0

This indicates the watchdog reset is not caused by the modem firmware or the shutdown delay itself, but is likely related to how LTE and the modem are being controlled in the application when using the connection-manager path.

As next steps to isolate the issue in your setup, we recommend first ensuring that all components that may access the modem are fully stopped before calling conn_mgr_all_if_down(). In particular, please verify that all LTE sockets are closed, any DNS/REST/HTTP clients are stopped, no AT commands are in progress, and modem tracing (if enabled) is idle.

We also recommend running the LTE down/up sequence from a dedicated application context (for example an application thread or work item), rather than directly from a network or connection-manager callback. As a diagnostic step, you can temporarily bypass conn_mgr_all_if_*() and directly call lte_lc_offline(), nrf_modem_lib_shutdown(), nrf_modem_lib_init(), and lte_lc_connect() to confirm whether the watchdog reset is specific to the connection-manager integration.

Best Regards,
Syed Maysum

devzone.nordicsemi.com/.../4403.prj.conf devzone.nordicsemi.com/.../13404.main.c

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Fri, 06 Feb 2026 17:28:31 GMT

Hi,

Thanks for sharing the sample and detailed logs. We’ll set this up and try reproducing the behavior on our side, and will get back to you early next week with an update.

Best Regards,
Syed Maysum

RE: nRF91 modem watchdog fault when re-activating LTE

JordanYates — Fri, 06 Feb 2026 00:14:43 GMT

> could you please share the nRF Connect SDK version you are using

I do not use nRF Connect SDK directly, but the modem libraries are extracted from NCS v3.1.0.

> and a minimal code example or sample project that reproduces the issue?

The following sample application reproduces the issue on a nRF9161DK.

https://github.com/Embeint/infuse-sdk/tree/example/nrf91_modem_fault/samples/nrf91_modem_fault

west build -b nrf9161dk/nrf9161/ns infuse-sdk/samples/nrf91_modem_fault/
west flash -d build/nrf9161dk/nrf9161/ns/nrf91_modem_fault/
...
*** Booting Zephyr OS build v4.3.0-168-g7eab92b0458b ***
[00:00:00.401,092] <inf> infuse:        Version: 0.0.0+00000000
[00:00:00.401,153] <inf> infuse:          Board: nrf9161dk@0.9.0/nrf9161/ns
[00:00:02.079,193] <inf> app: Enable LTE for first time
[00:00:02.121,887] <inf> app: Waiting 15 seconds to enter shipping mode...
[00:00:17.122,009] <inf> app: Bring down LTE for shipping mode
[00:00:17.176,696] <inf> app: 65 seconds to exit shipping mode
[00:01:22.177,886] <inf> app: Exiting shipping mode
[00:01:22.405,639] <err> nrf_modem: Modem has crashed, reason 0x2, PC: 0x468de
[00:01:22.405,639] <err> modem_monitor: Modem fault, rebooting in 2 seconds...

Note the example is setup to output serial logs over RTT, not the serial port.

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Thu, 05 Feb 2026 17:28:54 GMT

Hi,

Thanks for the clarification. From your testing, the watchdog reset only occurs when the modem is fully shut down and re-initialized (conn_mgr_all_if_down/up), and not when simply disconnecting and reconnecting LTE. This suggests the issue is tied to the modem restart path rather than LTE reactivation itself.

To help us reproduce and investigate this further, could you please share the nRF Connect SDK version you are using and a minimal code example or sample project that reproduces the issue? With that, we can try to reproduce this locally and determine the next steps.

Best Regards,
Syed Maysum

RE: nRF91 modem watchdog fault when re-activating LTE

JordanYates — Thu, 05 Feb 2026 00:43:13 GMT

> Can you try fully shutting down and re-initializing the modem in the following way as mentioned in the documentation:

I unintentionally left out some information in the original post. The activation and de-activation code paths look like this:

		LOG_INF("Device activated, enable LTE");
		conn_mgr_all_if_up(false);
		conn_mgr_all_if_connect(false);
		...
		LOG_INF("Device de-activated, disable LTE");
		conn_mgr_all_if_disconnect(false);
		conn_mgr_all_if_down(false);

The connect/disconnect calls do indeed call the functional modes I mentioned, but the `if_up` and `if_down` calls get routed down to lte_net_if_enable and lte_net_if_disable, which are already fully shutting down and re-initialising the modem.

This was confirmed by adding extra logging inside those functions, but also by the trace module logging (see below).

> If the issue still reproduces after using this sequence, please enable modem traces and share them so it can be investigated further.

I have enabled modem traces (attached below), however I am doubtful the trace will be useful in practice, since the tracing module suspends in response to the modem powering down, and there is no logic to re-enable it once it comes back up.

[00:00:01.783,386] <inf> modem_trace_backend: Modem_trace RTT backend channel 1
[00:00:01.783,416] <inf> nrf_modem_lib_trace: Trace thread ready
[00:00:01.784,942] <inf> nrf_modem_lib_trace: Trace level override: 2
...
[00:00:26.409,027] <inf> app: Device de-activated, disable LTE
[00:00:27.173,004] <inf> epacket_udp: Network disconnected
[00:00:27.189,422] <inf> nrf_modem_lib_trace: Modem was turned off, no more traces
...
[00:02:02.850,982] <inf> app: Device activated, enable LTE
[00:02:03.280,090] <err> nrf_modem: Modem has crashed, reason 0x2, PC: 0x468de
[00:02:03.280,120] <err> modem_monitor: Modem fault, rebooting in 2 seconds...

devzone.nordicsemi.com/.../1770250638_5F00_nrf_5F00_modem_5F00_trace.zip

After removing the calls to `conn_mgr_all_if_up/down` (and therefore not shutting down the modem entirely), I am able to transition between shipping and active modes without faults. However this doesn't explain the root cause of this issue, which is how a hardware watchdog can expire less than a second after booting from the shutdown state.

RE: nRF91 modem watchdog fault when re-activating LTE

Syed Maysum Abbas Zaidi — Wed, 04 Feb 2026 13:02:13 GMT

Hi,

Thanks for the detailed report. NRF_MODEM_FAULT_HW_WD_RESET (0x2) means the modem firmware has become unresponsive and its internal hardware watchdog has reset the modem. And from your description, this is triggered when LTE is deactivated for a longer period and then re-activated. Can you try fully shutting down and re-initializing the modem in the following way as mentioned in the documentation:

When entering shipping mode: stop LTE users and call nrf_modem_shutdown()
When exiting shipping mode: call nrf_modem_init() and then reconnect LTE

If the issue still reproduces after using this sequence, please enable modem traces and share them so it can be investigated further.

Best Regards,
Syed Maysum