What (and why) is the most safe way to use a internal hardware watchdog in a scheduled bare-metal embedded app?

I've already used internal hardware watchdogs in several OS-less embedded applications (with static schedulers).

What I do is:

I look for the slowest periodic and lowest priority task
I set the watchdog timeout to something more than the period of the slowest task
then I kick the dog at the beginning of the slowest task

I think this is a minimalist but safe approach.

Is there any best practice? (personal experience or verified sources)

I've heard/seen people doing different things like kicking the dog more than once in different tasks, or kicking only if all tasks have been called within a timeout,...

Solution

Your question is a bit subjective, but there is something of an industry de facto standard for real-time applications, which goes like this:

Specify a maximum allowed response time of the system. As in, the longest time period that some task is allowed to take. Take ISRs etc in account. For example 1ms.
Set the dog to a time slightly longer than the specified response time.
Kick the dog from one single place in the whole program, preferably from the main() loop or similar suitable location (RTOS has no standard for where to do this, AFAIK).

This is the toughest requirement - ideally the dog doesn't know anything about your various tasks but is kept away from application logic.

In practice this might be hard to do for some systems - suppose you have flash bootloaders and similar which by their nature simply must take long time. Then you might have to do dirty stuff like placing watchdog kicks inside a specific driver. But it is a best practice to strive for.

So ideally you have this at the very top level of your application:

void main (void)
{
  /* init stuff */

  for(;;)
  {
    kick_dog();
    result = execute();
    error_handler(result);
  }
}

As a side-effect of this policy, it eliminates the risk of having "talented" people end up kicking the dog from inside a ISR.