Hi,

I have a problem when using gcc-avr to write internal eeprom. I used
library calls eeprom_write_word, eeprom_write_byte, eeprom_write_block
to write the content. However, I found that when I reset the device by
powering off and on again, the eeprom reading is refill to be all 0xff.
Have I missed some procedures such as saving the content?

Thanks!

No. If you wrote to eeprom it's will be stay.
Did you use any supervisor? AtmelAVR have some problem with this.

No RTOS is used.

I have seen some information in the interent that there is a function
to check whether the internal eeprom is busy. So I suspect that the
eeprom is not ready at the beginning. Is this true?

My code is listed in the following. Firstly I write a byte 0 in
location eeprom_var2.

uint16_t  dummy        EEPROM_SECTION  = 0;       // avoid using lowest
addresses
uint8_t   eeprom_var1  EEPROM_SECTION  = 1;       // EEPROM address
0002
uint8_t   eeprom_var2  EEPROM_SECTION  = 2;       // EEPROM address
0003
uint16_t  eeprom_var3  EEPROM_SECTION  = 1027;    // low byte = 0003,
high = 0004
float     eeprom_var4  EEPROM_SECTION  = 1.3456;  // four byte float

int main(void)
{
uint8_t state1;

eeprom_write_byte(&eeprom_var2,0);	//and write value to EEPROM addr
0003
state1 = eeprom_read_byte(&eeprom_var2);	//read variable from EEPROM
addr 0002

//eeprom_read_block( &floatVar, &eeprom_var4, sizeof(eeprom_var4)
);

DDRA=state1;
for(;;){}//loop forever
}


Then the main() is changed to be

int main(void)
{
uint8_t state1;

//eeprom_write_byte(&eeprom_var2,0);	//and write value to EEPROM addr
0003
state1 = eeprom_read_byte(&eeprom_var2);	//read variable from EEPROM
addr 0002

//eeprom_read_block( &floatVar, &eeprom_var4, sizeof(eeprom_var4)
);

DDRA=state1;//<--------break here
for(;;){}//loop forever
}

and run again and set break point before looping. I see that state1 is
not zero but is 255.

Thanks!

My code is listed in the following. Firstly I write a byte 0 in
location eeprom_var2.

uint16_t  dummy        EEPROM_SECTION  = 0; // avoid using lowest
addresses
uint8_t   eeprom_var1  EEPROM_SECTION  = 1;// EEPROM address 0002
uint8_t   eeprom_var2  EEPROM_SECTION  = 2;// EEPROM address 0003

int main(void)
{
uint8_t state1;
eeprom_write_byte(&eeprom_var2,0);//and write value to EEPROM addr
0003
state1 = eeprom_read_byte(&eeprom_var2);//read variable from EEPROM
addr 0002
DDRA=state1;
for(;;){}//loop forever
}

Then the main() is changed to be

int main(void)
{
uint8_t state1;
state1 = eeprom_read_byte(&eeprom_var2);//read variable from EEPROM
addr 0002
DDRA=state1;//<--------break here
for(;;){}//loop forever
}

and run again and set break point before looping. I see that state1 is
not zero but is 255.

Thanks!

I am using atmega16 MCU.

I have a big discovery!

Today I browsed my old code projects and found that I have a project
using atmega16 DIP which operates normally to retrieve data from
eeprom. So I suspect that it is atmega16 TQFP version that has this
problem! I have checked 3 devices that the saving is vanished during
power reset!

Do anyone has similar problem?

And I found a very strange thing. I read the eeprom at the beginning of
the program. I used the debugger to stop the execution before the
execution of reading eeprom. Then I step over the reading procedure and
found the data is 0xff. I think this remove the suspection of unstable
voltage at startup as the eeprom reading procedure is now stop and then
go.

Thanks!

The problem is solved. This is a programming bug.

d...@yahoo.com.hk wrote:
> 
> The problem is solved. This is a programming bug.

So, after about 18 articles posted at 10 minute intervals without
quotes and one or two answers in spite of that, you think this is
adequate closure?  You don't think that people who read your
articles and at least gave it some thought deserve to know the
answer?  May your next problem receive equal attention.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson