> Od zdaje się 5-6 lat dostarczam producentowi
> maszyn sterownik oparty na Atmel AVR ATmega32.
> Czasem też robiłem coś na ATmega8.
> Dawno to już było, gdy tworzyłem oprogramowanie.
> Jednak pamiętam, ze działy sie wtedy dziwne rzeczy
> z danymi zapisanymi w pamięci EEPROM.
> Gdzieś wyczytałem, że pierwsza komórka EEPROM
> w ATmega8 czasem zmieniała swoją wartość.
> Mogło być coś w tym, bo pamiętam, że jedno
> z urządzeń, które miało jakiś bajt konfiguracyjny
> pod zerowym adresem EEPROM w ATmega8
> potrafiło podawać inną wartość tej komórki, niż
> początkowo zapisana.
> Z kolei w ATmega32 wykorzystywałem kilkadziesiąt
> komórek pamięci. Pamiętam, że urządzenie też
> potrafiło zmienić parametry.
> Z tego względu zrobiłem tak, że każda wartość
> była zapisywana nawet w 10 miejscach pamięci.
> Następnie odczytywałem je wszystkie, a jako
> wartość właściwą brałem tę, która występowała
> więcej niż w połowie komórek; komórki o błędnych
> wartościach nadpisywałem tą właściwą.
> Teraz mam potrzebę skorzystać z większej
> ilości pamięci EEPROM i przydałoby się zrezygnować
> z kopii parametrów.
> Jak obecnie wygląda sprawa z pamięcią EEPROM
> w ATmega? Czy można na niej polegać?

Nie mam większego praktycznego doświadczenia w tej kwestii... wiadomo,
że pamięć może ulec przekłamaniu, ale w normalnych warunkach raczej nie
"sama z siebie"... problem pojawia się w przypadku zapisu do pamięci i
zaniku zasilania.... Problem z zerową komórką też na tym polegał i jeśli
ten 1B nie stanowi dla Ciebie problemu, zostaw tę komórkę wolną (choć w
dokumentacji i erratach do nowszych układów już o tym błędzie nie
piszą). Poza tym - sam musisz przeanalizować co się stanie w czasie
zapisu do pamięci... musisz cały czas pamiętać, że zapisując daną
komórkę w czasie, w którym przyjdzie jakieś silne zakłócenie, przerwa w
zasilaniu itp, możesz zapisać w niej głupoty...

Poczytaj DataSheeta tak w ogóle... nie wiem, jak do ATmega32, ale
ostatnio czytałem na ten temat w dokumentacji ATmega168 i pisali po
prostu, że włączenie BOD lub zapewnienie czegoś podobnego dosyć
skutecznie chroni przed błędami...
Tak więc BOD + ochrona przed zakłóceniami i powinno jakoś działać ;)...

Drugie wyjście - możesz zrobić proste "księgowanie"... poświęcasz 4
bajty EEPROMa... przy każdym zapisie wpisujesz w te 4 bajty adres, nową
daną oraz CRC z 3 poprzednich bajtów. Następnie zapisujesz właściwą
komórkę i kasujesz "księgowanie" (choć to niekonieczne)... Po resecie
sprawdzasz taką "księgę". Jeśli CRC się nie zgadza, to znaczy, że dane w
niej są uszkodzone. To dobry znak. Skoro ten zapis się nie udał, to
zapewne nie uszkodziłeś właściwych danych, bo nie zacząłeś ich
zapisywać. Jeśli CRC się zgadza, sprawdzasz co jest we właściwych danych
i ewentualnie poprawiasz.... Powinno wystarczyć ;)...

No chyba, że Ty to w kosmos wysyłasz, to faktycznie będzie problem ;)...
Albo w warunkach silnego promieniowania elektromagnetycznego - w
takich sytuacjach dane mogą zostać uszkodzone "z zewnątrz" w dowolnej
chwili, nie tylko w czasie zapisu....

--
Pozdrawiam
Konop