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...

[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...