ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

moose — Sat, 18 Dec 2021 03:46:42 GMT

I just tested this module using the new zephyr version (2.7.99) and it seems to work fine now. Thanks for your support.

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

Simon — Mon, 20 Sep 2021 09:05:10 GMT

Thanks for sharing the solution Spencer. Appreciated.

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

SpencerMougey — Thu, 26 Aug 2021 20:57:38 GMT

I just encountered this same issue today and found a work around for it. I don't know if it is applicable to all systems, but at least the nRF5340 supports it, and I would imagine the other nRF processors would as well. As for the other Zephyr processors, that is TBD.

Essentially it is just an ordering swap in the task_wdt_add function call as pointed out in one of the previous comments. The task_wdt_add runs the feed before the hardware watchdog has been run via the wdt_setup call which causes the underlying Nordic driver to assert (rightfully so in my opinion). I have included the fix below.

	/* look for unused channel (reload_period set to 0) */
	for (int id = 0; id < ARRAY_SIZE(channels); id++) {
		if (channels[id].reload_period == 0) {
			channels[id].reload_period = reload_period;
			channels[id].user_data = user_data;
			channels[id].timeout_abs_ticks = K_TICKS_FOREVER;
			channels[id].callback = callback;
			//task_wdt_feed(id); // THIS IS WHAT CAUSES THE SYSTEM CRASH!!!!!

#ifdef CONFIG_TASK_WDT_HW_FALLBACK
			if (!hw_wdt_started && hw_wdt_dev) {
				/* also start fallback hw wdt */
				wdt_setup(hw_wdt_dev,
					WDT_OPT_PAUSE_HALTED_BY_DBG);
				hw_wdt_started = true;
			}
#endif
            // Feed the watchdog after the hardware setup is called.
            // Otherwise, the feed will throw an assert because the 
            // watchdog has not been set up yet.
            task_wdt_feed(id);
			return id;
		}

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

Simon — Tue, 25 May 2021 14:25:38 GMT

I tested the sample zephyr\samples\subsys\task_wdt with an nRF52833dk_nrf52833 and it seemed to run fine.

I got the same log output as mentioned in https://github.com/nrfconnect/sdk-zephyr/tree/a409bc732b62ce659462114ccf2870ada1724e1c/samples/subsys/task_wdt#sample-output

However, setting CONFIG_ASSERT=Y triggered the same assert you got. It seems like this subsystem is quite new and recently added to Zephyr (15th of March), so that's why it might be some undiscovered bugs. Would you be able to create a Zephyr issue https://github.com/zephyrproject-rtos/zephyr/issues/new/choose? If you don't get an answer, please get back to me here and I will look into it. If you resolve it, it would be nice if you could share the solution.

Best regards,

Simon

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

moose — Fri, 21 May 2021 01:14:32 GMT

Simon, as mentioned I am using the zephyr task wdt module which internally configures the hardware wdt. I call the task_wdt_init function first, then task_wdt_add, and finally task_wdt_feed on a periodic event. Here is the link for the module code link. In the code, you can see that wdt_setup function is called within task_wdt_add.

Please note that within task_wdt_add, task_wdt_feed is called before wdt_setup which in turn call wdt_feed function. Not sure if this problematic.

Any ideas on how to proceed? Has the task_wdt module ever worked on a nordic SoC? Thx!

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

moose — Fri, 21 May 2021 01:14:23 GMT

Please note that within task_wdt_add, task_wdt_feed is called before wdt_setup which in turn call wdt_feed function. Not sure if this problematic.

Any ideas on how to proceed? Has the task_wdt module ever worked on a nordic SoC? Thx!

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

Simon — Tue, 18 May 2021 13:35:07 GMT

Did you call the enable function before calling feed function? As you can see in the file nrfx_wdt.c, it will set p_cb->state to NRFX_DRV_STATE_POWERED_ON in nrfx_wdt_enable(). If this is set, the assert won't trigger.

Call wdt_setup() before doing anything else, it will trigger wdt_nrf_setup(), which will trigger nrfx_wdt_enable()

Best regards,

Simon

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

moose — Fri, 14 May 2021 18:22:29 GMT

Hello Simon,

Here is the full error message and attached is a screenshot of the output.

ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_ON] @ WEST_TOPDIR/modules/hal/nordic/nrfx/drivers

For some reason, it didn't specify the actual file but when I look in that directory, I think the most relevant file is the nrfx_wdt.c included within the src directory. Within that file, I see the above assertion statement on line 155 within the nrfx_wdt_channel_feed function.

This function is called by wdt_nrf_feed function within the wdt_nrfx.c. I am assuming this function is eventually called by task_wdt.c but I could find the exact link. task_wdt.c uses wdt_feed function which I don't know where is that one is defined.

Hope this provides some data and look forward to your input. Thanks!

RE: ASSERTION FAIL [m_cb[p_instance->drv_inst_idx].state == NRFX_DRV_STATE_POWERED_0

Simon — Fri, 14 May 2021 12:46:09 GMT

I'm not able to find the assert you're referring to, could you point me to the file and line of the assert?

Best regards,

Simon