Searching \ for 'ROM checksum' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/method/errors.htm?key=checksum
Search entire site for: 'ROM checksum'.

Truncated match.
PICList Thread
'ROM checksum'
1998\01\09@002950 by The Jacky's

flavicon
face
Hi World
Thanks to all for your input on a PIC 73 RAM check .... you've proven
so valuable I just gotta dip in this "well of wisdom" one more time.
My application needs to be very reliable so the PIC (on startup) needs to
make
sure ROM has not lost it's mind.  One way is to just add, or OR, or AND
each ROM location to the next location, from the first to the last.
If you ignore overflow,  the result is some number, a checksum of ROM.
If the number is the same as the one you added up when the ROM was virgin
everything is OK.  So here's the problem.   This seems to simple.  There
could be a hidden
problem,  a better WAY.  The most reliable WAY.   Any thoughts on
this.....?

1998\01\09@015606 by Andrew Warren

face
flavicon
face
The Jacky's <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> My application needs to be very reliable so the PIC (on startup)
> needs to make sure ROM has not lost it's mind.  One way is to just
> add, or OR, or AND each ROM location to the next location, from
> the first to the last. .... This seems to simple.  There could be a
> hidden problem, a better WAY.  The most reliable WAY.   Any
> thoughts on this.....?

Jacky's:

There IS a problem... It's not possible for a PIC16C73 to checksum
its own ROM; the architecture of the device prevents it.

Sorry.

-Andy

=== Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\01\09@053343 by maten149

flavicon
face
Hi!

The Jacky's wrote:

> Hi World
> everything is OK.  So here's the problem.   This seems to simple.  There
> could be a hidden
> problem,  a better WAY.  The most reliable WAY.   Any thoughts on
> this.....?

The PIC-range processors have harvard architecture, meaning that data
memory is separated from program memory. You cannot read the program rom ->
you cannot checksum.
Perhaps you can run you program in diagnostics-mode where all operations are
performed except for the 'final' steps and the results are written to a
ram-location, and
then verified. The gain in reduced error-probability depends on how much code
you can execute without actually performing I/O-tasks et.cetera.

Any other Ideas
Regards, Mattias

--
-------------------------------------------
               BassLab
   Production, Mix, Remix facility
      Mail us : basslabspamKILLspamusa.net
      Call us : +46-(0)708-833331
-------------------------------------------

1998\01\09@191037 by Scott Newell

flavicon
face
> The PIC-range processors have harvard architecture, meaning that data
> memory is separated from program memory. You cannot read the program rom ->
>you cannot checksum.

The Analog Devices fixed point DSP chips are also Harvard architecture (or
is it 'modified' Harvard artchitecture?), but they were clever enough to
include a bus exchange for transferring between program and data space.
They use a dedicated register to hold the extra byte (program memory is 24
bits, data memory is 16 bits).

I've always wondered why Microchip didn't do something similiar.


newell

1998\01\09@193658 by Andrew Warren

face
flavicon
face
Scott Newell <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU> wrote:

> The Analog Devices fixed point DSP chips are also Harvard
> architecture (or is it 'modified' Harvard artchitecture?), but they
> were clever enough to include a bus exchange for transferring
> between program and data space. They use a dedicated register to
> hold the extra byte (program memory is 24 bits, data memory is 16
> bits).
>
> I've always wondered why Microchip didn't do something similiar.

   Scott:

   Microchip DID do something similar... Take a look at the 17Cxx
   devices.

   -Andy

=== Andrew Warren - EraseMEfastfwdspam_OUTspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1998\01\10@113509 by wwl

picon face
On Fri, 9 Jan 1998 17:53:10 -0600, you wrote:

>> The PIC-range processors have harvard architecture, meaning that data
>> memory is separated from program memory. You cannot read the program rom ->
>>you cannot checksum.
>
>The Analog Devices fixed point DSP chips are also Harvard architecture (or
>is it 'modified' Harvard artchitecture?), but they were clever enough to
>include a bus exchange for transferring between program and data space.
>They use a dedicated register to hold the extra byte (program memory is 24
>bits, data memory is 16 bits).
>
>I've always wondered why Microchip didn't do something similiar.
'cos it isn't necessary - *if programmed correctly*, ROM corruption
just doesn't happen, so the extra cost of a verification mechanism
isn't justified. Unfortunately, some standards have been written which
require it, and MCT added a facility to the 16C715 for this reason.

    ____                                                           ____
  _/ L_/  Mike Harrison / White Wing Logic / wwlspamspam_OUTnetcomuk.co.uk  _/ L_/
_/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/

1998\01\10@183356 by Scott Newell

flavicon
face
>>I've always wondered why Microchip didn't do something similiar.

>'cos it isn't necessary - *if programmed correctly*, ROM corruption
>just doesn't happen, so the extra cost of a verification mechanism
>isn't justified. Unfortunately, some standards have been written which
>require it, and MCT added a facility to the 16C715 for this reason.


