Re: Eeyore hates American movies too...

Hello Frank,


"You might as well service them silently, ..." usually isn't an option if these interrupts come from sources that aren't supposed to ever generate an interrupt. "Or have them set a flag, ..." is almost correct but you'd have to drop the word "Or" :-)

The set flag idea can be seen as an almost free sanity
check, but it is not more than that. You can sprinkle your
code with thousands of sanity checks. But they're just
sanity checks and nothing else. So you have to decide
how many sanity checks you provide, 999 or 1000. In
theory you don't need sanity checks, so I see them
mainly as an aid during development. And leave them
in afterwards.


Something needs to happen upon a set flag. A flag alone usually won't protect enough.


That's why I wrote:
"Or have them set a flag,
and turn on a sirene - if you must - but let the system continue as
healthy as possible instead of letting it go bananas first and wait
for the WDT.".

A 'flag' can be anything, upto and including an email to the VP.


Only thing is that it seems that the presented code doesn't contain a mechanism to generate any flags. That was what puzzled me.


WDT's are bandages and only cover a very very very
small part of (all) potential problems. Allowing a uC/uP
to go bananas because of missing stubs is plain
stupid and a WDT is certainly not the way to catch
those. Static discharges - yes, that should not occur -
can alter bits in configuration registers, and all of
a sudden you will have your unexpected interrupt.
Not providing a stub or harmless vector for it, invites
the watchdog, but a system rebooting from a watchdog
may already have caused damage or at least aggrevation.
Imagine a production line with half finished products.
In medical systems, it could be worse than that.


A WDT is like an airbag. Shouldn't go off but if it does and if the recovery after reset is handled properly it can save the situation as much as an airbag does. IOW your glasses might be busted and the car is totaled but you didn't break your neck. Think of it as crash-worthiness.


A WDT is for anything you couldn't possibly anticipate in your
design. Missing vectors does not fall into that group. Full recovery
after a reset is (or can be) very difficult, all data in ram should
be treated as possibly corrupt because you have no idea (yet) why the
WDT triggered and what has happened in the milliseconds before it kicked
in. You would be totally insane not initializing vectors to stubs even
for sources that are not supposed to generate any interrupts in the
first place.


It can detect missing vectors (if set up to do it). Also, some uC have special registers that lets the system know whether a reset was caused by a WDT time-out or by something else like the BOR.


Interrupts are (in most cases) not the result from processing data, but from
external events like timers, counters, hardware inputs etc. Don't let
a WDT take care of unexpected or impossible events from those sources.
Make a note of it (a flag, a sirene, an email to the VP) if you want,
but keep your system up and running. Or do a jmp reset yourself if you
really don't have a clue how to handle it.

Never let your system run crazy for milliseconds and possibly corrupting
all your vulnerable data, before a WDT kicks in, if you can avoid it.
Be good and put vectors in, for all your interrupts, including the
so-called impossible ones.


You seriously lack some understanding and should be kept
far away from any uC/uP stuff other than toys perhaps ;)


Then don't develop a complicated coronary crisis anywhere near a large city, including you country. Chances are that a system containing one of my designs will be used on you and it does contain a uC. Of course, while I did the architecture the code was written by experts and was then vetted by numerous other experts in design reviews. And it has undergone rather rigorous agency testing. They look in every nook and cranny. Plus they expect some HW interlocks.


Can't complain about code written by experts.


Good to know that you seem to trust my code architecture then ;-)

--
Regards, Joerg

http://www.analogconsultants.com
.

Relevant Pages

  • Re: The idea of disabling interrupts
    ... disable interrupts for a short period, and you don't call any OS/library ... While flags may seem to resemble in one way like a semaphore in its ... 1)A flag may get modified any time and may introduce write/read ... for your product or application,provided your talking about RTOS .You ...
    (comp.arch.embedded)
  • Re: Eeyore hates American movies too...
    ... these interrupts come from sources that aren't supposed to ever generate ... The set flag idea can be seen as an almost free sanity ... A WDT is like an airbag. ...
    (sci.electronics.design)
  • Re: The idea of disabling interrupts
    ... disable interrupts for a short period, and you don't call any OS/library ... it can be a useful method. ... 1)A flag may get modified any time and may introduce write/read ...
    (comp.arch.embedded)
  • DFHSM Doc on when it resets the "dataset changed flag(bit)"
    ... I can't find a definitive statement in the DFhsm books as to when and ... we do both FDR and HSM backups. ... FDR has a setting to not reset the flag in a mixed environment ...
    (bit.listserv.ibm-main)
  • [PATCH] scheduler: introduce SCHED_RESET_ON_FORK scheduling policy flag, Second try
    ... This patch introduces a new flag SCHED_RESET_ON_FORK which can be passed ... priority is reset to DEFAULT_PRIO if it was higher and b) the scheduling ...
    (Linux-Kernel)