Re: Power On Self Test

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.arch.embedded
Subject	Re: Power On Self Test
Date	2020-09-23 14:13 +0200
Organization	A noiseless patient Spider
Message-ID	<rkfe4s$cr2$1@dont-email.me> (permalink)
References	<rkf74n$u9$1@dont-email.me> <rkf9nl$gab$1@dont-email.me>

Show all headers | View raw

On 23/09/2020 12:57, Don Y wrote:
> On 9/23/2020 3:13 AM, pozz wrote:
>> I'd like to implement a Power On Self Test to be sure all (or many)
>> parts of the electronics are functioning well.
>>
>> The tests to be done to check external hardware depends on the actual
>> hardware that is present.
>>
>> What about the MCU that features an internal Flash (where is the code)
>> and RAM and some peripherals? Are there any strategies to test if the
>> internal RAM or Flash are good? Do you think these kind of tests could
>> be useful?
>>
>> What about a test of the clock based on an external crystal?
> 
<snip>
> Think hard about the types of failures you EXPECT to see (i.e., many are
> USER errors!) and don't invest too much time detecting things that will
> likely never fail OR whose failure you won't be able to do much about.

This last bit is crucial.

A lot of testing "requirements" that are specified are completely
pointless - or far worse than useless, as they introduce real points of
failure in their attempts to cover everything.

First, figure out what you should /not/ test.

Don't bother testing something unless you can usefully handle the
failure.  If the way you communicate errors is through a UART, there is
no point in trying to check that the UART is working.  If you have a
single microcontroller in the system, there is no point in trying to
check the cpu or the on-chip ram.  There is no point in checking that
you can write to flash or on-chip eeprom - all you do is reduce its
lifetime and make it more likely to fail.

Don't write any test code which cannot itself be tested.  If you cannot
induce a failure, or at least simulate it reasonably, do not write code
to check or handle that failure.  The reality is that the untested code
will have a higher risk of problems than the thing you are testing.

Don't check the ram or the flash of the microcontroller - there's
nothing you can do if there is a failure.  (You can check that you have
successfully loaded a new software update, or that there hasn't been a
reset during an update - a CRC for that kind of thing is a good idea.)
If you have a system that is important enough that ram or flash failures
need to be checked and handled, use a safety-qualified microcontroller
with ECC ram, flash, cache, etc., and perhaps even redundant cores (you
get these with PowerPC and Cortex-R cores).

And think about what can reasonably go wrong, how it can go wrong, and
what can be done about it.  Other than for devices susceptible to
current surges (like filament light bulbs), most hardware failures are
in usage, not while power is off - checking on power-up (rather than
while the system is in use) usually only makes sense if it is likely for
a user to see there is a problem and try to "fix" it by turning power
off and on again.

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