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

Groups > comp.arch.embedded > #29977

Re: Power On Self Test

Show all headers | View raw

On 9/23/2020 7:03 AM, David Brown wrote:
> On 23/09/2020 14:51, Richard Damon wrote:
>> Testing RAM can be useful, letting the system fail gracefully rather
>> than acting flaky, perhaps just locking up into a tight loop flashing a
>> LED as a fault indicator.

Exactly.  If memory is expected to work -- and NEVER expected to fail -- then
it's a small cost to actually make some attempt to prove that is actually the
case.  Otherwise, when that "Can't Happen" actually does, you're left clueless.

[In the 70's, a common system failure I encountered was an address decoding
error which would effectively disable all memory (think misprogrammed PLA).
It was readily apparent as the processor would be found halted at ~0x0076
(IIRC) -- 0x76 being the opcode for HALT which would be the low byte of the
address still "floating" on the multiplexed address/data bus.  Nowadays, one
can imagine similar failures -- including grown defects -- deleteriously
affecting deployed product.]

> Have you ever seen microcontroller RAM that failed?  It's a possibility
> for dynamic ram on PC's that is pushed to its limits for power and
> speed, and made as cheaply as possible.  But for static RAM in a
> microcontroller, the risk of failures is pretty much negligible.  The
> exception is if a bit is hit by a cosmic ray (or other serious
> radiation), which can flip a bit, but that won't be detected by any RAM
> test of this kind.

You're assuming that there is only one, predetermined way to get into the
self-test routine.  And, that nothing in the machine has failed that would
render that assumption false.

At each point in your code, you should know what assumptions are safe and
which are yet to be proven/made safe.  If you're in the self-test routine,
you shouldn't have to wonder if memory works, is configured as you expect
it to be, etc.  ("Hey, I'm running code so why bother to TEST the code
image??")  Assuming that the memory is operational NOW (while I am executing
this piece of self-test code) is a hazard waiting to happen.

For example, an errant RETURN could land the program IN the self-test code
WITHOUT the benefit of having been through the controlled, repeatable start-up
sequence.  (i.e., the RAM -- or other resource -- may NOW be mapped to a
different location in the address space such that the code written under
the assumption that it resides in its "power on reset" configuration no
longer works properly.)

I'd rather have that code FAIL and report the error to me -- because it
tried to verify some assumption(s) and failed -- than have the code continue
to operate FROM THERE on the assumption that it is actually (later) talking
to functional RAM that has yet-to-be reconfigured.  Otherwise, you get a
"fluke" that you can never resolve (and, because you can't easily sort out
what might have happened in order to reproduce and repair, you shrug it
off due to time pressures -- even though YOU SAW IT FAIL!).

[I have an entry point in all of my products called RESET.  It manually and
deliberately works to restore the hardware to the same condition that it
was in just after the application of power.  So, any code that executes
after passing through that entry point -- to "RESETTED" -- SHOULD behave the
same regardless of whether power was just applied, or not]

Note that there's a difference between the sort of "confidence testing"
that occurs at POST (how many devices perform exhaustive tests at POST?
How many users would tolerate that sort of delay?) and "diagnostic testing"
which truly provides an assessment of the health of the device and can often
be used to assist in determine the need for replacement (or, for self-healing).

In most cases, you can test RAM with a single write pass followed by a
verification read pass and be reasonably sure that you've caught stuck-at
failures as well as decode failures -- no need for a whole barrage of
different tests when you're typically looking for a simple Go-NoGo.

[I run three passes on a 512MB block and use that as a crude assessment
as to whether or not the memory will LIKELY accept a program image.
Installing -- and verifying -- that image acts as a further test of
the memory's crude functionality.  Thereafter, I swap pages of memory
out and exercise them to verify that I'm not seeing an increase in
ECC activity in a particular region -- which I will remap if need be.]

You also need to know how the device is fabricated; a memory module
will experience different errors than memory that is soldered down.
(and, in the latter case, you have to be prepared for the memory to
NOT be what you THOUGHT it was going to be, at design time).  And,
soldered down memory will behave different than chip-on-chip.

Folks write ONE memory test and then assume all memory behaves (fails!)
the same.

If you don't understand your hardware and how it can fail, you shouldn't
be the one who is designing the test suite!

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