AVR EEPROM writing

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;//

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;//

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.

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

Sorry, actually the answer involves my very careless mistake to save the setting. I miss to check it as other settings are saved but missed that. So I have not real it as it does not have learning value. Sorry!

Since there is obviously a language barrier, apology accepted. Now read my sig lines below and start posting replies with quotations.

--
"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

OK. I missed to used it as I changed to google group beta not long enough and initially cannot find the thread tree at the left hand side. Now I can pop the tree again and so I will reply at the right position in the future.