3

The watchdog of an ATMEL ATXMega128 should have been enabled with fuses. It triggers a reset, if the timer was not reset within the configured time span. I want to be sure, that it is enabled and working properly.

What is a good method to verify that the watchdog is enabled and working on the finished PCB?

Is it common practice to prepare a spare input signal in order to trigger the watchdog artificially? Should the watchdog trigger, if I pull the external oscillator to GND, or will this stop the watchdog too?

Jonas Stein
  • 410
  • 3
  • 14
  • 4
    Do you know what WD is supposed to do? Make it doing it. – Eugene Sh. Sep 14 '18 at 17:01
  • 4
    Your code is supposed to kick the watchdog (WD reset) periodically. So if it doesn't, you will observe a periodic reset. Just make it to do something detectable on each reset. – Eugene Sh. Sep 14 '18 at 17:10
  • 2
    Some uC’s have a register that stores the cause of the last reset, including a WD reset. Check to see if yours has such a thing. – Chris Knudsen Sep 15 '18 at 22:45
  • 1
    @Passerby I call it "feed the watchdog" (to prevent starvation). – U. Windl Apr 13 '21 at 13:16
  • The intent of the watchdog is to cause system reset in case OS kernel hangs, right? Load an OS kernel module that takes some critical kernel lock and never frees it. That would emulate a broken device driver and if the watchdog cannot trigger reset for that case, it's quite a pointless watchdog. – Mikko Rantalainen Aug 16 '22 at 10:25

3 Answers3

2

AtMega MCUs have a watchdog with dedicated 32kHz oscillator, so yes: putting the main oscillator on pause will trigger it. Writing a test software which intentionally fails to service the watchdog is another possibility, and it will enable you to validate not only the fact that the watchdog in enabled, but easily measure the timeout as well.

Dedicating a pin triggering a fault makes less sense. I'd never include that in the final software, and if you're going to do a test software anyway, you don't need the pin.

Dmitry Grigoryev
  • 25,576
  • 5
  • 45
  • 106
1

You can test through a sequence. Use an existing non critical output like an led as a test signal. Program the board with a test sequence that will toggle the led and loop, And does not pet the watchdog. Test for the loop. Then program it to do a second loop, where it will not reach if the specified watchdog timer does not reboot. Test to make sure it passes the watchdog petting. These two steps will make sure the hardware part of the watchdog are good.

The rest is ensuring your final code does not affect the watchdog by disabling it or petting it when something that shouldn't lock up gets locked up.

As to your question about the external clock being stopped, I'm not familiar with any microcontroller that would have two independent clock sources that would keep the watchdog ticking when the main clock source is disabled. In a externally grounded clock situation, a watchdog reset wouldn't fix that anyway, unless your code can switch to an internal clock for the main code after that reset. The watchdog is meant to clear software related hangs. But I'm sure those exist for mission critical applications.

Passerby
  • 72,580
  • 7
  • 90
  • 202
  • 1
    Actually many MCUs run the watchdog off a different clock than the CPU typically uses. Take for the example the STM32L0's, where the watchdog runs off the same low frequency source as the RTC. Granted, if you select an *external crystal* RTC source, and then break that, it might not work. – Chris Stratton Sep 15 '18 at 04:08
  • Thats what i mean. Many microcontrollers use one main clock source and the accessory clock runs off it too. But I'm not well versed in many many microcontroller types so I can't say they don't exist. It all depends on the microcontroller – Passerby Sep 15 '18 at 04:19
  • 1
    @ChrisStratton STM32L0 has two watchdogs. One clocked from the internal RC oscillator at around 40 kHz (no option to set it to the external crystal) directly resetting the MCU (no interrupt) and the other clocked from the main clock. And the second one actually allows an interrupt before reset. They are called, respectively, IWDG and WWDG. – jaskij Sep 15 '18 at 18:33
  • A watchdog will indeed clear some software bugs, but its primary purpose is to recover from hardware glitches (like RAM corruption or loss of PLL lock) which obviously cannot be fixed in software. Using a watchdog as a countermeasure against *known* software deadlocks (instead of fixing the root cause) is a very bad practice. – Dmitry Grigoryev Sep 03 '19 at 13:12
0

When your watchdog expires, it will call a specific function.

The normal action of that function will be to take whatever remedial action is required under those circumstances. However, before it does that, it should check a variable called something like WDT_test, and only do the remedial thing if it's false.

If WDT_test is true, it should instead log a report (perform some action) that the WDT is working.

To test the WDT, set WDT_test true, stop kicking the WDT, and wait for the report within a certain time.

That's the non-intrusive way to do it. To do a more complete end to end test, just stop kicking the WDT and wait to see whether it eventually performs the remedial action.

Neil_UK
  • 158,152
  • 3
  • 173
  • 387
  • 3
    No. A *hardware* watchdog as described in the question does not "call a specific function" typically it triggers a reset. At most, it triggers an interrupt which could in turn call a function. You are thinking of a purely software watchdog, which is not what the question asked was about. – Chris Stratton Sep 15 '18 at 04:06