Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Håkon Alseth — Mon, 12 May 2025 10:32:36 GMT

Hi,

Ok, let me know if you are able to recreate the scenario again, and please check the callstack and/or assertion log if it happens.

Kind regards,

Håkon

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Amirtha — Mon, 12 May 2025 10:16:03 GMT

Hi,

Yes, Firmware is working as expected.

Thanks,
Amirtha N

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Håkon Alseth — Mon, 12 May 2025 08:17:55 GMT

Hi,

This means that no fault occurred for 2 days? Ie. the firmware still behaves as expected?

Kind regards,

Håkon

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Amirtha — Mon, 12 May 2025 06:58:39 GMT

Hi

As per your suggestion, we disabled the watchdog timer (WDT) and tested the device for two days, during which no resets occurred. However, since our device requires a watchdog to handle potential hangs, Any suggestions on how to add watchdog efficiently.

Best Regards,
Amirtha N

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Håkon Alseth — Fri, 09 May 2025 12:20:57 GMT

Hi,

First callstack shows that you're validating your image, ie. in mcuboot context.

Second callstack shows a workq item being executed, but no fault/assert.

It can be beneficial if you disable the watchdog while trying to debug your issue.

Kind regards,

Håkon

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Amirtha — Fri, 09 May 2025 11:48:30 GMT

Hi

I have attached the call stack that appears when the connection request is received.

Best Regards,
Amirtha N

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Amirtha — Fri, 09 May 2025 11:21:00 GMT

Hi

Once the connection request is received, a reset occurs. During the reset, the provided call stack appears. I have attached the screenshot.

Best Regards,
Amirtha N

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Håkon Alseth — Fri, 09 May 2025 10:21:04 GMT

Hi,

That callstack does not seem to hold anything useful, looks like it is from after a reset has occurred.

Did you attach without resetting the target after it faulted?

Kind regards,

Håkon

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Shanmugam — Fri, 09 May 2025 07:54:37 GMT

We are using UART for logging. As you mentioned, we have disabled CONFIG_RESET_ON_FATAL_ERROR to prevent a reset from occurring. We have attached a screenshot that includes the log and call stack.

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Håkon Alseth — Thu, 08 May 2025 16:45:54 GMT

Hi,

It looks like you are using RTT for logging and receiving an assertion or fault.

First, lets enable blocking assert/faults:

CONFIG_RESET_ON_FATAL_ERROR=n

If you still do not see any assert output on RTT, could you please enter debug mode and share the callstack?

Kind regards,

Håkon

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Shanmugam — Thu, 08 May 2025 10:09:42 GMT

we have upgraded to nRF Connect SDK v2.6.4 on our nRF7002 DK (nrf5340). However, we are encountering an issue where the device undergoes an unknown reset repeatedly after a connection request. Issue Description: After initiating a connection request, the device resets unexpectedly and continuously at the same point and reproducible. The issue did not occur in the previous SDK version (v2.6.1).devzone.nordicsemi.com/.../sdk_5F00_2_5F00_6_5F00_2_5F00_reset_5F00_log.txt

RE: Facing hang in Zephyr wifi library and watchdog reset not occurred that instances

Håkon Alseth — Mon, 05 May 2025 14:22:00 GMT

Hi,

[quote user=""]In rare cases, we’ve observed that the nRF5340 hangs during Wi-Fi library operations, and in such instances, the watchdog reset does not trigger. [/quote]

This indicates that the scenario is yielding to the thread where you reload the watchdog.

Could you share a bit more information about your application?

Q1: What NCS version are you using?

Q2: Do you have "RPU Recovery" enabled? This is a feature that resets the nRF7002 in case it does not respond over (Q)SPI.

To enable the RPU recovery (available from v2.5-branch/v2.6.2 and forward), you need to enable this kconfig:

https://docs.nordicsemi.com/bundle/ncs-2.6.2/page/nrf/drivers/wifi/nrf700x/nrf700x.html#cmdoption-arg-CONFIG_NRF_WIFI_RPU_RECOVERY

And implement the Wi-Fi Ready library + handle the events in the application itself:

https://docs.nordicsemi.com/bundle/ncs-2.6.2/page/nrf/libraries/networking/wifi_ready.html

An example of such an handling is implemented in the wifi/sta sample:

https://docs.nordicsemi.com/bundle/ncs-2.6.2/page/nrf/samples/wifi/sta/README.html#rpu_recovery

See the implementations guarded with "CONFIG_WIFI_READY_LIB" here:

https://github.com/nrfconnect/sdk-nrf/blob/v2.5-branch/samples/wifi/sta/src/main.c#L56

Kind regards,

Håkon