AVR Freaks

So in global.h I have some variables which are used in main.c, init.c and interrupt.c.

Just checking but the extern in the header does have ONE instantiation in some C file doesn't it?

(I guess it must have or you would be getting a link error).

EDIT:

Both of these variables are incremented in the same code snippet

Just a minute  - that does not make sense. You cannot just:

int EEMEM n = 37;

while(1) {
    n++;
}

if that's what you are talking about? You would need something like this:

int EEMEM n = 37;
int n_in_RAM;

while(1) {
    n_in_RAM == eeprom_read_word(&n);
    n_in_RAM++;
    eeprom_write_wrod(&n, n_in_RAM);
    // and to see it:
    LCD_print_var(n_in_RAM);
}

My eemem variable is written immediately after increment using this command: eeprom_write_word(&my_eeprom_variable, my_eeprom_variable);

But you cannot do that - &my_eeprom_variable is nothing more than an address in the EEPROM chip. You cannot use it like a "real" RAm based variable. You Have to read what is at the address of my_eeprom_variable into something that can be updated, then update it, then write that cached copy back again.

All that:

volatile uint8_t EEMEM my_eeprom_variable;

is asking the linker to "set aside 8 bits in the EEPROM for me please and let me refer to that location 0x1234 as "my_eeprom_variable" or whatever". Look again about what I said of "n" in my example above. You cannot do things like "n++". Instead you must eeprom_read_*() the contents of the location into something that can be updated (using code underneath eeprom_read*() that knows about EEAR, EEDR and so on). Once the item is in registers or RAM it can be operated on. When the update is finished it must then be explicitly written back.

It seems to me that you've misunderstood EEMEM, based on your choice of variable names:

uint16_t EEMEM my_eevar_address = 0;
volatile uint16_t my_eevar = 0;

Yes this fine, and the way in which you are accessing both variables is correct, but it belies what I think may be a misunderstanding.

What you have called my_eevar_address is not an address at all.  It is in fact a variable in EEPROM.

When you call a function like:

eeprom_read_word(&foo);

... you are passing the address of foo, but you are doing by way of the unary pointer operator '&'.  So foo is the variable, but &foo is the address of that variable.  In the case of a variable in EEPROM as declared by EEMEM, that address is an EEPROM address.

Names more in keeping with the nature of these variables might be:

// global.h
extern uint16_t EEMEM my_eevar;
extern volatile uint16_t my_eevar_sram_copy;

// global.c

uint16_t EEMEM my_eevar = 0;
volatile uint16_t my_eevar_sram_copy = 0;

// reading from EEPROM
my_eevar_sram_copy = eeprom_read_word(&my_eevar);

// writing to eeprom if required
eeprom_update_word(&my_eevar, my_eevar_sram_copy);

Another thing to keep in mind is that when you initialize an EEMEM variable the compiler places that initialisation into a section called .eeprom.  In fact, that's all EEMEM itself actually does:

#define 	EEMEM   __attribute__((section(".eeprom")))

After building your code, that section can be carved out of the .elf file into .hex file and programmed into the EEPROM memory of your target, in the same way in which the code itself is carved out of the .elf file into a .hex file and programmed into the flash memory of your target.  It's important to know that unless you program the EEPROM memory, any initialisation of EEMEM variables will not be performed.  Changes to EEMEM variables through the use of the eeprom_write_*() and eeprom_update_*() functions will be unaffected.