Atmega328 EEPROM

[dan3460]

I have been working on this problem for several hours and I was thinking that my code was bad. I have looked all over for examples and could not figure it out. I have a function that writes a byte of data to a eeprom location  and another that reads that location. I tried all type of casting the variable with the data, but every time that I read the location it showed 255 or 0xFF, which I think is the code for location not written. I was doing the following, remember this is for test purposes, i would put the write function on the program, run it on the chip to save the parameter. Then comment put the write function and uncommented the read function, but it will give me 255.
So I did the following:

Code: [Select]

eeprom_write_byte((uint8_t *) 10, (uint8_t *)78);

for (int x=0; x<20; x++)
{
lcd_gotoxy(0,0); lcd_int(eeprom_read_byte((uint8_t *)x)); lcd_puts(" "); lcd_int(x);
_delay_ms(500);
lcd_gotoxy(0,0); lcd_puts("              ");
}The display shows 255's in all but address 10, where it shows 78, but if i comment the write statement the whole series is 255, the 78 disappeared from memory.

Is the EEPROM erased every time that the program is loaded on the chip? Is there a trick to make the memory permanent on the chip?
thanks for the help.

[georges80]

What are you using to program the chip? I use atmega328pb as well as attiny24/44/88, attiny85, attiny861 and they work just fine, flash & eeprom are reliable.

Many programming programs will erase eeprom when they program the flash memory - they also have options to NOT erase the eeprom when programming the flash.

You need to figure out the options in your programmer.

I use Studio 7 and at Atmel ICE programmer.

cheers,
george.

[bobaruni]

Try waiting before performing a R/W.

Code: [Select]

uint16_t EEPROMAddress = 10;
uint8_t EEPROMData = 78;

eeprom_busy_wait();
eeprom_write_byte((void*)EEPROMAddress, EEPROMData);


eeprom_busy_wait();
EEPROMData  = eeprom_read_byte((void*)EEPROMAddress);



[sleemanj]

As above, if your write and read is done by two different programs, with an upload in between, the Arduino IDE for example will erase the EEPROM during the upload, because it does not provide the -D option to avrdude (-D = Disable auto erase when uploading to flash).

[alex0801]

I also use the suggested delay, with success. No idea why this it needed, but it works.

[dan3460]

Thanks for the replays, answer to Bobaruni i know that the data has been written to eeprom because is read back to me when i have both commands on the program (write and then read).

I'm using Atmel Studio 7 and the programmer is USPASB, the parameters for the external tool i lifted from Avrdudess 2.4, there is an option to erase flash and EEPROM (flag -e) that is not selected. Here is the command that I'm using:

-c usbasp -pM328p -B 0.5 -v -v -v -v -U flash:w:"$(ProjectDir)Debug\$(TargetName).hex":a

.
I also used Ardudess to read EEPROM and i can see the data in the 10th position, so it is clear that the programmer is erasing the EEPROM.
I can probably work around the problem, but i still working on the program and i see many more uploads of code, every upload i loose the calibration data.

[dan3460]

As above, if your write and read is done by two different programs, with an upload in between, the Arduino IDE for example will erase the EEPROM during the upload, because it does not provide the -D option to avrdude (-D = Disable auto erase when uploading to flash).

I can add the -D flag to my command, would this solve the problem? Why do you need to erase the flash memory before you upload a new program?

[bobaruni]

Thanks for the replays, answer to Bobaruni i know that the data has been written to eeprom because is read back to me when i have both commands on the program (write and then read).

Ahh, OK, flip your EESAVE fuse bit, this bit determines if the EEPROM contents are preserved during chip erase.

There is an online fuse calc here:
http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p

[sleemanj]

As above, if your write and read is done by two different programs, with an upload in between, the Arduino IDE for example will erase the EEPROM during the upload, because it does not provide the -D option to avrdude (-D = Disable auto erase when uploading to flash).

I can add the -D flag to my command, would this solve the problem? Why do you need to erase the flash memory before you upload a new program?

-D stops the erase happening

An erase also erases EEPROM (unless EESAVE fuse is set) which is why you see the problem, so yes, adding -D should allow the EEPROM to persist

An erase is usually a good thing so that none of the old program remains in flash after you have uploaded a new program, in theory it shouldn't matter if you skip the erase, if your code has no bugs it shouldn't access those old bits of code left behind anyway, but in practice it might be a different story ;-) 

[bingo600]

AFAIk

eeprom_update is preferred over eeprom_write , as it can save a lot of eprom wear.

/Bingo

[dan3460]

Thanks every one, I did change the Fuse to prevent the eeprom erase. The -D option worked on the first upload of the program, but as it also prevents the flash to be erased. The second time that I programmed the chip the checking cycle of the programmer would report an error.
With regards of the update instead of the write function for the eeprom, that is something to keep in mind for future projects, on this one I do not envision changing the calibration parameters more than a handful of times during the life of the unit.

[Rick Law]

Thanks every one, I did change the Fuse to prevent the eeprom erase. The -D option worked on the first upload of the program, but as it also prevents the flash to be erased. The second time that I programmed the chip the checking cycle of the programmer would report an error.
With regards of the update instead of the write function for the eeprom, that is something to keep in mind for future projects, on this one I do not envision changing the calibration parameters more than a handful of times during the life of the unit.

Suggestion:

If you changed the fuse bit not the clear the EEPROM, you should also make sure that there is a signature for sanity check and EEPROM data initialization.

I had a hell of a time tracking an issue until I remember EEPROM has some old data.  So, at start of my EEPROM data is a signature byte.  If on program start which loads the EEPROM data into RAM, the signature byte is not right (or when certain TAC switch is held), I initialize the block of data with default values.