Hey Dwayne, I already went to that beach, the water is not so cold... :) Simple and easy, you have two choices: a) If you have an extra byte at the eeprom, just save the last IDentification block number there, or circular buffer pointer, so when you power up again, just read it and set the buffer pointer back, or search for the ID into the circular buffer. b) If you DO NOT have this extra byte, or don't want to keep reducing the eeprom life, just reserve the "00" identification byte for the next empty block, use block ID's from 01 to FF. Whenever you write a block, write an extra byte of "00" after that block, *that* will be your mark of END OF CIRCULAR BUFFER. For sure this "00" will be recorder over the oldest block identification byte, but even so you would be able to read that block of data. With this option, at power up, you just need to go to the beginning of the circular buffer, and start reading just the block ID's, looking for "00", so the most recent is exactly the previous one, the oldest the one with the "00". 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 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. Again, this technique will not works if your circular buffer holds only 2 blocks, or its size is exactly the block size times 256 (to a 8 bits ID), so the disruption above 65 -- 62 would then be 65 -- 66. As you said, you are using 256 bytes of buffer, 32 bytes per block, so it is only 8 different block ID's, so the above technique will work. Now, if you really don't need to store the block ID number, then: If the first data byte values follows some kind of rule, for example, it is always less than 7F, you could use the bit 7 turned on only for the next buffer available byte, so easy to scan when powering back on. Or if the data bytes never use some bit combination, use that combination at the next buffer available byte. In any way, you need to remember that you have a limited quantity of write operations in the eeprom chip. There are eeproms for 100k or 1M recordings (never clear from manufacturer, temperature changes it). Suppose the worst scenario, 1 minute per recording, you are using 32 write cycles per recording, per minute, gives you 3125 recordings or only 52 hours. A whole month has only 720 hours!!! Suppose the best scenario, 1M recordings in one hour interval, 21250 recordings, 885 days. Lets go for the average: 500k write cycles, 30 minutes per recording, 15625 recordings, 7812 hours, 325 days. So, your unpredictable e2prom life can goes from less than a month to almost 3 years... I would not bet on this solution as the best one, if you need several months of working situation. Do you already considered the possibility to use NVRAM? You could avoid CRC and all, just write 3 times the same record, when reading just compare and go for the majority in case of problems (you would not have problems with NVRAM during 10 years). Dwayne Reid wrote: > Thats the problem - I have to find *which* record is newest in order to set > the buffer pointer. > > When the system powers down, all I have is the data stored in eeprom. I am > currently using 8 records of 32 bytes each in the buffer - another record is > stored at some time varying from 1 minute to an hour. > > Each record includes a CRC to warn me of a corrupted record or damaged > eeprom. If a damaged sectoin of eeprom is found, I swap in one of 7 spare > chunks (just change the pointer in my 'housekeeping' section. > > Essentially, I consider any location that gets written often to be subject > to damage. Thats why I don't keep my buffer pointer in eeprom - it would > have to be written every time a new record was written - and, if that > location died, I would have no way of dealing with it. The way I have it > set up now, my housekeeping section get written once upon first power-up, > then written only when necessary to map out a defective section of eeprom. > Each of the 8 records currently in use contains the 1 byte sequence count - > I simply need to find out which count is highest so that I can set my buffer > pointer to that record. > > I start off with 512 bytes of eeprom. This is divided into 16 chunks of 32 > bytes each. One of those chunks is reserved for what I call 'housekeeping' > - it contains 3 copies of the start addresses of the 8 records in my buffer. > This leaves me with 7 spare chunks of eeprom that will get swapped in as > required. When the last of those is gone, my buffer drops from 8 records > down to 7, then 6, etc. Of course, when I have lost more than a couple of > spare chunks, I'll signal that maintenance is required. > > I hope this explains things a bit more clearly. > > dwayne >