Refresh the timeout

Informative

How to keep the watchdog alive — refreshing the timeout (direct strategy) and feeding it from a timer (logical strategy). Binding rules: CHI-WDG-MUST-06, CHI-WDG-SHOULD-02, and CHI-WDG-SHOULD-03 in Wdg — Requirements.

Refresh at watchpoints (direct strategy)

Call Wdg_UpdateTimeout at each point where you want to prove the control flow is progressing. Each call delays the reset until the new timeout (in milliseconds) elapses:

Wdg_UpdateTimeout(50u);      /* the MCU resets unless refreshed again within 50 ms */

The value is bounded by the configured maximum_timeout for the current mode; a larger value raises WDG_DEVERR_PARAM_TIMEOUT. A value of 0 requests an (almost) immediate reset — a deliberate way to force a reset:

Wdg_UpdateTimeout(0u);       /* trigger a watchdog reset as soon as the HW allows */

Feed from a timer (logical strategy)

If your hardware needs the logical strategy, the driver keeps the timeout in software and a periodic timer — owned by the upper layer — calls Wdg_FeedHw to re-trigger the hardware:

/* in the upper layer's periodic timer interrupt */
void on_wdg_timer_tick(void)
{
    Wdg_FeedHw();            /* decrements the logical timeout by the call interval,
                                and re-triggers the HW only while it has not expired */
}

You still call Wdg_UpdateTimeout at your watchpoints to extend the logical timeout; Wdg_FeedHw counts it down. Setting up and calling the timer at the mode’s trigger interval is your responsibility — the WdgDrv does not configure timer hardware.

Note

Wdg_FeedHw is only used by the logical strategy; the direct strategy does not need it. For the logical strategy, once the logical timeout has expired Wdg_FeedHw stops re-triggering the hardware, so the reset fires (CHI-WDG-SHOULD-02).