>
> Personally, I have never seen such a problem with PICs, but then 
> again, many of my signals are bypassed
> with 100pF ceramic caps or even LC filters between points on the PCB. 
> I deliberately prevent PIC pins
> from picking up a signal so I can key a long-range radio with the 
> antenna a few inches away and nothing
> happens. One design I am testing now has a cellular modem mounted on 
> the same PCB as the PIC
> and its antenna is 2" away from the PCB.  I maintain two copies of 
> every critical register, and maintain 3 sets
> of EEPROM Data Configuration bits; the copies are matched to the 
> originals every 12mS; I force a reset if it
> won't cause a problem immediately, or I set a flag to force a reset at 
> the first opportunity.
>
>> By the way, a 10F200 makes a great little external watchdog.  I'm 
>> working on
>> a project right now using one for this purpose (It's really not that 
>> mission
>> critical, but the managers have a medical devices background and just 
>> can't
>> give up the concept of a separate failsafe chip they can physically look
>> at).  The 10F drives the MCLR line of the main controller, and does the
>> timing and sequencing of the 3 inputs to know what state the unit is 
>> in and
>> when to release the main processor.  One of the inputs is a heartbeat 
>> signal
>> from the main processor, and the 10F is programmed to wait a certain 
>> while
>> after reset for the main processor to get past initialization, then 
>> require
>> a minimum pulse period on the heartbeat line.
>>

These are all very good ideas, thank you.

Brings me up to another problem we had in a very few cases:  the program 
flash part was modified.
In this case there was no code to write the flash program memory,
but there was code to write to the flash data memory (which is almost 
identical)
and which was used quiet frequently.
Unfortunatly in these cases we had code-protected the flash program memory,
so we were not able to see what really changed,
but after reprogramming the PIC, the system worked well again.
We expect that external induced currents (either ESD or strong EM 
fields)  caused the problem,
but on the lab-table we couldn't induce this problem.
(because we still didn't trust the PIC we replaced it)

This brings up the followig questions:
1. Does anyone else have seen problems with modified program flash ?
2. Is it possible that the write to flash data eeprom could have written 
in the program area ?
3. If question 2 is true, is there a way to  put an extra  safety to 
prevent it ?

thanks you all for this very valuable and interesting discussion,
Stef Mientki


_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist