I am sorry, I did not follow very well what you said, appears to me that
in case of eeprom writing problems, you still have problems anyway. If
the ID byte is recorded in failure, how can you recognize what is right
or wrong?

Suppose you need to record this ID's:   01 02 03 04 05 FF 00  (being 05
the last) and by a problem in the recording, it ended up this way: 01 02
07 04 05 FF 00, how can you identify which one is the last?   Even the
negative difference gets crazy here.

Memory data corruption is a problem anyway, and you simply can not avoid
them all, you can be sure that if you don't cover 100% of the error and
possible solutions, it will get you sooner than you can think.

For example, to avoid problems with power down while recording the
eeprom, you should have enough backup energy to complete the eeprom
recording, anything less is asking for problems.  An interrupt power
fault is a must to decide if it will or not record the eeprom, or any
other kind of NVRAM or flash. This is a traditional understanding of
"loose the new 8 data bytes" or "corrupt the old existent megabyte".

An easy way, avoid to use the block ID byte, just stablish a fixed
position at your e2prom to store the address of your last register. Use
two fixed locations. LAST1 and LAST2, they both are the same, but LAST1
is recorded before you write the register, LAST2 is recorded after you
write it. So, LAST1 will always be ok, because it is written fast. If
LAST2 is different than LAST1, it means you got a power loss during the
register recording and it is not valid, being LAST1 - 1 the last valid
recording.

Wagner

Nikolai Golovchenko wrote:
>
> Hi Wagner
>
> >Any other math solution doesn't work, since if your block ID's are also
> >circular from 00 to FF, there is NO WAY to find out which one was the
> >last, except in one condition:
> >If your circular buffer size is not a perfect multiple of the (block
> >data size + Id) * 256.  In this case you can search for a disrupt in ID
>
> Why should the block size be so restricted? You just have to know the block
> size, whatever it is, to find IDs locations. The block size have to be fixed
> though, because EEPROM failure may disrupt the whole sequence.
>
> >sequence.  For example, if you circular buffer is only 256 bytes long
> >and your block size is 32 bytes:
> >
> >ID  DATA (31Bytes)- - - - - - - ->
> >01  00 01 02 03 04 ... 1E <--- begin of circular buffer
> >FD  00 01 02 03 04 ... 1E
> >FB  00 01 02 03 04 ... 1E
> >FC  00 01 02 03 04 ... 1E
> >FD  00 01 02 03 04 ... 1E
> >FE  00 01 02 03 04 ... 1E
> >FF  00 01 02 03 04 ... 1E.
> >00  00 01 02 03 04 ... 1E <--- end of circular buffer
> >
> >If the block size is fixed, then you see that the difference between two
> >block ID's is different than 1 it means the lower address block is the
> >last one, if the circular buffer runs up address. In this example it is
> >clear that the last register is the first on the buffer.
>
> Because of the possible record failure, looking for difference different
> from 1 may not work.
>
> >Again, this technique will not works if your circular buffer holds only
> >2 blocks,
>
> But it will if you are looking for *negative* difference.
>
> 2 blocks example:
> 00 01      1 - 0 = 1, next, 0 - 1 = -1, bingo! 1 is last
> 02 01      1 - 2 = -1, 2 is last
> 02 03      3 - 2 = 1, next, 2 - 3 = -1, 3 is last
> FE FF      FF - FE = 1, next, FE - FF = -1, FF is last
> 00 FF      FF - 0 = FF = -1, 0 is last
>
> With this technique, all possible IDs make up a circle,
>
>                 00  01
>            FF           02
>          FE                03
>         .
>         .                  04
>
>          0A                05
>             09          06
>                 08  07
>
> where IDnext = IDprevious + 1. Because ID can overflow, this is not true
> when IDprevious = FF. If you use for difference the same number of bits,
> i.e. 8, then the difference will overflow too at the same place (00 - FF =
> 1). In this case, if you take any two consecutive numbers on the circle the
> difference is *1* always. And different from 1 if distance between IDs is
> greater than 1.
>
> In Dwayne's case there is a possibility of EEPROM failure that may cause one
> record to be bad (record writing cycle not finished in case of power down).
> So difference may be 2 as well for ascending numbers. Value, different from
> 1 or 2, will indicate the end of sequence. This makes possible *254* length
> of sequence!! Since Dwayne needs only 8 records I would suggest just test
> the MSB of 8 bit difference.
>
> Hope it helps :)
>
> _
>
> Nikolai Golovchenko, Electrical Engineering Student
> National Mining University of Ukraine www.nmuu.dp.ua
> Dnepropetrovsk, Ukraine
> E-mail: golovchenko@mail.ru