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.

  • What difference it makes? – user31481 Nov 15 '17 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. – Chris Stratton Nov 16 '17 at 3:55
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.

4

They're all set to 0xFF by default.

  • On what authority do you rest this claim? – Chris Stratton Nov 16 '17 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 '17 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. – Chris Stratton Nov 16 '17 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 '17 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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