Continous eeprom checksum microcontroller

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi, Anybody come across continous background checksum tests on
eeprom?? Is it worth doing ??

Re: Continous eeprom checksum microcontroller

Quoted text here. Click to load it

Yes, I do it all the time.  Whether it's worth doing depends on whether you
need to know if the memory has failed.  Probably not for a musical greeting
card, probably yes for a radiotherapy dosing controller.

Cheers,
Alf



Re: Continous eeprom checksum microcontroller
On 2 Jul 2004 21:34:16 -0700, the renowned vishalpatil snipped-for-privacy@yahoo.co.in

Quoted text here. Click to load it

a)     I've implemented it.
b)    I think so.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Continous eeprom checksum microcontroller
Quoted text here. Click to load it

The question is what to do when an error is detected...

*** Keyboard not present *** Press [F1] to continue.

The only I thing I once did, was a small database with
maximum and minimum allowed values and preferred defaults
for each parameter, which were used to validate the user
input during setup, and for sanity checks during startup.
The values would be put back to their defaults, if out of
limits. Silently. When more than 3 errors, the entire
set of parameters would be set to default, which was useful
for production.

I have had some problems with first generations of EEproms,
but not the last 5 years or so, not that I noticed anyway ;)

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)




Re: Continous eeprom checksum microcontroller
On Sat, 3 Jul 2004 16:54:25 +0200, the renowned "Frank Bemelman"

Quoted text here. Click to load it


<LOL>

Quoted text here. Click to load it

Loss of calibration data can be the equivalent of a hard failure-
there's no obvious default values to set it to.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Continous eeprom checksum microcontroller
Quoted text here. Click to load it

Yes, for calibration data some redundancy is nice, and auto-repair
facility. Or a calibration certificate, on luxury paper and interesting
stamps all over it..  or display a nag-screen "calibration required" ;)


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: Continous eeprom checksum microcontroller
On 2 Jul 2004 21:34:16 -0700, vishalpatil snipped-for-privacy@yahoo.co.in (Vishal)

Quoted text here. Click to load it

Can be worthwhile in a high-reliability system. Compared to the usual
power-on checksum, it has the advantage of testing in the actual
execution environment: elevated device temperatures, supply voltage
levels and noise affected by active peripherals, etc. In a dialysis
machine years ago, I tested ROM and RAM in a background task. The RAM
was tested a byte at a time, disabling interrupts briefly while the
RAM contents were modified.

Assuming the device is on an external bus, you're really testing all
of the signals on the bus - decodes, control lines, address and data -
so failures can be from problems other than in the memory itself.
--
Jim McGinnis

Re: Continous eeprom checksum microcontroller

Quoted text here. Click to load it

If the integrity requirements for your system indicate that such checking
is useful then it is definitely worth doing. As some others have indicated,
it can catch problems with bus addressing and/or data shared pathways. The
most difficult thing about deciding to use continuous eeprom checksum is
what you need to do if you discover a problem.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Continous eeprom checksum microcontroller
On Sat, 03 Jul 2004 20:45:34 +0100, "Paul E. Bennett"

Quoted text here. Click to load it

I was thinking the same thing. I presume some analysis was performed &
the eeprom checksum is a mitigation of some fault or hazard. Otherwise
what do you do when a fault is detected? Initialise to default values?
Log an error & continue? Halt the device? Reset the device?

Also is a "checksum" adequate or should a CRC be calculated?

Performing continuous eeprom checks could chew up considerable MIPs,
so I wouldn't do it unless I had cause for good reason. Some good
design practices employ minimal resource usage -- I wouldn't put this
one into that category.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Continous eeprom checksum microcontroller
On Tue, 06 Jul 2004 23:09:36 GMT, the renowned snipped-for-privacy@noname.com

Quoted text here. Click to load it

Attempt to salvage correct value, attempt to repair at an appropriate
time in my case.  

Quoted text here. Click to load it

It could not, too.

Quoted text here. Click to load it

Yes.


Depends on the other specifications. The minimum resource usage to
meet ALL the specifications, right?

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Continous eeprom checksum microcontroller
On Tue, 06 Jul 2004 23:34:14 GMT, Spehro Pefhany

Quoted text here. Click to load it

What does "salvage" really mean. If a checksum is performed on a block
of memory & it's wrong then one could take this to mean that 1 or any
number of the contents are incorrect. If a checksum is performed on a
single item and it's wrong, then all you can deduce from this is that
the value is incorrect. Unless you keep a mirror image of the data you
cannot "salvage" the correct value. Possibly the only things one could
do is fall back to some "safe" or default value, reset the device or
place the device in an error state.

Quoted text here. Click to load it
Sorry but this requirement just has that particular pattern as a
MIPs-chewer --  "repetitive calculation on a block of memory". Why
can't this requirement be met on demand -- that is, the checksum is
calculated when the data is read and used?

