Watchdog timer and reseting

[nForce]

When writing a program for an MCU, we have to take into account the watchdog timer. If our program execution time exceeds the time of watchdog timer, then the timer resets the system. But how do we know how much time have we? Can we write to registers of watchdog timer and set the time?

How do we know how much time the program will execute?

Can someone explain? Thanks.

[mikerj]

You can measure the execution time with the watchdog disabled, either through toggling a port pin and using an oscilloscope, or by adding a small amount of extra code to save timestamps (from a free running timer) into memory where you can view it with e.g. a debugger.  Obviously you need to avoid adding code with will greatly increase execution time e.g. using a bit-banged UART to send out execution would be pretty useless.

[nForce]

Can we write to an internal register of WDT to extend the time of counting? Let's say we want to implement bit-banging.

[Kasper]

What MCU are you using?

You can measure watchdog timeout similar to how mikerj describes measuring execution time. Toggle an output and measure it with scope. For watchdog, toggle an output at start of code and look for time between toggles aka time between resets aka time it takes for watchdog to cause reset + time it takes to reset.

[nForce]

I am not using any MCU. I just ask, what can we do in theory, and how we configure WDT. I have to know!

What do we do if we make time-consuming function let's say discrete fourier transform, and because of that the WDT resets the system. What now?

[wraper]

I am not using any MCU. I just ask, what can we do in theory, and how we configure WDT. I have to know!

Open some MCU datasheet FFS. WDT is different in different MCUs, timeout usually is configurable.

What do we do if we make time-consuming function let's say discrete fourier transform, and because of that the WDT resets the system. What now?

You can reset WDT from multiple points in the program. If any routine takes a lot of time, then it should be reset from within it as well.

[bson]

Can we write to an internal register of WDT to extend the time of counting? Let's say we want to implement bit-banging.

A WDT always has a "clear" mechanism, in fact this is how they work - your code needs to clear it.  Normally this is done through some kind of path that guarantees the µC works normally, for example a timer interrupt.  If something truly bad happens like interrupts end up disabled this timer interrupt will never happen, the WDT doesn't get cleared, and so will trigger an hard reset when you're out of time.

Also be aware that once you run the WDT you can no longer debug your code - it will stop on a breakpoint, but as soon as you try to step or continue the WDT will issue a reset and the debugger will get really confused.  So the WDT is typically something you add as an ultimate reliability mechanism to make sure your system can't wedge hard once everything already works like it should.  But you could still have major software bugs, the WDT only prevents hard seize-ups.  And you don't want too much complicated code in the way of clearing the WDT, or you may find you have bugs in this code and get spurious nuisance resets that are REALLY hard to track down.

[@rt]

WDT might be clocked with it’s own RC clock, so you can’t measure it down to the wire if your mcu has a better clock course.
You might be a WDT clock prescaler, so that could be set in program to adjust the timer at execution time,
but I can’t think of a reason to do anything other than clear it.

[langwadt]

Can we write to an internal register of WDT to extend the time of counting? Let's say we want to implement bit-banging.

A WDT always has a "clear" mechanism, in fact this is how they work - your code needs to clear it.  Normally this is done through some kind of path that guarantees the µC works normally, for example a timer interrupt.  If something truly bad happens like interrupts end up disabled this timer interrupt will never happen, the WDT doesn't get cleared, and so will trigger an hard reset when you're out of time.

Also be aware that once you run the WDT you can no longer debug your code - it will stop on a breakpoint, but as soon as you try to step or continue the WDT will issue a reset and the debugger will get really confused.  So the WDT is typically something you add as an ultimate reliability mechanism to make sure your system can't wedge hard once everything already works like it should.  But you could still have major software bugs, the WDT only prevents hard seize-ups.  And you don't want too much complicated code in the way of clearing the WDT, or you may find you have bugs in this code and get spurious nuisance resets that are REALLY hard to track down.

feeding the dog in a timer interrupt can be dangerous, the timer could happily feed the dog every millisecond while the main loop is stuck waiting for a week with
two Tuesdays 

instead make some combination ala;  the mainloop feeds the dog every so often but only if it sees a counter incremented in an interrupt has changed

and the out of reset it should generally be possible to determine if the cause of the reset was the watchdog

[bson]

feeding the dog in a timer interrupt can be dangerous, the timer could happily feed the dog every millisecond while the main loop is stuck waiting for a week with
two Tuesdays 

Yes, but that means your main loop has a software bug, but the hardware is working correctly.  You shouldn't use a WDT to catch software problems; restrict it to failures on a hardware or very close to hardware level (such as leaving interrupts disabled).  The WDT is not a debugging aid.

Use timer interrupt to implement your own timeout mechanisms and deal with it gracefully.  You can do that as long as the hardware works correctly, which is what the WDT guarantees.

[wraper]

feeding the dog in a timer interrupt can be dangerous, the timer could happily feed the dog every millisecond while the main loop is stuck waiting for a week with
two Tuesdays 

Yes, but that means your main loop has a software bug, but the hardware is working correctly.  You shouldn't use a WDT to catch software problems; restrict it to failures on a hardware or very close to hardware level (such as leaving interrupts disabled).  The WDT is not a debugging aid.

And what if there was a bit flip caused by power transient or radiation, causing main loop going astray? Not to say we all know that programs are 100% bug free  . Often bugs may cause unintended behavior very rarely and under particular conditions, very hard to reproduce. If something goes wrong, you want device in the field to restart properly, regardless of the cause. Not hang because the cause of malfunction was not kosher enough. As example, I don't want controller in my soldering station to hang while enabling heating and causing cartridge glowing red.

[langwadt]

feeding the dog in a timer interrupt can be dangerous, the timer could happily feed the dog every millisecond while the main loop is stuck waiting for a week with
two Tuesdays 

Yes, but that means your main loop has a software bug, but the hardware is working correctly.  You shouldn't use a WDT to catch software problems; restrict it to failures on a hardware or very close to hardware level (such as leaving interrupts disabled).  The WDT is not a debugging aid.

Use timer interrupt to implement your own timeout mechanisms and deal with it gracefully.  You can do that as long as the hardware works correctly, which is what the WDT guarantees.

doesn't matter if it's a software bug, hardware bug or cosmic radiation if the code isn't doing what it is intended to do you want to get out of that before something catastrophic happens like a heater staying on and setting the house on fire

[Kasper]

[...]  And you don't want too much complicated code in the way of clearing the WDT, or you may find you have bugs in this code and get spurious nuisance resets that are REALLY hard to track down.

Reminds me of some code I reviewed that had a wdt clear with comment "kick the f***ing dog". I think it took them a while to realize a watchdog clear was needed there.

[Sal Ammoniac]

Jack Ganssle has a good write-up on watchdogs on his site:

http://www.ganssle.com/watchdogs.htm