Calling wdt_setup returns EBUSY

[Mike Granby]

Toolchain v2.70, SDK v2.7.0, VS Code, Windows

I am trying to enable the watchdog in my application, and I can successfully locate the device node and add a timeout, but when I call wdt_setup, it returns EBUSY. According to the docs, this means that it has already been setup. But I have not configured it, so I am at a loss as to how this is happening. I am building for FOTA, so I guess there is a boot loader running ahead of my code. Could that be setting up the watchdog and stopping me using it in my application?

The code is pretty simple:

        struct device const *wdt = DEVICE_DT_GET(DT_NODELABEL(wdt0));

        if( wdt ) {

                struct wdt_timeout_cfg cfg = {};

                cfg.flags      = WDT_FLAG_RESET_SOC;

                cfg.window.min = 0u;

                cfg.window.max = 1000u;

                int chan = wdt_install_timeout(wdt, &cfg);

                if( chan >= 0 ) {

                               

                        int r = wdt_setup(wdt, WDT_OPT_PAUSE_HALTED_BY_DBG);

                        if( !r ) {

                                for(;;) {

                                        k_sleep(K_MSEC(500));

                                        wdt_feed(wdt, chan);

                                }

                        }

                }

        }

Any ideas would be appreciated...

[Susheel Nuguru]

MCUBoot might have the WDT enabled in it. If you have CONFIG_WATCHDOG=y in your mcuboot.conf file

Then disable it by setting it to CONFIG_WATCHDOG=n (or set this anyway to n in this file just to be sure)

[Mike Granby]

I have no mcuboot.conf file in my project and I do not have a sysbuild folder, nor a child_image folder.

What should I add and where?

[Simonr]

Hi Mike

Susheel is off for vacation, so I'm looking into it in his stead.

The Watchdog timer won't be reset by a soft reset, os if the application has already run once and enabled it before doing a softreset (from an error handler or for DFU) the WDT wills till be active when you're back up and running again. So it that's the case for you as well it would be expected to get an EBUSY error I think, since the WDT is already running.

Best regards,

Simon

[Mike Granby]

Hmmm. Does WDT_FLAG_RESET_SOC force a soft reset or a hard reset? And are you saying that the enable state and the timeouts remain after the watchdog has reset the system? If the timeouts remain, that would mean that if you enabled say a one second watchdog once you had initialized it and it then tripped, you'd then only have one second to kick it again on startup, which seems off. Also, I haven't actually seen a reset, so I'm not convinced that it's actually get configured...

[Simonr]

Hey Mike

The WDT_FLAG_RESET_SOC must be set on the nRF side. This means that the Watchdog resets, which is not the same as a soft reset or hard reset. A Watchdog reset is its own type where afterwards the watchdog will be disabled and has to be enabled again to run. You can see the reset behavior table in the product specification for details.

Since you don't see a reset on the board there must be something else that is happening here, although I don't have a good idea as to what. Have you done any debugging to see what returns the EBUSY error when youo init the watch dog. If you step down when debugging you should be able to see that.

Please note that we're approaching the holiday season here in Norway, and from Dec. 21st to Jan. 2nd next year we will be severely understaffed, so response delays must be expected. Sorry for the inconvenience and happy holidays!

Best regards,

Simon