Quoted text here. Click to load it

I've no argument on resource budgeting for input requirements, but
this particular requirement looks like a mitigation for some fault or
hazard. I've no problem with checksumming or CRCing stored data, but
doing it on a continual basis seems to me to be ill-formulated.
Admittedly I don't know what the application is, but I'm in the
medical electronics game and have worked in the automotive industry,
and am familiar with over-burdened mitigations.

Ken.
Quoted text here. Click to load it


+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Continous eeprom checksum microcontroller
On Wed, 07 Jul 2004 23:10:59 GMT, snipped-for-privacy@noname.com (Ken Lee)

Quoted text here. Click to load it

If you are using some sort of multitasking kernel, which usually
contains a null task (running an idle loop), which executes when no
other task is runnable, simply put the memory check into this null
task.

Paul
 

Re: Continous eeprom checksum microcontroller

Quoted text here. Click to load it

I'm sure that there are a multitude of ways to implement this but that
wasn't my point. I was making an observation  as to why this
requirement had to be done continuously, opposed when it's needed &
that's when the value is actually read.

Ken

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Continous eeprom checksum microcontroller
On Sun, 11 Jul 2004 22:55:13 GMT, snipped-for-privacy@noname.com (Ken Lee)


Quoted text here. Click to load it

Suppose the device is the navigation system for an airplane, and you
haven't taken off yet. Wouldn't you like to know whether you could
rely on it once you're in the air?

--
Jim McGinnis

Re: Continous eeprom checksum microcontroller
In fact, that is one of the tasks that does run as part of
the normal frame in our embedded avionics software for
some of the boxes we build for airplanes !!  Yes, we do
want to know if things are corrupted.

--
Mike "mikey" Fields
http://home.comcast.net/~mike.fields /
We've slightly trimmed the long signature. Click to see the full one.
Re: Continous eeprom checksum microcontroller
On Sun, 11 Jul 2004 22:12:58 -0400, Jim McGinnis

Quoted text here. Click to load it

So you're implying that they don't do a system check of the navigation
system on the ground before take-off. I'm assuming that the navigation
system is turned on prior to the plane getting into the air.

Let me be perfectly clear -- I'm NOT saying that the check shouldn't
be done. I'm objecting to the fact that it is done "continuously"
rather than on-demand.

Ken.

+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com

Re: Continous eeprom checksum microcontroller
Quoted text here. Click to load it

Oh, not again. Why not a controller for a nuclear power plant, an
on-board engine controller for a satellite in orbit, a laser for
eye corrections, a heart-lung machine in an OR, a launcher for
H-boms...

The bottom line is that folks that implement it, probably need it.
Either because their hardware is crap or they are paranoid or it
is a requirement from some retard, leaving 0.01% of applications
where it really serves a purpose.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)



Re: Continous eeprom checksum microcontroller

Quoted text here. Click to load it

I don't think so.

Quoted text here. Click to load it

But why would they imagine thet the EEPROM hardware is crap while
having faith the the "do the checksum" hardware and the "store the
checksum to compare with the EEPROM" hardware will work just fine?

Quoted text here. Click to load it

By why would they be paranoid about the EEPROM hardware and not the
EEPROM checking hardware?

Quoted text here. Click to load it

Possibly , but if you develop embedded sytems, it's your *job* to
identify flaws in the requirements.  If it isn't needed and the
customer insists on having it you have to make the personal choice
of whether to do it or find work elsewhere.


Re: Continous eeprom checksum microcontroller

"Guy Macon" <http://www.guymacon.com schreef in bericht
Quoted text here. Click to load it

They need it, but only from their point of view.

Quoted text here. Click to load it

I have no idea.

Quoted text here. Click to load it

Paranoid behaviour implies lack of understanding.

Quoted text here. Click to load it

Oh, if someone insist on it, even after pointing out it isn't
very useful, why not. But most requirement flaws I ignore without
informing the person that wrote them (or simply copied them
from another project).


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)




Re: Continuous eeprom checksum microcontroller


Quoted text here. Click to load it

You would have a problem if I was your project manager.  You would
be instructed to evaluate the requirements and to agree or disagree
with each requirement, and the definition of your code being "done"
would include the independent testers verifying that your code complies
with all requirements. On my projects requirement errors are serious,
and they are to be corrected, not ignored.

Then again, I wouldn't be handing you requirements that are male bovine
excrement. Before you got a requirement to implement a continuous checksum,
you would have hard numbers for EEPROM errors, sense-amp errors, ALU errors,
register errors. etc.. both under normal conditions and under conditions
of radiation, ESD, etc, and an analysis of the reliability impact, cost,
etc. of the sum-checker.


--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline