Thanks for the details.
Doesn't instill consumer confidence in buying new expensive electronics!



"D Yuniskis" wrote in message
...
Hi John,

John Keiser wrote:
Several months ago I salvaged a Westington flat screen [LTV-32w6 HD] that
had been abandoned because the tuner failed. As the tuner is part of the
motherboard I didn't fix it was easier to use an external VCR as the
tuner. TV functions fine. I assume the tuner died in a power surge.
Yesterday, the power failed and I awoke to find that the TV had turned
itself on but no sound. Toggling mute and adding external speakers did
not work. I assumed the worst but guessed that maybe this was a
microprocessor locked into mute. I unplugged the set and tried again
after 15 minutes. Sound was restored. Whew!
I wonder how many consumers would be so lucky? Is this type of
sensitivity common? [I have a nice old 32inch CRT that has been immmune
from these problems and provides a great picture.] I'll probably add a
line conditioner, but, really, are consumers expected to be that
cautious?

Most modern devices use mmicroprocessors or microcontrollers. Often
*several* (VCRs typically had three or four; my cassette deck has
one just to count capstan revolutions!).

If power fails -- wholly or partially -- it is possible for any
of those processors to reset. Or, *partially* reset. Or, "get
confused" (and head off to never-never land doing something
unintended -- like "executing" *data*).

If the processor doesn't have brownout detection (or it isn;t
implemented properly), a processor can get stuck in one of these
confused states. If the processor doesn't have a hardware
watchdog (or, it isn;t implemented properly), once confused it
can fail to get OUT of that state.

Regardless, sloppy code in one or more of these can result
in them running, but failing to move to their *correct*
operational state. This is a common sort of bug -- the
code makes assumptions (implicitly or explicitly) that,
suddenly, are not valid (because something unforseen has
happened -- e.g., a power glitch between instructions
102,678,993 and 102,678,994). Because the programmer made
those assumptions, he didn't code to protect *against*
them being incorrect.

So, for example, if there are two processors in the set,
they *always* are powered up at the same exact instant
(there is ONLY one power button, right?). And, the code
that they execute never changes. So, 23.0257 milliseconds
after RESET, processor #1 has done blah and can now
send the "OK, I am ready to fire up the display" message
to processor #2. Meanwhile, 24.6802 milliseconds after
RESET, processor #2 goes looking for the "OK I am ready"
message, *sees* it (since it was delivered about a millisecond
earlier) and correctly fires up the display.

Now, if something happens that causes processor #1 to come
out of RESET a bit later -- perhaps, 3 milliseconds (e.g.,
maybe power at *it's* reset circuit glitched a bit more than
at #2's; or, it's brownout detector fired *twice* instead of
once) -- then it (#1) might not issue the "OK" message until
26.0257 milliseconds (since it's RESET was 3 milliseconds
later than #2's). Meanwhile, at 24.6802 milliseconds, processor
#2 went looking for the message AND IT WASN'T THERE!!

Had the programmer NOT *assumed* the message *would* be there,
he would have told #2 to wait for it -- for some amount of time.
Instead, he might just crash; or, *incorrectly* (buggy) "wait";
or, fire up the display prematurely causing some other fault
(that shuts him down -- or, something *else* gets shut down), etc.

The heat of almost ALL software bugs is one or more bad assumptions.
When the world behaves in ways programmers don't expect, you
get "anomalous behaviors" -- things that seeem unexplained and
that change without any action on your part to "fix" them.

shrug Makes you wonder how *anything* works properly! :-/

(of course, there can also be hardware issues that are causing
this -- like a cap not completely discharging so the circuit
it connects to never sees the "reset")