0

I have checked with two datasheets: one for some ATMegas and one for some ATTinys MCUs and could not find what the EEPROM.get() call would read back if the EEPROM was empty (or contained default factory values). I have written a program in order to find out and it looks like on Arduino Uno the EEPROM bytes are all FF by default.

Is this the case with every Arduino board or just some of them ? Or perhaps we can not assume that all the MCUs of a certain type (such as ATMega328) will have this factory preloaded value of FF for the EEPROM bytes ?

edit

Following the fuses - thanks @Chris Stratton - I was able to find this in the datasheet:

Skip writing the data value 0xFF, that is the contents of the entire EEPROM (unless the EESAVE Fuse is programmed) and Flash after a Chip Erase.

Seems like we could get the factory pre-loaded value by not programming the EESAVE fuse, which is what the Arduino Uno does by default, and just reading them.

uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extendedfuses=0xFD

However, having a way to set them to a known value is fine too for my needs, so I shall just write that fuse and havea guaranteed 0xFF all over the EEPROM.

2
  • What difference it makes?
    – user31481
    Nov 15, 2017 at 19:41
  • 1
    You'll have to check the specific ATmega fuse settings, but I believe that by default the Arduino programming process erases the EEPROM, so an Arduino-based test may not show you what the contents were before you uploaded the test program. Nov 16, 2017 at 3:55

2 Answers 2

2

When you erase an EEPROM it sets the cells to 0xFF. When you write a byte to a cell any 0 bits are set to 0 and the 1 bits are left alone.

0xFF is the normal erased state for most EEPROMs.

3

They're all set to 0xFF by default.

4
  • On what authority do you rest this claim? Nov 16, 2017 at 3:52
  • 1
    Having read unset EEPROM on several of the chips when new. I know it is true at least for the 328, 1284, and 2560. Having heard the same from many others who have seen the same. Why are you seeing something different?
    – Delta_G
    Nov 16, 2017 at 4:00
  • Read it how? Some methods would likely have pre-erased before you could do so. But even with one that couldn't, there's a big difference between observations of typical values of unspecified aspects, vs those which are actually specified by the manufacturer. Nov 16, 2017 at 4:14
  • 1
    Ok sure. Do you know what they are preloaded with? I've heard the 0xFF from enough people in enough places to believe it beyond my own observations. Do we have any reason to believe otherwise? Do you have any documentation saying that it isn't? What makes you think my method isn't sound? avrdude doesn't erase the eeprom the way I normally use it. I know this because I can load a sketch that writes in configuration values and the load another new sketch that uses them and they're still there. And my code actually tests for 0xFF to determine if the configuration values have been written
    – Delta_G
    Nov 16, 2017 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.