I assumed the microcontroller has 3 components as per storing data: - flash memory for the program - RAM for variables - EEPROM for non-volatile user-storage

And I always assumed those are separate chips on the board. However, working directly with a RobotDyn Uno R3 leads me to believe I may be wrong somehow.

I compiled this program:

#include <EEPROM.h>

struct SettingsStruct {
  String server;
  String port;
  String user;
  String password;
  String description;
} gSettings = {
  "fci blah vlak",
  "Extra string here"

void setup()


  Serial.print(F("EEPROM size is: "));
  Serial.print(F(" bytes"));

  Serial.print(F("Server: "));
  Serial.print(F("Port: "));
  Serial.print(F("Username: "));
  Serial.print(F("Password: "));
  Serial.print(F("Description: "));

void loop()
  // nope

void loadConfig() {
    for (unsigned int t=0; t<sizeof(gSettings); t++)
      *((char*)&gSettings + t) = EEPROM.read(t);

void saveConfig() {
  for (unsigned int t=0; t<sizeof(gSettings); t++)
    EEPROM.write(t, *((char*)&gSettings + t));

Problem is that each time I add new elements to the struct, and I run the program, the serial prints different things. I recognize previously saved strings but they are right shifted, meaning that somehow the ZERO address of EEPROM might have moved backwards and previously saved strings move right and offocurse, appear on other struct variables.

This leads me to believe the actual EEPROM is related with the flash memory and depends on it on each compile. As if the ZERO address of EEPROM is established after each compile.

Can anyone confirm this or lead me to some documentation relating this? It's a weird mystery that I would like to clear out.


The EEPROM is a completely separate part of the silicon inside the chip. It has no address of its own.

You are making a fundamental error in what you are doing, though - you cannot directly store the contents of strings by looking at the addresses of those strings. The data in them is dynamically allocated in RAM and is completely separate from the object. You will have to come up with a different way to store your data.

  • The assumption was that EEPROM starts ALWAYS at the same address. the struct defined above should be able to be loaded as long as the save is equivalent. And it actually is. Problem was that data is shifting in EEPROM and I don't know why. I read your answer many times and it still does not help me understand this. What am I missing? Mar 1 '17 at 0:10
  • 3
    The struct is saved and loaded fine. The point is that the string data isn't in the struct for you to save. The struct only contains the String objects, and those just contain a pointer to dynamically allocated (at runtime) memory for the string data.
    – Majenko
    Mar 1 '17 at 0:11
  • There's my problem. "dynamically alocated at runtime". My thought was that EEPROM is a fixed data storage entity you can always address the same way, similar to old assembly addressing mode. The fact that the EEPROM chip is separate also allows me to sustain this assumption. Why would runtime execution allow data shifting? Mar 1 '17 at 0:16
  • 1
    You're missing the fundamental issue here. The issue has nothing at all to do with EEPROM. That is exactly as you assume it to be - fixed. You read from address 0 exactly what you write to address 0. The fundamental issue is that you are not writing what you think you are writing to the EEPROM. It's like you have stored the envelope a letter came in and burned the letter itself, then go back to the envelope expecting it to be the letter.
    – Majenko
    Mar 1 '17 at 0:18
  • My struct has a single variable called letter. I write it to eeprom, and I expect the /0 termination indicates the end of the string. Then, I add another variable to the struct. Another string, called title, before letter. Without writing, I read the new structure and observe that the title is gibberish then I can see my old letter further on. Where is the gibberish coming from and why is it before what I wrote before at address zero? This is basically what I don't understand. I do get that you are explaining that the struct itself is a reference. I don't get the field result. Mar 1 '17 at 0:26

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.