Zeroing microcontroller EEPROM in a product

[Psi]

Are there any downsides to zeroing all MCU eeprom locations to 0x00 as the default state for a product.
I ask because it seems more logical to have product settings in eeprom that default to off so they can be used as boolean.
I could add code to treat 0xFF as off but it would be simpler to just set all eeprom to 0x00 to start with.

The eeprom in ATMegas is byte oriented so there's no paging issues.

Can anyone think of physical or software reason why 0xFF is preferable as the default eeprom state?

[ve7xen]

I would deal with this by using one byte as a marker value (e.g. if address 0 is 0xaa, EEPROM data is valid, else initialize it to defaults), or better yet, store a checksum. There are lots of ways the state might be corrupted that could make your code behave screwy if you just trust it.

Unless you're using every byte of EEPROM I don't see an advantage to the extra programming step, but I don't think it can cause harm either. 0xff is just the default state for newly manufactured EEPROM cells (no charge stored on the floating gate), the manufacturer doesn't go to the trouble of setting them to that specifically.

[nctnico]

+1 for the checksum. I usually use CRC32 instead of a simple XOR or sum.

[mikeselectricstuff]

Why add unnecessary code? You _know_ a factory part will be all 0xff. Why add the risk that a bug in your code may not initialise it correctly in all situations (e.g. powerdown during zeroing).

[Codemonkey]

Why add unnecessary code? You _know_ a factory part will be all 0xff. Why add the risk that a bug in your code may not initialise it correctly in all situations (e.g. powerdown during zeroing).

Thats not always the case though. I'm pretty sure I've seen in datasheets of devices I used (long ago admittedly) that the contents of on chip EEPROM was undetermined and could not be guarenteed to be all F's on products straight from the manufacturer, so basically read the datasheet carefully if you're going to make an assumption like that.

I do agree about not adding uncecessary code wherever possible though!

[JoannaK]

It just happens to be, that all (e)eproms natural erased state reads out as '1' .. This is due design of the hardware. If there's any other value, then the chip has not been erased properly.

In fact, even though you might just want to write a new value into Eeprom byte, in backgroud there's (AFAK) is still a mandatory erase cycle required. Nowdays this erase cycle is usually well hidden and it's not necessary to initiate manually. So if you want to store (say $55) to a byte of eeprom, beheind the scenes the event is:

Old value $89 -> Erase ($ff) -> write ($55)

And the basic rule of eeproms is, that it's not Writing the 0_es that wears down the chip, but the limitations of erase cycles. In the very begin of the EEprom technology (with like 100 or 1000 cycles) it was recommended not to erase entire byte, but to write down the necessary 0:s, and/or do manual write/erace balancing across the memory. 

I think Motorola (nowdays Freescale, that is) did have some excellent articles of this one concerning their early Eeprom chips.
 

[Kremmen]

To add an unnecessary comment to an already well handled topic: I always preface the EEPROM area with a magic sequence to indicate whether it is properly initialized or not. Presence of that magic sequence is a guarantee that the rest of the EEPROM or whatever portion of it has been used, is consistent and contains valid data. Only if the data is anything safety related do i bother with checksums because they are a bit risky if the data changes a lot. The checksum sites in the EEPROM will be updated every time anything else is, and potentially there is the risk of running out of rewrite cycles. Maybe not a concern usually and there are ways to cycle the location of the checksum data, but usually i don't bother.
Never had one fail yet.

[madires]

Are there any downsides to zeroing all MCU eeprom locations to 0x00 as the default state for a product.
I ask because it seems more logical to have product settings in eeprom that default to off so they can be used as boolean.
I could add code to treat 0xFF as off but it would be simpler to just set all eeprom to 0x00 to start with.

The eeprom in ATMegas is byte oriented so there's no paging issues.

Can anyone think of physical or software reason why 0xFF is preferable as the default eeprom state?

For storing settings in the EEPROM you can define variables located in the EEPROM with a default value of 0x00. When programing the MCU the EEPROM area used for your settings is set to 0x00 then. The unused space remains untouched (0xFF). There's no need to 0x00 the complete EEPROM.

[Psi]

Why add unnecessary code? You _know_ a factory part will be all 0xff. Why add the risk that a bug in your code may not initialise it correctly in all situations (e.g. powerdown during zeroing).

I was planing on zeroing the eeprom as part of the process that uploads the device with its first firmware after PCB assembly.
It would be done by the test jig over programming SPI and not done by the mcu itself.

That way i can be sure all boards have zero'ed eeprom and all devices ship with optional features in the off (default) state.
however i do like Kremmen's idea of a "magic sequence".

For storing settings in the EEPROM you can define variables located in the EEPROM with a default value of 0x00. When programing the MCU the EEPROM area used for your settings is set to 0x00 then. The unused space remains untouched (0xFF). There's no need to 0x00 the complete EEPROM.

Do you mean declaring the variables as EEMEM? i really do not want to do that.
It gives the compiler complete control over where in eeprom a variable is stored.
The same code compiled in the future on a different compiler version may not make the same decision and could corrupt the settings.

[madires]

I was planing on zeroing the eeprom as part of the process that uploads the device with its first firmware after PCB assembly.
So it would be done by the test jig over programming SPI and not done by the mcu itself.

That's what I meant, but just for the space used for settings. It's done the same way for the Transistor Tester. When SPIing the firmware the default calibration values are stored in the EEPROM too. Later on the running firmware updates the values if requested by the user. My alternative firmware also adds a simple checksum to detect problems and tells the user about.

That way i can be sure all boards have zero'ed eeprom and all devices ship with optional features in the off (default) state.

You can set the defaults to whatever you like :-)

[madires]

Do you mean declaring the variables as EEMEM? i really do not want to do that.
It gives the compiler complete control over where in eeprom a variable is stored.
The same code compiled in the future on a different compiler version may not make the same decision and could corrupt the settings.

If you care about the exact location you can tell the linker to use a specific address. The best way is to put all settings into a struct, define a variable for the struct in the EEPROM, assign that to a named section and add "--section-start=.name=0x...." to gcc options in the Makefile.

[Psi]

I already have that bit working fine using fixed eeprom address that come from a few macro functions.
I pass the macro function what i need and it returns the eeprom address for that data.

[madires]

I already have that bit working fine using fixed eeprom address that come from a few macro functions.
I pass the macro function what i need and it returns the eeprom address for that data.

With a struct and the block-read/write functions you could read/write all settings at once :-)

[Niklas]

Why not redefine TRUE to something else than "anything but 0"? We used 0x55 as TRUE and 0xAA as FALSE in an safety related application. Everything else was treated as incorrect and taken care of by the error handler.

I like the magic sequence that Kremmen mentioned. I used that on an alphanumeric LCD, without proper busy flag at startup, to check for ESD related display reboots. The sequence was written outside the visible range in the display's CGRAM and read back periodically.

[Psi]

Yeah, i could definitely do it in software.

[nctnico]

Why add unnecessary code? You _know_ a factory part will be all 0xff. Why add the risk that a bug in your code may not initialise it correctly in all situations (e.g. powerdown during zeroing).

The same can happen while writing other values. The best thing to do is to use a strong checksum and use safe defaults when the checksum fails.