Well, I wouldn't (and haven't) use it for ROM checksumming, but I think
it's nice to be able to put big tables in ROM space (especially with the
ADSP-2181, where it makes FIR filters much nicer).  Something like a
sine-table lookup could use the extra precision.

Now if I were building something that was going into low earth orbit, I
might want a rom checksum...


newell

1998\01\10@192823 by John Payson

picon face
> >'cos it isn't necessary - *if programmed correctly*, ROM corruption
> >just doesn't happen, so the extra cost of a verification mechanism
> >isn't justified. Unfortunately, some standards have been written which
> >require it, and MCT added a facility to the 16C715 for this reason.
>
> Well, I wouldn't (and haven't) use it for ROM checksumming, but I think
> it's nice to be able to put big tables in ROM space (especially with the
> ADSP-2181, where it makes FIR filters much nicer).  Something like a
> sine-table lookup could use the extra precision.

The only time a ROM checksum routine is really useful is if the checksum
routine itself is stored in a more reliable medium than the code being
checked.  For example, some devices have a checksum routine in masked ROM
while the main code is in OTP or EEPROM; even more common are flash-based
systems were the checksum routine is in a hardware-write-protected block
of flash.

Otherwise, the ability to store information more densely in code space would
be a plus, definitely; it would have to be balanced, though, against the
possibly-increased-ease of reading out code-protected devices.  Of course,
this probably isn't the reason for Microchip's decision not to include that
facility, but it should be a consideration.  The crack for the DS5000 series
chips relies upon this sort of weakness, and similar cracks could probably
be weaseled for other chips as well.

1998\01\11@055942 by wwl

picon face
On Sat, 10 Jan 1998 17:32:30 -0600, you wrote:

>>>I've always wondered why Microchip didn't do something similiar.
>
>>'cos it isn't necessary - *if programmed correctly*, ROM corruption
>>just doesn't happen, so the extra cost of a verification mechanism
>>isn't justified. Unfortunately, some standards have been written which
>>require it, and MCT added a facility to the 16C715 for this reason.
>
>
>Well, I wouldn't (and haven't) use it for ROM checksumming, but I think
>it's nice to be able to put big tables in ROM space (especially with the
>ADSP-2181, where it makes FIR filters much nicer).  Something like a
>sine-table lookup could use the extra precision.
Yes, fine, but you don't often need big tables  in small cheap
microcontrollers, and you can do tables on the PIC anyway
>Now if I were building something that was going into low earth orbit, I
>might want a rom checksum...
But you could afford a more expensive chip


    ____                                                           ____
  _/ L_/  Mike Harrison / White Wing Logic / @spam@wwlKILLspamspamnetcomuk.co.uk  _/ L_/
_/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/

1998\01\11@162407 by Walter Banks

picon face
John Payson wrote:

> The only time a ROM checksum routine is really useful is if
> the checksum routine itself is stored in a more reliable
> medium than the code being checked.

I agree with part of the comment however the real role of a
checksum routine is to prevent in-operative code from
executing.  Careful design of the checksum routine can
result in the failure modes of the checksum preventing the
application from running. In critical systems the checksum
routine which is quite small becomes the focus of very careful
anaylsis.

Walter Banks

1998\01\11@193738 by John Payson

picon face
> John Payson wrote:
>
> > The only time a ROM checksum routine is really useful is if
> > the checksum routine itself is stored in a more reliable
> > medium than the code being checked.
>
> I agree with part of the comment however the real role of a
> checksum routine is to prevent in-operative code from
> executing.  Careful design of the checksum routine can
> result in the failure modes of the checksum preventing the
> application from running. In critical systems the checksum
> routine which is quite small becomes the focus of very careful
> anaylsis.

If a checksum routine is designed very carefully, it may be possible to
ensure that some failure modes of the checksum program memory will result
in an inoperable system (rather than one which operates wrongly).  In
practice, though, I would tend to question the usefulness of such tech-
niques on single-chip micros with a unified code store (as opposed to chips
which have some ROM/OTPROM and some "live-programmable" EEPROM).  In cases
where it's plausible that some of the code might be damaged without render-
ing the whole CPU entirely unreliable (e.g. in larger systems where the code
is spread out over several chips, or in cases where some of the code in in
user-insertable modules as with game machines) a checksum may be an excell-
ent way of ensuring that all is as it should be.  In fact, an excellent way
of designing a field-upgradable system would be to use a 17Cxx with an ext-
ernal flash; the internal OTPROM could checksum the external memory and run
it only if it looked okay.  For a PIC running internal code, however, I'm
not aware of any plausible* failure modes that would allow a checksum rou-
tine to detect the problem and act accordingly.

