 |
 |
| View previous topic :: View next topic |
| Author |
Message |
nilsener
Joined: 06 Dec 2005
Posts: 59
|
| Data EEPROM read/write reliability |
 Posted: Wed Nov 01, 2006 3:01 am |
 |
|
Dear,
1st problem: I am thinking about how many reads and/or writes of internal data EEPROM may fail. In my opinion, read and write of internal EEPROM is communication such like RS232 or so, certainly with easier protocol and I think without error determination. So I am afraid that at any time over the livetime of the unit a single bit may be read or written incorrectly without notice.
2nd problem: what to do if a cell of EEPROM may be defective irreversibly.
Some ideas how to handle this problem? Store data redundant? Is it realistic to handle this problem if EEPROM will be written max. 100 times over the livetime? (1 million cycles possible at 18F2520)
If this (1st and 2nd prob) can not be surely avoided, I have to store data redundant e.g. 3 times to solve the read problem. Or better way?
The write problem may be avoided through a read back and write again if verify fails (for 1st prob).
I have to store different data in the eeprom, e.g. setpoint ALARM max and ALARM min etc. If a read or write of data may fail it results in malfunction of the hole unit.
Many thanks for any suggestions and experiences!
Best Regards
nilsener |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Nov 02, 2006 12:23 am |
|
|
I've posted two methods of validating data stored in eeprom.
The first one does range checking, and the 2nd one uses
a checksum. These are both simple methods. I'm sure they
could be improved.
--------------
Here is one way to do it. After reading a temperature
setting from NVRAM (could also be EEPROM), the value
is checked again acceptable high and low limits. If it's
out of range, a default value is used. The NVRAM is
updated with the default value.
One problem with this method is that the temperature
read from NVRAM could be incorrect but if it's within
the acceptable range, it will still be used. Of course,
in this particular application the range was fairly narrow,
(80 to 95 degrees Fahrenheit), so it didn't really hurt
much if that happened. (Even though it was unlikely).
| Code: |
// Read the water temperature setpoint from NVRAM.
gc_temp_setpoint = ds1307_read_byte(TEMP_SETPOINT_NVRAM_ADDR);
// Validate the temperature setpoint. If it's out of range,
// then use the default value.
// The "OFF" setting is not considered to be out of range.
// So skip the range check code if the value = 'OFF'.
if(gc_temp_setpoint != TEMP_SETPOINT_OFF)
{
if((gc_temp_setpoint > MAX_TEMP_SETPOINT) ||
(gc_temp_setpoint < MIN_TEMP_SETPOINT))
{
gc_temp_setpoint = DEFAULT_TEMP_SETPOINT;
// Write the default value to NVRAM.
ds1307_write_byte(TEMP_SETPOINT_NVRAM_ADDR,
gc_temp_setpoint);
}
} |
Here's another way to do it. In this routine, the mode value
and its checksum are read from two eeprom bytes. The
checksum is just the inversion of the mode byte.
The mode is then XOR'ed with the checksum. If the bytes
are correct, the result will be 0xFF. If there is an error,
a default value is returned. Also, the EEPROM is then
updated with the default value and its checksum.
| Code: |
int8 read_mode_from_eeprom(void)
{
int8 mode;
int8 checksum;
mode = read_eeprom(EEPROM_MODE_ADDR);
checksum = read_eeprom(EEPROM_CHECKSUM_ADDR);
// XOR the mode byte and the checksum byte together.
// If the result is 0xFF, then it's OK. If not, there's
// an error, so return the default value as the mode.
if((mode ^ checksum) != 0xFF)
{
mode = DEFAULT_MODE;
write_eeprom(EEPROM_MODE_ADDR, mode);
write_eeprom(EEPROM_CHECKSUM_ADDR, ~mode);
}
return(mode);
} |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
