EEPROM contents -for a new processor

Hi,

I'm hoping to use EEPROM to indicate if a sketch is being run for the first time (so it can do a calibration routine). After power off and a restart I want it to to be able to see that the sketch has run before.

The question is, for a new out of the box processor (ATmega32u4; Leonardo), can I rely on its EEPROM contents being all xFF?

experiments on a couple seem to show this is the case but.....

thx

You should anyway mark the eeprom with your own code if you are using it for calibration, initialisation or other information. Make the first few bytes something you can always test for e.g. 0xdeadbeef. If you don't find it, assume it is uninitialised (by your application)
Or are you concerned about overwriting an eeprom that may have been set by another sketch and the data may still be valuable ?

hammy:
experiments on a couple seem to show this is the case but.....

So at start up read all locations in the EEPROM and if all are 0xFF ...........................

I would never bet on the contents of the EEPROM, it could contain test data. Use several bytes, put in some AAH 55H your name, 55H and AAH, then the checksum. Try putting that is two locations. To test simply checksum each block if different it is new, if they checksum the same check the values. You could also put the date and time of calibration in there if you want. This response is to help you get started in solving your problem, not solve it for you.
Good Luck & Have Fun!
Gil

Thanks for the replies all - Your idea of extending the data stream and a check sum ( which is easy to do) Is a good one .

I could therefore within, my program, in the first run, upload my default calibration factors with that check data ( as the eeprom will be holding something else and the check sum should fail ) . Next run do the check sum part and don’t change any values if the check sum is ok ( so if meanwhile I’ve adjusted any calibration factors and saved to eeprom they won’t get changed back) .

A new processor EEPROM should contain all 0xFF.
However, Arduino boards have put the Serial Number in the EEPROM of new boards (at one time, anyway), for example.

Calculate over the EEPROM minus the last 4 bytes and compare with the last 4 bytes.

After "the work", update the CRC in the EEPROM (last 4 bytes).

I’ve got this working now and have just put two different bytes in adjacent eeprom addresss ( I used 100&101dec) and check for the presence of these when the program starts - if they are not there , then I assume it’s a first ever run and load up my default calibration factors plus the two numbers . Works fine .
On subsequent runs the defaults aren’t reloaded and any changes I separately made in the calibration factors don’t get spoilt .