In my last post I mentioned using RFBees for a communications link between a remote sensor and a laptop PC. During my testing, the RFBees would become unresponsive at random intervals for some reason. Not liking to walk across the room, or worse, go outside in the elements to physically reset the RFBee, I came up with a workaround using the AVR watchdog timer library. This library gives the RFBee’s ATMega168 processor the ability to automatically reset itself if the watchdog detects that the code is running longer than some given time. For further reference see the ATmega datasheet for your board (I’m referencing this one: http://www.atmel.com/Images/doc2545.pdf for the ATmega48/88/168, specifically pages 49-52).
Here’s an example of the code I'm using:
#include <avr/wdt.h>
…
void setup()
{
// I think I need to do this first thing to avoid infinite reset loops
// see the datasheet for ATMEGA48/88/168 p. 51
// and documentation for wdt.h library
// at http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html
wdt_disable();
...initialize other stuff
// enable the watchdog timer with a four second timeout
// it may be possible to set to 8 seconds for some processors - see the wdt.h
// header file and your datasheet
wdt_enable(WDTO_4S);
}
void loop()
{
// first thing, reset the watchdog timer
wdt_reset();
// do some other work that might seize up randomly
// if we don’t reach the top of the loop function in 4 seconds
// the watchdog times out causing a system reset
// where we will re-enter the setup() method above
...
}
This code has been working for me without any problems. I think the danger would be in calling the wdt_enable function with too small of a timeout value such that the watchdog timer repeatedly times out causing an infinite loop of resets...please use caution if you attempt this at home!
I haven’t debugged the code at this point to understand what causes the system to hang randomly. I’ll keep digging and share what I find here...