Watchdog that should be taken out and shot

It's probably the lead developer's dog's birthday written in base 9 and shown as a hex number. Almost certainly there is an ex post facto explanation as to why it is the technically sound choice.

Silly question, but "periodically" = inside an ISR?

Either that or it was the last time that the UART documentation was updated :-)

No no. I had initially headed off on that route before the little voice in the back of my head smacked the bigger voice on the back of its head for being so stupid.

The GUI I use is a polled system and I call the watchdog refresher whenever I update the GUI, which is pretty much all the time.

Oh honestly Lewin, where else would you kick the dog?

Do you know of any really good discussions of the care and feeding* of watchdogs? Where I've seen it done well it involved _all_ of the critical tasks setting a bit in a variable, then an ISR that would check for all the bits set, then reset the variable and kick the dog if they were. The nice thing about this is that you couldn't have one bit of software that would function correctly and kick the dog while the rest of the system went to hell in a handbasket.

• In one of your many books, perhaps?

Perhaps the interrupt idea isn't so crazy after all. Perhaps if I had a counter running in a timer ISR which caused a branch to zero at a certain level could be a dirty hack to get around the problem? Seems a shame when a chap at Sharp has spent at least a morning designing a nice watch dog.

Neat trick. Another one noted for future use :-)

I think my kicking mechanism works, I just need it to notice when I stop kicking!

I haven't written anything formally on the topic, but it has been discussed here many times. One of the techniques I've used is to have an entry counter in each thread. At regular intervals (in an ISR), these counters are checked. If they fall within guard bands [which may have to be pretty wide], the WDT is kicked; otherwise, bite.

Ganssle has some excellent material on the topic, of course.

I'm using a 75410, which has a watchdog that looks the same. I don't use it because it is only any use in faulty software and if I had faulty software why would I expect the watchdog code to be any better. However, I can test it out.

For me 2^25 counts is 0.65 seconds.

Yep, reset after a fraction of a second. Using a larger period gave the expected results.

I poked 0x90, 0x91 and 0x98 rather than oring but other... Peter

Big Brother is watch(dogg)ing you!

I fear you're missing the point of a watchdog.

A watchdog isn't there to catch faulty software - as you say, you shouldn't have any. (Although some would disagree). It's there as an EMI-recovery device. *Any* microprocessor-based product, no matter how well designed, can be made to go "off in the weeds" with a strong enough EMI spike. The watchdog is there to limit the time the processor can stay off in the weeds.

Steve

it

software

test

shouldn't

can

weeds.

After such a spike the last thing I would worry about is the CPU. That would system appear to be working but not actually be. Internal and external EMI are a big issue for the delicate measurements. In any case my comment was tongue-in-cheek as I'm sure you were aware.

Peter

Hello Tim,

Kicking is animal cruelty...

"Go Natural" works best for our shepherd mix, can be bought at our local feed store ;-)

We did a lot of EMI testing on a number of products (albeit some years ago). We found that "going off on the weeds" took a certain finite threshold; we tried turning it up to find the the "permanent damage" threshold, and never did. We passed on the "Nuclear EMP" option.

I wasn't, but a) I do now and b) I'm relieved ;).

Steve

There are failure causes other than faulty software. Some are permanent, some transient. Think cosmic rays.

Of course, my software is perfect and can never fail so I only need the watchdog in case of alien death rays ;-)

Maybe my maths is a bit off but even at 0.65s then I would expect it to reset - even if I expected it to take longer.

Didn't happen for me :-( Is there something in the RCPC registers that needs to be set before watchdogs have any bite? Is there anything that can stop them?

Hold on I'll try......nope, didn't work.

Perhaps there is something in the hardware that can prevent a WDT? Perhaps I have a disabling pin activated or something but I'm not aware of any that it could be.

"Tom Lucas" wrote in message news: snipped-for-privacy@proxy00.news.clara.net...

Problem Solved!

It turns out that the address of the watchdog register is actually

D'oh!

OK, a bit late in the thread, but

martin

Good link. Thanks.

Which I have found and it is very good.

Hello Martin,

Thanks, very nice link. Jack really knows his stuff and I subscribed to his Embedded Muse.

One statement in there that I don't really get is this: "Reloading the program counter may not properly reinitialize the CPU?s internals." I'd have thought that properly written code will do one thing first: Set all the CPU internals before doing anything.

Then there is the external watchdog where he rightfully criticizes that wiggling it's "I'm alive" line can also be done by code that has run out of control. This begs the question: Are there reasonably priced external WDTs that require a little serial password? If there aren't, why not? I mean, it doesn't have to be a 128bit hacker-proof variety.