Strange EEPROM related issue

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,20%

We have a fully functional system but saw twice so far (in 100+ samples) th=
at the values in the EEPROM sometimes seem to be messed up. We suspect that=
 this is happening after powering on & powering off the system a few times =
repeatedly but have been unable to reproduce the issue so far. Does anyone =
have a clue what this might be? Would it be safer to store the data in Flas=
h instead of in EEPROM? Any hints or pointers would be appreciated!20%
Our controller is a Microchip PIC18F86K22 and BOR and PUT are enabled.20%

Thank you!!!

Re: Strange EEPROM related issue

Quoted text here. Click to load it
the values in the EEPROM sometimes seem to be messed up. We suspect that this is
happening after powering on & powering off the system a few times repeatedly but
have been unable to reproduce the issue so far. Does anyone have a clue what
this might be? Would it be safer to store the data in Flash instead of in
EEPROM? Any hints or pointers would be appreciated!
Quoted text here. Click to load it

I have some distrust of on-chip BOR circuits.. but anyhow, have you
set the BOR trip point to a voltage where operation at your clock
frequency is _guaranteed_ with worst-case trip? Is it in a relatively
high power mode?  


Re: Strange EEPROM related issue

Quoted text here. Click to load it

How are you using the EEPROM? Is there a single structure or data set
that you are writing or are you using multiple locations?

Without knowing any of the details, try using alternating storage blocks
in the EEPROM and including a CRC with each block. If the system dies in
the middle of an update then fall back to the other block.

Also, I seem to recall that some micros (the early AVRs maybe?) could
initiate an inadvertent write to an internal EEPPROM under an unlikely
but possible set of circumstances, with a recommendation that the EEPROM
address register always be left pointing to an unused location. Or
perhaps it was that the spurious write would be to EEPROM location
0x0000 so just avoid that address?

If you haven't read the errata sheets for your processor, that may be a
place to start.

--
Rich Webb     Norfolk, VA

Re: Strange EEPROM related issue
Quoted text here. Click to load it
What kind of EEPROM?
If I2C, a classic problem is violation of "bus free time" and/or "write
cycle time", which are typically timed in software.

Quoted text here. Click to load it
Not really, flash just opens up a different set of problems.

Leo Havm°ller.


Re: Strange EEPROM related issue
Quoted text here. Click to load it
at this is happening after powering on & powering off the system a few time=
s repeatedly but have been unable to reproduce the issue so far. Does anyon=
e have a clue what this might be? Would it be safer to store the data in Fl=
ash instead of in EEPROM? Any hints or pointers would be appreciated!
Quoted text here. Click to load it

You need to make sure that you are not changing the EEPROM address
while a write is in progress. What would happen if you were writing
the EEPROM when the system powered down?

Re: Strange EEPROM related issue
[This followup was posted to comp.arch.embedded and a copy was sent to
the cited author.]

In article <31567350.955.1331241801971.JavaMail.geo-discussion-
forums@pbbvx14>, snipped-for-privacy@gmail.com says...
Quoted text here. Click to load it
the values in the EEPROM sometimes seem to be messed up. We suspect that this is
happening after powering on & powering off the system a few times repeatedly but
have been unable to reproduce the issue so far. Does anyone have a clue what
this might be? Would it be safer to store the data in Flash instead of in
EEPROM? Any hints or pointers would be appreciated!
Quoted text here. Click to load it

It can be a good idea to organize all the data items you want to store
in EEPROM into a structure and when you write to the EEPROM always write
two copies of the whole structure in succession. Each structure should
include a CRC-16 computed across the structure contents. When the system
wakes up read in the EEPROM data structure to local RAM for run-time
usage. Check the CRC-16 if the first image and if good then use the
first read copy. If the CRC-16 fails then proceed to use the 2nd copy of
the stored data structure. If the CRC fails in the second access then
set all your parameters to default values and wait for the user to
readjust the parameter settings and result in re-write if the two data
structures.

Any EEPROM usage scenaro requires the MCU to have a precise voltage
monitor that asserts the hardware reset line whenever the VDD level
droops down any where near or below the speced minimum operating voltage
of the MCU and its associated components.

--

Michael Karas
Carousel Design Solutions
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline