Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #30015

Re: Power On Self Test

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: Power On Self Test
Date 2020-10-03 12:08 -0700
Organization A noiseless patient Spider
Message-ID <rlai8a$2p2$1@dont-email.me> (permalink)
References (8 earlier) <rkhnr4$idr$1@dont-email.me> <rkhut9$vh4$1@dont-email.me> <rki1l6$hr1$1@dont-email.me> <rki9bm$75r$1@dont-email.me> <947ec9a8-1f61-45b9-a742-1fd6d9b6c2d4o@googlegroups.com>

Show all headers | View raw


On 10/2/2020 5:29 PM, Dave Nadler wrote:
> On Thursday, September 24, 2020 at 10:10:05 AM UTC-4, Don Y wrote:
>> Failures rarely occur when the device IS off. But, the act of
>> removing power to a device is just as hazardous as APPLYING power.
> 
> Absolutely!
> My two favorites, sadly seen multiple times in shipping systems where
> I was asked to find out what happened, both involving capacitors:
> 
> 1) Large cap added to uC ADC to 'smooth things out'.
> Guess where that stored energy goes when power is removed?

What about the off-board cumzintas and gozoutas?  What can they
potentially encounter that could deleteriously affect (yet not
spectacularly destroy) the functionality of the circuit?

While you can put invariants in your code to constrain/verify the
nature of inputs at some place in the code, doing so with hardware
requires incurring recurring costs and an active imagination to
consider the many ways your device can be "misapplied".

How often do your products see any formal shake-n-bake prior to release?
Any predictive analysis as to their expected longevity?  Expected
warranty repair costs?

Do you routinely get reports from manufacturing test as to the
problems they encountered after formal release?  If not YOUR
responsibility, does the manufacturing engineer consult (even
informally) with you so you are aware of the problems that
your designs are experiencing "getting out the door"?

What about returned devices?  Do you get a report as to why
they are being returned?  Are there genuine failures?  UX issues?
How do you close your design loop so the next product gets
*better*?

[Yeah, you might be 99.73% sure that the user "did something
wrong"... but, do you refuse to replace the device and risk
the customer's wrath (and bad "publicity") just to cut your
warranty costs?]

I rescued a Nest thermostat some time ago (wanting it for it's
ergonomics, not electronics).  It had been scrapped because the
Rh input was no longer operational (the software can detect
the presence of signals on each wire and could never see, nor
utilize, the signal on Rh).

Did the user legitimately connect the device to their home
wiring and it failed -- from NORMAL use?  Or, did the user
screw up, in some way?

> 2) Large cap after secondary linear regulator.
> Guess where that stored energy goes when power is removed?
> 
> Sorry nothing to do with POST...

The problem with "power" -- for most devices -- is that the designer
(and, thus, the device) has very little control of it after deployment.

The user can rapidly reapply power after removing it (off, then on,
quickly).  Will the supplies come up in the prescribed sequence, given
that they may not have completely discharged to their NORMAL "starting
point" (0V)?

The mains can do the same.

The mains can sag or run hot -- whenever and for as long as they want.
Does your device "know" when this is happening?  Or, does it only
"know" in the sense that it is stressed beyond its nominal design
conditions?

The "wrong" power supply can be used.  E.g., a wall wart that "happens
to fit" but is the wrong voltage (low or high), polarity (+, -, AC),
or inadequate ampacity.

The power supply may fail to age "gracefully" (does anyone really think
all these crappy 'lytics were used in products INTENTIONALLY?).  Were
those 2000Hr caps? ... now still trying to perform 3 years down the road?

The power supply may be considered a "check off" item and not truly
designed to the actual usage of the device in question.  E.g.,
a device left powered on 24/7/365 sees ~8000 PoHrs each year.
Are the components rated for that (esp low ESR filter caps used
in the switcher)?  Was the wall wart outsourced to the cheapest
vendor on Alibaba?  ("Yes, it's 12V @3A... you can trust us!")

A device may see a different usage pattern than intended (any
environmental factor stressed:  time, temperature, humidity, etc.).

I power the devices in my current design via PoE.  So, it is
worth my design effort to ensure the PSE has added hooks to let
me QUANTITATIVELY verify its proper operation; any monies spent
there are amortized over the 100+ PDs.

And, as "I" am the entity powering the devices up/down, there's
little cost to tracking how often I do this (for each device)
along with the PoH that each device experiences.  The alternative
is just to make FUTURE design decisions based on assumptions about
usage patterns that led to failures/faults.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Power On Self Test pozz <pozzugno@gmail.com> - 2020-09-23 12:13 +0200
  Re: Power On Self Test Don Y <blockedofcourse@foo.invalid> - 2020-09-23 03:57 -0700
    Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-23 14:13 +0200
      Re: Power On Self Test Richard Damon <Richard@Damon-Family.org> - 2020-09-23 08:51 -0400
        Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-23 16:03 +0200
          Re: Power On Self Test Don Y <blockedofcourse@foo.invalid> - 2020-09-23 09:36 -0700
            Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-23 21:02 +0200
              Re: Power On Self Test Don Y <blockedofcourse@foo.invalid> - 2020-09-23 12:32 -0700
                Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-24 11:10 +0200
                Re: Power On Self Test Don Y <blockedofcourse@foo.invalid> - 2020-09-24 04:11 -0700
                Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-24 13:58 +0200
                Re: Power On Self Test Don Y <blockedofcourse@foo.invalid> - 2020-09-24 07:09 -0700
                Re: Power On Self Test Dave Nadler <drn@nadler.com> - 2020-10-02 17:29 -0700
                Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-10-03 18:22 +0200
                Re: Power On Self Test Dave Nadler <drn@nadler.com> - 2020-10-03 09:27 -0700
                Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-10-04 12:48 +0200
                Re: Power On Self Test Don Y <blockedofcourse@foo.invalid> - 2020-10-03 12:08 -0700
              Re: Power On Self Test Paul Rubin <no.email@nospam.invalid> - 2020-09-23 13:05 -0700
                Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-24 11:15 +0200
          Re: Power On Self Test Richard Damon <Richard@Damon-Family.org> - 2020-09-23 21:55 -0400
            Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-24 11:26 +0200
              Re: Power On Self Test Richard Damon <Richard@Damon-Family.org> - 2020-09-24 09:01 -0400
                Re: Power On Self Test David Brown <david.brown@hesbynett.no> - 2020-09-24 16:21 +0200
  Re: Power On Self Test Mike Perkins <spam@spam.com> - 2020-09-23 23:13 +0100
    Re: Power On Self Test pozz <pozzugno@gmail.com> - 2020-09-24 09:18 +0200
      Re: Power On Self Test Mike Perkins <spam@spam.com> - 2020-09-30 15:14 +0100

csiph-web