On 12 Dec 2017 at 23:30, Isaac M. Bavaresco wrote:

> > Just reminding myself why I am doing this: By avoiding 0xFF as a CRC va=
lue I=20
> > avoid incorrectly reading as valid a record where the data was written =
to EEPROM=20
> > but the CRC was never written (which normally happens after validation)=
, with 0xFF=20
> > simply being the erased state of the EEPROM.
>=20
> You are missing one important point: For a record be deemed valid, the
> CRC calculated during the checking procedure must be equal to the CRC
> that was calculated during the saving process (and that was saved along
> with the data).
>=20
> It is impossible for a record that does not have its CRC value stored
> with it to pass the validity test, unless the random value in the CRC
> area is equal to the correct CRC (but then, it doesn't matter if it was
> not saved,it was already there).

Hi Isaac,

It is that random value in the CRC position that concerns me. If it was not=
=20
intentionally written there then the record was never "validated", yet it c=
ould=20
accidentally match the correct CRC and make it appear valid. A little more =
likely to=20
occur with a CRC of 0xFF, due to that being the erased state of EEPROM, but=
 then=20
probably only until one full cycle through EEPROM has altered all the value=
s.

I imagine the process will go like this: I save a few bytes of data to EEPR=
OM, I=20
immediately read it back to verify that it has been written correctly, if v=
erified then I=20
write the CRC to the immediately following address in EEPROM, reading back=
=20
again to verify the whole record. If the CRC value is not written (could be=
 because=20
the data was corrupt, or failed to write correctly, and failed the first ve=
rification), and=20
the EEPROM location where the CRC should have been written accidentally=20
matches the correct CRC, then it becomes a "valid" record which I don't wan=
t it to=20
be.

If I exclude 0xFF from the list of valid CRC's as planned, and instead use =
that value=20
to indicate "no CRC, record not validated", then record validation can be b=
etter=20
trusted. It may be advantageous to write 0xFF to the CRC location one recor=
d=20
ahead of the record being written... though that would double the number of=
 writes=20
to those locations and impact on EEPROM endurance.

Cheers, Brent.

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