> -----Original Message-----
> From: Jeff Hunsinger [SMTP:jeff@SILICONENGINES-LTD.COM]
> Sent: Wednesday, October 13, 1999 4:10 PM
> Subject:      Re: PIC12CE518 EEPROM
>
>
        [Gary Schroeder] Jeff, Thank-you for your response
> A couple things that may be part of your EEPROM corruption problem:
>
> - Do you provide protection against load dumps (24-50V+) and other
>   transients?
>
        [Gary Schroeder]  I use a very simple voltage regulator that
includes a transient
        voltage suppressor

> - Does your circuit run properly over the normal operating range of
>   the battery (generally 9-16V).
>
        [Gary Schroeder] Yes.

>  Do you have any built-in detection
>   of under/over battery voltage? Does the code enter a safe mode
>   when this condition arises?
>
        [Gary Schroeder]  I am using brown out protection circuitry.
When the alarm
        1st turns on, it reads a value from its EEPROM and uses this
value to control the
        pitch of the alarm. I use no code that reacts to under/over
battery voltage. When the EEPROM
        is erased the alarm has an extremely low pitch. I can not
reproduce this failure with my power
        supply in the lab. It only happens on certain electric vehicles.
If I take a failed alarm to the lab
        and power it up, it continues to fail. I am assuming the code is
behaving O.K., it's just that some
        type of noise erased the EEPROM value.

        Also, I have added code so that if the EEPROM read fails, a
nominal pitch controlling value is used
        in place of the EEPROM value so that the alarm will sound at a
decent pitch.


> - Are the lines going to your serial EEPROM short and guard banded?
>
>
        [Gary Schroeder]   the PIC12CE518 has an on board EEPROM.
        What is guard banded?


> - Do you keep checksums for both the EEPROM data and the data that
>   is to be written?
>
        [Gary Schroeder]  I did not know that you could have checksums
for EEPROM data.
        How do you obtain these checksums and how do you use them?

> I've had problems with EEPROM corruption before. It can generally
> be traced back to either noise on the serial lines or the MCU
> getting "lost", especially during normal EEPROM access.
>
        [Gary Schroeder] Again, I think the code is acting O.K., it's
that some kind of noise erased the
        EEPROM. I suspect the solution will be better protection for the
PIC against spikes. I guess the problem is getting to the EEPROM through
the Vdd pin. Or could other pins be allowing some signal to get to the
EEPROM?
> Jeff