(*) By this I mean failure modes which are at least 10% as likely as more
   common failure modes.  If a system has a 1% chance of having its CPU
   start operating sporatically in a year, and a 0.1% chance in that same
   year of having its memory lose a few bits and the CPU detect the sit-
   uation, the CRC routine hasn't really bought much.

1998\01\12@122529 by Wayne Foletta

flavicon
face
Am I missing something? I thought the main purpose for ROM (or other
data) checksums was to verify the contents was correctly programmed with
a given code version. Faster than other checks (i.e. CRC) but just a
check.

- Wayne Foletta
BMI - Saratoga, CA

{Quote hidden}

1998\01\12@124552 by Walter Banks

picon face
----------
> From: Wayne Foletta <spamBeGonewaynespamBeGonespamELECTROTEK.COM>
> To: TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU
> Subject: Re: ROM checksum
> Date: Monday, January 12, 1998 12:23 PM
>
> Am I missing something? I thought the main purpose for ROM (or other
> data) checksums was to verify the contents was correctly programmed with
> a given code version. Faster than other checks (i.e. CRC) but just a
> check.

That is true however with embedded systems the question  is
if the ROM can be proven defective then what?  The answer depends
on the application. In John's original post he was making a point that
the ROM test routine for something like the 17Cxxx parts could be
placed in a more reliable ROM than the application is stored in.

My point was with (great) care in analyzing the failure modes
of the test routine it might be possible to accomplish the same goals
with regular ROM.

Fails safe code has to be carefully written. About a year ago a failsafe
system shut the engine down on a ocean going cargo ship because a
bearing was getting hot the result was an out of control ship that took out
a
dock, hotel and part of a shopping mall in New Orleans.

The same kind of thought needs to go into fail-safe modes for car engine
controllers and embedded systems used in medicine.


Walter Banks

1998\01\13@012628 by John Payson

picon face
> That is true however with embedded systems the question  is
> if the ROM can be proven defective then what?  The answer depends
> on the application. In John's original post he was making a point that
> the ROM test routine for something like the 17Cxxx parts could be
> placed in a more reliable ROM than the application is stored in.

In some situations, the device may be designed so that if the checksum
on the flash fails, it will still provide some minimal degree of func-
tionality including the ability to signal the failure and/or request and
receive new code (e.g. if the device has a modem it could call up a
central system where the code was kept).

Especially in the context of flash-based systems built with surface-mount
parts, including a CRC/bootloader in ROM may make the difference between
having to unsolder/resolder parts (MAJOR bummer) and simply having to hook
up a programming jumper or run special computer software (much easier).
In general, though, unless something useful can be done in case of a CRC
failure there isn't much point in even having the check.

1998\01\14@032037 by ruben

flavicon
face
John Payson wrote:

> > That is true however with embedded systems the question  is
> > if the ROM can be proven defective then what?  The answer depends
> > on the application. In John's original post he was making a point that
> > the ROM test routine for something like the 17Cxxx parts could be
> > placed in a more reliable ROM than the application is stored in.
>
> In some situations, the device may be designed so that if the checksum
> on the flash fails, it will still provide some minimal degree of func-
> tionality including the ability to signal the failure and/or request and
> receive new code (e.g. if the device has a modem it could call up a
> central system where the code was kept).
>

-Snip-

> In general, though, unless something useful can be done in case of a CRC
> failure there isn't much point in even having the check.
>

I disagree.

I make products for human safety in industrial environment, devices
that controls that no person is within the reach of a potentialy
dangerous machine, such as an industrial robot or a press, when it is
working. These devices has to make sure that the dangerous machine
stops if a person enters its working zone in order to prevent
injuries or even death. A safety device of this category has to be
able to stop the dangerous machine even if there is failure in any
of its components. This is most often done with a two channel
design, where the both channels do the same evaluation of the inputs
and then checks that they both have come up with the same result
and then activates the outputs that keeps the dangerous machine
going if the inputs say so. (Dynamicaly refreshed outputs that has to
be triggered every programcycle to be activated.)

If this device is done with microprocessors and there is any chance
that the program code in one processor can become corrupt and fail in
such a way that it isn't detected by the other processor and that it
disables some of it's safety functions, say allways detecting an
input as active, it could, in worst case, cause the death of a person
entering the dangerous zone at the wrong time.

Since it can be very hard and timeconsuming to check the effect of a
fault in every single bit of the programcode a checksum routine is
very useful. In this case a checksum of the ROM (or the EPROM for
PIC's) could detect the corrupt code and prevent the safety outputs
>from activating. Of course, the checksum code itself would have to be
carefuly designed so that the probability of detecting an error in
this code would be high. One way to do this could be to have two
checksum routines in different codespace which where alternated every
other programcycle. A fault in one would be detected in the other.

In a way this is something useful though, so I guess
I agree anyway :-)


-----------------------------------
Ruben Jšnsson
AB Liros Elektronik, Sweden
RemoveMEmaxrubenspamTakeThisOuTmail.bip.net
-----------------------------------

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...