View previous topic :: View next topic |
Author |
Message |
Fabri
Joined: 22 Aug 2005 Posts: 275
|
EEprom and data lost |
Posted: Fri Nov 11, 2011 10:18 am |
|
|
Hi,
I need a suggestion regarding the use of the internal EEPROM of a PIC18F4525. I use it to save the calibration data for probes J and for system data. The cases are really remote, but I would like to increase reliability ad understand when happen.
I already use write routines in the EEPROM with access via an enable bit. At the end of the writing I do a reading on a fixed location so that the last operation is the reading of a location not important. The system performs an update every 10 seconds a few bytes of EEPROM state. After each A/D conversion I read the calibration data in memory to display the temperature. I wonder if a reset occurs during a write system what makes the PIC? can be a dangerous situation for my data?
Note that I have performed various reset conditions by injecting noise burst without getting a data corruption.
Have you anything to suggest?
Regards,
Fabrizio |
|
![](templates/subSilver/images/spacer.gif) |
Geps
Joined: 05 Jul 2010 Posts: 129
|
|
Posted: Fri Nov 11, 2011 10:35 am |
|
|
In my current application I write the data twice and then use a 16 bit CRC. I can then recover the data if a single piece of data is corrupted.
They're spread across the EEPROM for further protection. |
|
![](templates/subSilver/images/spacer.gif) |
Fabri
Joined: 22 Aug 2005 Posts: 275
|
|
Posted: Fri Nov 11, 2011 10:48 am |
|
|
Really interesting but every time you change one datum you need to calculate CRC of all data.
I cannot think to write all data two times but just calibration data is possible.
I have a database by default in ROM. In case of error in the calculated CRC I can restore the default data.
Any other suggestion ? |
|
![](templates/subSilver/images/spacer.gif) |
Geps
Joined: 05 Jul 2010 Posts: 129
|
|
Posted: Fri Nov 11, 2011 10:51 am |
|
|
No, I don't have to store alot of data so I use a CRC for each piece of data. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Nov 11, 2011 3:16 pm |
|
|
Quote: |
I need a suggestion regarding the use of the internal EEPROM of a
PIC18F4525. The system performs an update every 10 seconds a few
bytes of EEPROM state.
|
That's 6 updates per minute, which is 360 per hour, which is 8640 per day,
and that gives approximately 260K per month.
Look in the 18F4525 data sheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/39626e.pdf
This table gives the lifespan (for writes) of a byte in the eeprom:
Code: |
TABLE 26-1: MEMORY PROGRAMMING REQUIREMENTS
Data EEPROM Memory
Min Typical
D120 Byte Endurance 100K 1M
|
So if you consider that after possibly 100K write operations per eeprom
byte, the cell may become unreliable, then your update rate of 260K
writes per month will cause a problem. (I am assuming 24hr/continuous
operation of your board).
There are several threads in the CCS forum and the Microchip forum on
alternative methods to solve this problem. |
|
![](templates/subSilver/images/spacer.gif) |
Fabri
Joined: 22 Aug 2005 Posts: 275
|
|
Posted: Sat Nov 12, 2011 3:16 am |
|
|
Yes PCM programmer.
But I write only if data changed and not all data every 10 seconds. So the write operation of single eeprom location, in the life of product, is under eeprom life. This data are only status of electronics and not really important because I restore it at start-up.
In any case I take care of your consideration and think about. With your experience, for improve my knowledge, can you suggest me other better ways ?
Regards,
Fabri |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Sat Nov 12, 2011 3:23 am |
|
|
OK.
The classic way of dealing with this possibility is to hold two sets of data.
Each set has as well as the CRC, a counter at the end.
You write a new block of data, and only once you have written it, increment the counter.
Each time you write, you work on the opposite block to the last one used.
On 'wake up', you read the counters, and take the one with the higher counter, as the 'last block'.
This way if a write fails, and the counter has not updated, you get the last value. If the counter has updated, then you know the data has already been verified as written.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|