인터넷 검색을 하여 비슷한 증상을 경험한 사례가 있는지 알아 보았다.
Why AVR's EEPROM will be erased randomly?
Wed, 02/27/2008 - 01:29 — allankliu
Some AVR developers reported that the AVR's EEPROM will be erased randomly. And these poor people are driven crazy because they have no clue about the real cause for it. Is AVR micro's embedded EEPROM not stable at all? Well, there are not perfect products in the world. But I would rather to say the real cause might be yourself.
Do you have any idea what AVR is doing during reset? Have you even done some testing for its reset behavior? AVR is a very fast microcontroller, cause it is an RISC micro. (Here I dislike the word of RISC, since RISC is a real microprocessor concept which has many related infrastructure in compilers, which is not suitable for microcontroller. I like to say AVR is a RISC like microcontroller, simple and fast.) Speed is its advantage, but sometimes it will cause a lot of issues if designer is not ready for it. Please read the AVR specification, you will find out that AVR is in a unstable RUNNING mode before valid reset is generated. Yes, it is RUNNING! During the process of downloading (actually uploading) program to AVR, between WRITE and VERIFY modes, the reset will be released, then pulled down in VERIFY mode. During this very short duration of reset pin released, the program is RUNNING randomly. I have a LCD project using AVR. During downloading, the LCD will show some content before VERIFY mode. Because this period, most of the ram data is random , so incorrect content is displayed anyway. When system drops into verify, the LCD is frozen.
So if your hardware has not enough precaution for reset circuit, during the power on reset, before valid reset is generated, AVR is randomly running. For example, writing EEPROM, while running is out of control, the data written into AVR is also random as well as the EEPROM address, since most of the AVR registers are zero during this period. So the so-called ZERO address is not stable is spread. If your program runs other routines before drops into EEPROM routines, who knows it wrote what in where? So it is unstable if you have no idea about it. So after your power on the system, the data is changed by your own program. Is that clear?
Solution is:
You can avoid using zero address of EEPROM for data storage, not a complete solution (Even IAR complier will use second EEPROM as default);
Using CRC for EEPROM data integrity checking;
Enable BOD of AVR, set 4.2V for 5V system, set 2.7V for 3.3V system, but some old AVR has not BOD inside;
Using external Reset chip such as DS1233, KIA7045 or IMP809/810.
네이버에서 검색해 보니 내부EEPROM에 문제가 있다는 글을 쉽게 찾을 수 있었다.
위에 해결책 4가지를 보면,
1. 내부EEPROM의 0번지를 피해서 쓰라.
2. CRC를 사용해 데이터 무결성을 체크하라.
3. 브라운 아웃 디텍터(BOD)를 활성화하여 전원전압 상승시간에는 확실히 리셋상태를 유지하라.
4. 외부 리셋IC를 사용하라.
나의 경우는 ATmega8A에서 Fuse BODEN Enable BOD전압 4.0V로 하여 테스트 진행중이다.