Using precisely this code - the eeprom_put example in the Arduino IDE, and am seeing some strange results...

The sketch does write correctly to eeAddress = 0, and the corresponding eeprom_get sketch does return the data.

Please note that I've initialized the entire EEPROM with 'FF's before any test...

The weird part is this sketch writes exactly the same data starting at Address = 2048. The loop is not running; I see no jump to offset 2048... I gotta be missing something!

I'm dumping EEPROM using avrdude, and viewing results in an external hex editor.

How is this stuff stored? Apart from not being able to directly view a float - OK, I get it - should the other data be simply viewable in hex?

My own experiments in writing hex bytes directly also work, but also write in two locations.

Small update to this: Precisely the same behavior seen with a RobotDyn Mega. Both the 'clone' Mega and the RobotDyn report: Device signature = 0x1e9801 (probably m2560)

#include <EEPROM.h>

struct MyObject {
  float field1;
  byte field2;
  char name[10];

void setup() {

  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only

  float f = 123.456f;  //Variable to store in EEPROM.
  int eeAddress = 0;   //Location we want the data to be put.

  //One simple call, with the address first and the object second.
  EEPROM.put(eeAddress, f);

  Serial.println("Written float data type!");

  /** Put is designed for use with custom structures also. **/

  //Data to store.
  MyObject customVar = {

  eeAddress += sizeof(float); //Move address to the next byte after float 'f'.

  EEPROM.put(eeAddress, customVar);
  Serial.print("Written custom data type! \n\nView the example sketch eeprom_get to see how you can retrieve the values!");

void loop() {
  /* Empty loop */
  • What board/mcu are you using? And did you give a larger eeprom size to avrdude to dump? Mar 17, 2017 at 19:39
  • It's a mega2560 - in fact, avrdude correctly detected it, and its 4k EEPROM size. No, did not override any EEPROM size parameters.
    – DrLou
    Mar 18, 2017 at 1:36

1 Answer 1


What is probably happening is aliasing. Let's say your processor has a 16 bit address bus. 16 bits can count up to 2^16 = 65536 = 64k memory addresses. Each address is a byte (B) so your processor has 64k-Bytes of address space. It can physically address 64kB of memory.

What happens if you only have one memory chip with 4KBytes of memory, with only 12 address lines? Well, if the designer was lazy (or cost-conscious), the first 12 address lines on the processor will be connected to the 12 lines on the memory chip. The other 4 lines on the processor will be ignored.

So it doesn't matter what the processor does with address lines 13-16 -- they're not connected to the memory chip. Therefore the contents of the memory chip appears where you expect, starting at address 0, but also again at address 4096, and again at address 8192 and so on.

  • Ah! I had no idea about this. And I imagine it seems a reasonable possibility for a cheap clone Arduino Mega2560? Supposed to have 4k of EEPROM, but sounds like you're saying a big chunk of it may not be usable!
    – DrLou
    Mar 17, 2017 at 19:32
  • The Arduino Mega 2560 has 4k of EEPROM and all 4k is usable. Only a few ATmega chips have 2k EEPROM, for example the ATmega644. Perhaps you are doing something wrong, perhaps avrdude is limited, or perhaps you hit a bug. When you do a read from 2048 in the sketch, you only see FF ?
    – Jot
    Mar 17, 2017 at 20:47
  • Well, it's slightly more nuanced than that. Board reports it has 4k bytes, as I'd expect. Its behavior at this point seems consistent with Mark Smith's comment above. A good test will be an attempt to write to addresses above 2048 - will try this tomorrow.
    – DrLou
    Mar 18, 2017 at 1:41
  • Another update: Yup, similarly weirdness when writing to address: byte eeAddress = 0x800. Data is written to both 0x800 and 0x00. Wow! @Mark Smith - whaddaya think? Anybody else interested in testing this on their own boards?
    – DrLou
    Mar 19, 2017 at 15:20
  • That's exactly the same behavior. 0x800 = 2048. Because of the incomplete decoding of the addresses, those addresses address the same piece of memory. They are the same piece of memory.
    – Mark Smith
    Mar 19, 2017 at 15:27

Your Answer

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

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