I am making good progress on a few of my projects and I am pondering the next steps on the vault hardware. Once I get a solid program complete, and that is getting really close, I want to design a project specific board for the controller. I am at a crossroads of unknown direction in watchdog timer options. I have seen some references to watchdog code to be dropped in to a sketch and have seen hardware watchdog elements as well. As a matter of fact, Jon sells one here on Superhouse I could integrate. Being as I am looking at creating an all in one board design though, I think I would probably want to integrate that into my board instead of an add-on. I am leaning towards hardware based timer. The reason being, since I don’t have any experience with this stuff, I would believe that if your processor hangs up, your software based timer is gonna hang too?
Anyone with experience that wants to kick in some thought on this?
The circuit for the hardware watchdog is quite simple, so incorporating it into your design should be fairly easy.
However, a word of warning about a trap that I fell into when I first implemented a hardware watchdog: you need a way to disable it for development. It’s really annoying to have a watchdog that hits reset on your microcontroller just when you’re in the middle of uploading new code and it’s not executing its watchdog reset code!
That was a head-slap moment when it first happened to me.
So in your design, put a 2-pin header with a jumper (or a cut-track if you prefer) between reset and the watchdog output, so that you can disable it while you’re doing software development.
I am trying to setup my watch dog timer but it is not working as expected.
It’s all connected to the correct pins - 5v, ground, reset and digital pin 3 as in the example
I am trying to pat the dog, it pats, but the timer resets the board in 5 minutes.
To confirm if it pats - I used multi-meter and can see it sends HIGH and LOW signals to the IN pin. But when it pats - yellow LED on watchdog doesn’t blink. There is a manual way to pat the dog - if I connect IN pin from the watchdog with TX pin on Arduino or with PIN13 (Arduino LED which set to high) - yellow LED on watchdog time blinks and pats the DOG.
Do you have any suggestions here? Any possible reasons why sending HIGH and LOW signals to D3 pin doesn’t reset the timer?
This is what i have working in my code
in the setting section
WATCH DOG SETTINGS */ #define ENABLE_EXTERNAL_WATCHDOG true // set this to false if you dont have a watchdog #define WATCHDOG_PIN 8
bool watchdog_status = false;
unsigned long watchdog_timmer = 0;
this is in void loop()
// Prevent arduino from resetting if everything is fine
if (ENABLE_EXTERNAL_WATCHDOG == true)
{
resetWatchDog();
}
and the void resetWatchDog()
Blockquote
*Reset watch-dog module
*Prevents Arduino from resetting if everything is fine
*@return void
*/
void resetWatchDog()
{
if (getTimer(watchdog_timmer, 1000))
{
watchdog_status = !watchdog_status;
}
digitalWrite(WATCHDOG_PIN, watchdog_status);
}
@Bedrock Your code is missing the body of getTimer() function. Here’s the full code:
/* WATCH DOG SETTINGS */
#define ENABLE_EXTERNAL_WATCHDOG true // set this to false if you dont have a watchdog
#define WATCHDOG_PIN 8
bool watchdog_status = false;
unsigned long watchdog_timmer = 0;
/**
* Initial setup - called once
*
* @return void
*/
void setup ()
{
// Enable watchdog
if (ENABLE_EXTERNAL_WATCHDOG == true)
{
pinMode(WATCHDOG_PIN, OUTPUT);
digitalWrite(WATCHDOG_PIN, LOW);
}
}
/**
* Main loop program
*
* @return void
*/
void loop ()
{
// Prevent arduino from resetting if everything is fine
if (ENABLE_EXTERNAL_WATCHDOG == true)
{
resetWatchDog();
}
}
/**
* Reset watch-dog module
* Prevents Arduino from resetting if everything is fine
*
* @return void
*/
void resetWatchDog()
{
if (getTimer(watchdog_timmer, 1000))
{
watchdog_status = !watchdog_status;
}
digitalWrite(WATCHDOG_PIN, watchdog_status);
}
/**
* Determine if given timer has reached given interval
*
* @param unsigned long tmr The current timer
* @param int interval Length of time to run timer
* @return bool True when timer is complete
* @return bool False when timer is counting
*/
bool getTimer(unsigned long &tmr, int interval)
{
// Set initial value
if (tmr < 1)
{
tmr = millis();
}
// Determine difference of our timer against millis()
if (millis() - tmr >= interval)
{
// Complete. Reset timer
tmr = 0;
return true;
}
// Still needs to "count"
return false;
}
That was the problem in my case why it didn’t pat the dog - pin wasn’t set as OUTPUT in setup.
There was another issue I had with my Arduino Mega and Watch Dog timer (that was before the problem I mentioned above) - on a light switch controller (Jon’s version) tried connecting watch dog INPUT pin to PIN 50 on the arduino, it was always patting the dog as PIN 50 is connected to something else on the board (maybe TX/RX or one of LAN pins), not exactly sure what. So need to find another pin.
Is there any particular reason why the digitalWrite to WATCHDOG_PIN is done outside of the if statement…? digitalWrite isn’t a trivial function, and most passes through, you’re just re-asserting it’s existing state.
To that point, I’d probably combine the two lines as:
I find that more explicit… It literally reads to me as: set the pin to the opposite of what it was last time.
@Serg — I though digitalWrite already ensures the pin is output… Perhaps it’s only checking for PWM output mode… I know it checks a couple things, which is why I said before that it’s not a trivial function. It’s a good idea to always remember your setup in any case, always set pin states, etc., which is why I can’t actually remember what it does or doesn’t check off hand — I never trust it to check anything, and make a point of setting it myself explicitly.
If the pin was still set for input, however, then yes, I believe you were just turning the internal pullup resistor on and off. Not an overly reliable way to drive the watchdogs input line. By comparison, on the D13 pin, you’ve got that built in LED providing grounding while you’ve got the pullup turned off. Not really how I would recommend driving your LED’s…
@Serg I was going to ask did you set the output mode. But you mentioned you used a multi-meter to test the output, so I assumed it was working
@Fredderic Because you want 1sec period of HIGH and a 1sec period of LOW. Without testing your code on actual hardware, I’m not sure if that single digitalWrite’s pulse is enough to trigger the watch-dog?
ahhh… huh? The way I’ve written it there, was a trivial rewrite of yours and Bedrock’s, and should function identically — with the exception of removing the redundant pin writes on every single pass through the function. It still has the 1s timer check just like yours, and isn’t a “single digitalWrite pulse” at all, it’s a 50% duty cycle pulse with a 2s period, exactly like yours.
Serg’s way — copied directly from the documentation page on the watchdog module — does the delay(20), and I was wondering initially if that was too short, because I know some watchdogs insist on a certain minimum hold time to avoid confusing noise as a pat. But being as it is taken right off the documentation page, I’d expect it to be sufficient.
It’s interesting to note, the multimeter could also have been grounding it enough to make it work while you were measuring it, and then stop working as soon as you took the meter away.
I can’t explain this, it wasn’t set to Output, but yes multi-meter showed spikes when PIN value was triggered LOW/HIGH. LED only started blinking when I set the pin to OUTPUT, happy it’s working now
I even tried to change the default delay from delay(20) to 1000 and 5000, that didn’t help.
