AVR Freaks

I already told you in the other thread. 

The lines above create some data in the .eeprom section.

D:\test\GccApplication1\GccApplication1\Debug>avr-objdump -s -j .eeprom GccApplication1.elf

GccApplication1.elf:     file format elf32-avr

Contents of section .eeprom:
 810000 04030201                             ....

You can see 04 03 02 01 in that (and, yes, it just happens to have been placed "backwards"). The above has been created withing the ELF file for the project.

At build time an avr-objcopy command is run to extract .eeprom from the ELF file and create an EEP file. You can see that:

D:\test\GccApplication1\GccApplication1\Debug>type GccApplication1.eep
:0400000004030201F2
:00000001FF

The key part in that is:

:04 0000 00 04030201 F2

So this is a 4 byte record at address 0000 that is type 00 (data) and the data bytes are 04 03 02 01 with a checksum of F2.

So all you have to do is when you use your programmer to load GccApplication.hex into the flash of the AVR you also use you programmer to load GccApplication.epp into the EEPROM of you AVR. That means that EEPROM location 0000 will contain 04, location 0001 will contains 03 and so on.

When you AVR code does something like:

byyte = eeprom_read_byte(&code3);

then because "code3" actually has the EEPROM address 0001 this will read whatever is in EEPROM location 0001 and because of the .eep file you programmed into it then it will find 03 there.

As you were told in the other thread do set the EESAVE fuse active. By default when you put new code into the AVR the programming starts with a "Chip Erase" and, unless told otherwise, chip erase means "wipe flash and EEPROM". So if you have not set EESAVE you will find that you have to program in both the .hex file and the .eep file every time. If you have set EESAVE then when "chip erase" is performed it will not wipe the EEPROM and the 04 03 02 01 that is already there will remain.

Yup, it's one extra thing stored as a flag in the EEPROM basically to say whether what is found in the EEPROM can be trusted or not. Some folks might actually group this all together as something like:

typedef struct {
  uint8_t code[4];
  uint16_t validity_cookie;
} eeLayout_t;

eeLayout_t eeVars EEMEM;

int main(void) {
    if (eeprom_read_word(&eeVars.validity_cookie) != 0x55AA) {
        eeLayout_t eeCopy;

        eeCopy.code[0] = 1;
        eecopy.code[1] = 2;
        eeCopy.code[2] = 3;
        eecopy.code[3] = 4;
        eeCopy.validity_cookie = 0x55AA;

        eeprom_update_block(&eeVars, &eeCopy, sizeof(eeLayout));
    }
    // etc.
}

I like "objects" that group together all the things that are connected in some way so the eeLayout is nice as it puts the 4 byte code and also my vailidity value all grouped together. It also just need one write (update) to write everything in one go. My read/check code shows that I can also access single items or groups from within the structure too. So read the 4 byte code I might later do something like:

uint8_t code[4];

eeprom_read_block(code, &eeVars.code, 4);

to read all 4 bytes in one go into a four byte array in RAM called code[].

PS forgot to say that if I was going to use an EEP file then:

eeLayout_t eeVars EEMEM;

could just as easily be:

eeLayout_t eeVars EEMEM = {
    { 1, 2, 3, 4},
    0x55AA
};

to give initial values that would create the .eep contents.