Embedded Muse 89 Copyright 2003 TGG November 24, 2003

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Even More on Watchdogs
- Backups
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

I often do this seminar on-site, for companies with a dozen or more embedded folks who’d like to learn more efficient ways to build firmware. See https://www.ganssle.com/onsite.htm.

Even More on Watchdogs

Amongst other approaches, the paper referenced above suggests building a state machine to tickle the WDT. Instead of simply calling a tickle_wdt() routine, generate code that looks something like:

main(){
state=0x5555;
wdt_a();
.
.
.
state+=0x2222;
wdt_b();
}

wdt_a(){
if (state!= 0x5555) halt;
state+=0x1111;
}

wdt_b(){
if (state!= 0x8888) halt;
state=0;
kick dog;
}

A crashed program that wanders into the tickle routine will fail, since the state machine will be in the wrong condition.

Perhaps it’s safe to assume that the code will again crash when wdt_b() returns, so the system will miss the next watchdog tickle. But… perhaps not – who knows what evil lurks in the mind of runaway software?

Is this fear paranoid? You bet. But the WDT might be the last line of defense between deflecting the Earth-bound asteroid and utter disaster, or at least in rebooting the pacemaker before grandpa collapses. Assuming that crashed code will operate in any benign mode is naïve.

Perhaps a better approach is to modify the wdt_b() routine as follows:

wdt_b(){
if (state!= 0x8888) halt;
kick dog;
if (state!= 0x8888) halt;
state=0;
}

The double-check of variable “state” insures the system halts (so the watchdog can issue a reset) even if rogue code wandered into wdt_b() just before issuing the “kick dog” command.

The interesting thing about watchdog timers is that a proper design requires very little code. And yet they’re surprisingly tricky, as a decent watchdog has to fire despite ANY sort of software failure.

Backups

A recent Microsoft study (http://www.itsecurity.com/tecsnews/oct2003/oct168.htm) suggests that over a quarter of small companies don’t back up at all, and 40% do so less than once a month.

Even the Electronic Frontier Foundation was recently attacked (http://ftp.gnu.org/MISSING-FILES.README), and have suggested their FTP archives may have been compromised.

Do you backup regularly? Are your backups readable? Is *everything* saved? A glib “yes” isn’t enough. Evaluate your backup strategy a couple of times a year. The alternative – losing source code – is too horrible and expensive to contemplate.

Steve Litt’s site has some good info on backing up. See http://www.troubleshooters.com/tpromag/9807.htm, and (for Linux users)
http://www.troubleshooters.com/lpm/200208/200208.htm.

We do have many backup media options today. CDs are cheap, but their capacity isn’t all that great. DVDs are an interesting alternative - the media price isn’t too bad, and it’s cheap to mail the burned DVD to a friend in a different state for off-site storage.

Recently I’ve started to use an external 200Gb Maxtor disk drive for daily backups, coupled with weekly DVD burns. The Firewire connection provides is dramatically faster than burning a DVD. A number of contacts have claimed that the Firewire drives are as fast as internal disks, but my tests (using the nice Sandra benchmarks at http://www.sisoftware.net/) demonstrate that an internal ATA100 disk is about twice as fast as the external Firewire unit.

Joke for the Week

My favorite: “Spend time with your spouse - Communicating with your wife or girlfriend (sic) may seem like a radical suggestion, but the time investment may offer long-term rewards. Spending any amount of time talking about your "relationship" may free up more Internet time for you later on, when your ADSL or Cable link to the World Wide Web has been restored.”