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
maxruben@mail.bip.net
-----------------------------------