Electronic – STM32F103 simple countdown timer (with no interrupts)

As you've discovered, handling counter overflow with an interrupt handler is tricky and race-prone. Even with your priority boost, you'll get the wrong answer if interrupts are disabled while you read the counter. There's a much simpler technique which works if you're not reading the clock from interrupt context (note that I'm using the DWT cycle counter here, which is built into the processor thus fast and simple):

uint64_t last_cycle_count_64 = 0;

// Call at least every 2^32 cycles (every 59.6 seconds @ 72 MHz).
// Do not call from interrupt context!
uint64_t GetCycleCount64() {
  last_cycle_count_64 += DWT->CYCCNT - (uint32_t)(last_cycle_count_64);
  return last_cycle_count_64;
}

If you need to call it from interrupt context (or with a preemptive OS):

volatile uint64_t last_cycle_count_64 = 0;

// Call at least every 2^32 cycles (every 59.6 seconds @ 72 MHz).
uint64_t GetCycleCount64() {
  uint32_t primask;
  asm volatile ("mrs %0, PRIMASK" : "=r"(primask));
  asm volatile ("cpsid i");  // Disable interrupts.
  int64_t r = last_cycle_count_64;
  r += DWT->CYCCNT - (uint32_t)(r);
  last_cycle_count_64 = r;
  asm volatile ("msr PRIMASK, %0" : : "r"(primask));  // Restore interrupts.
  return r;
}

You may need to enable the cycle counter first:

DWT->CYCCNT |= DWT_CTRL_CYCCNTENA_Msk;  // Set bit 0.

Regular watchdog timers must be reset at some time before they time out. If you have a 100ms WDT you can reset it every 99.9ms or every 10us and it will never time out.

Window watchdog timers have a time window within which they must be reset. If you reset it too early or too late (from the previous reset) it will cause the processor to reset.

The purpose, if it is not obvious, is to help ensure that the code resetting the WDT is the intended code, operating in the intended fashion. Some kind of unforeseen condition that generates high-frequency WDT resets won't prevent the system from being reset.

Running a WDT from the system clock could be a bit of an issue- if the clock fails and if there is not an independent clock monitor circuit, bad things can happen. The independent clock for the WDT means that if the thing for some reason started running at 1/10 speed, the WDT would reset (but the window WDT would not).

Use both if you can.

As the page says, resetting the WDT with an ISR is generally bad juju (but may be acceptable if the ISR verifies the reset of the firmware is functioning before resetting the timer).