Re: Continous eeprom checksum microcontroller
From: Paul E. Bennett (peb_at_amleth.demon.co.uk)
Date: 07/07/04
- Next message: R Adsett: "Re: Time Stuff"
- Previous message: Dingo: "Re: USB & Windows (XP)"
- In reply to: Ben Bradley: "Re: Continous eeprom checksum microcontroller"
- Next in thread: Hans-Bernhard Broeker: "Re: Continous eeprom checksum microcontroller"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 07 Jul 2004 20:18:29 +0100
Ben Bradley wrote:
> On Tue, 06 Jul 2004 23:09:36 GMT, postmaster@noname.com (Ken Lee)
> wrote:
[%X]
>>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.
As I stated previously, only the risk assessment process for the system in
its intended environments can guide the mitigating measures required in the
system. It can take as long or longer to perform the risk analysis
ccompared to the time required to do the system design.
> It really depends on how often it needs to be performed. If you
> have a routine called in a main loop or tick interrupt that
> accumulates a location, increments a pointer (and if at end, does the
> compare and resets the pointer) and returns, it will use very little
> resources and be done in seconds or minutes.
> From reading followup posts, the OP seems to want to do this for
> the more general purpose of system integrity. I'm not sure this is the
> best (and certainly not the only) way to validate system integrity. As
> any recent c.a.e reader knows, we've had a few heated threads recently
> regarding devices intended to increase system integrity. Some things
> are a lot better than others in increasing, validating or insuring
> system integrity.
The difference between genearal purpose controller systems and high
integrity controller systems should, nowadays, be less reflected in the
hardware manifestations. The difference is more likely to be manifested in
the software techniques used and the overall system integration
arrangements. Whatever errors you find in the system you still must have
some plan of action for the controller to follow even if it is just raise
an alarm and turn itself off. Naturally, when errors are encountered they
should be logged somewhere so that the engineers/operations staff can
identify what happened (in sequence hopefully).
> Quoting an earlier response in the thread:
>
>>Hi, one more(i am getting lazy,cant dig out on my own ;) )
>>One of the generic requirement by my customer asks for a register
>>refresh on continuous basis again. I am using a hc12 micro. My que is
>>the same .. is it worth it ?? never implemented such a thing
>>before...
>
> It seems to me your question is "I am using a hc12 micro. What can
> I do to make it as reliable as reasonably possible?"
Most likely what he is asking but also trying to follow a document he has
been given by his client (who may just have cherry picked some supposedly
useful phrases that have been applied to other systems without
understanding the implications of what they are asking - the OP needs to
explore this with his client from the basis of a good grounding in
defensive programming techniques and their overall value to system
integrity. I would require a significant amount of information from the OIP
to be able to assist him to that level from where he seems to be.
> As for the "register refresh" he may be referring to output
> registers and data direction registers. Electrical spikes can cause
> the bits in these registers to change states, so it makes sense to
> refresh them regularly. But why does your customer ask this? It seems
> that as the designer, you should be making these decisions. Is your
> customer micromanaging you? Or is your customer a governmental agency
> and these are "required specs"?
The general rule for registers that are relied upon for output is that
their state should be refreshed at the successful completion of each
control loop cycle based on the evidence from the real system state as
represented by the inputs (INPUT-->PROCESS-->OUTPUT). If the path to the
end of the control loop is not completed successfully then you may need to
set a default output pattern that has been determined to be safe (I try and
make mine all outputs off if I can - not always possible).
> But if a spike can change an I/O register, then it can change any
> other read/write bit on the silicon, such as a CPU register or RAM
> location. These can't be "refreshed" because you don't know what
> values they should be. The solution to this, in addition to to the
> above CRC's and refreshing, is to reduce the effect of a spike so it's
> much less likely to affect the controller: change layout, add bypass
> caps, add diodes and resistors on I/O's and such.
> So what happens if an I/O port is the wrong value? Could it do
Systems that are easily suceptable to the effects of spikes from PSU, ESD
or RFI need the hardware design looking at. Decent layout, adequate
decoupling, filtering, shielding and sensible arrangement of ground
circuits will all have beneficial effects on the system.
> something dangerous? Could it lose valuable data? What should the
> thing do? Reset? Save the fault state in an EEPROM, light a special
> "ERROR" LED and stop? (I rather like that, as the fault state is
> "valuable data" to the designer) All this is dictated by the
> application.
It just takes a little up-front thinking to eliminate many of the problems
that can arise for a system design. No-one needs to rush to dash out a
system design on receipt of the requirements.
-- ******************************************************************** Paul E. Bennett ....................<email://peb@a...> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
- Next message: R Adsett: "Re: Time Stuff"
- Previous message: Dingo: "Re: USB & Windows (XP)"
- In reply to: Ben Bradley: "Re: Continous eeprom checksum microcontroller"
- Next in thread: Hans-Bernhard Broeker: "Re: Continous eeprom checksum microcontroller"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
