Jak to jest z bezpieczeństwem danych w EEPROM w ATmega?

Witam,

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ć?

Z góry dziękuję za pomoc.

Robbo

Reply to
Robbo
Loading thread data ...

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

Reply to
Konop

Niby tu problemów z zasilaniem nie mam, ale kto wie, może jakieś zakłócenia (to jest środowisko przemysłowe; występuje podczas produkcji w miarę silne pole elektromagnetyczne

-- przy czym zapis do pamięci EEPROM ma miejsce, gdy produkcja stoi). Jeżeli jest tak, jak piszesz, że przekłamanie może nastąpić (jedynie) podczas zapisu, to byłaby to dobra wiadomość dla mnie -- po prostu po zapisie sprawdzałbym, co się zapisało i ewentualnie poprawiał źle zapisane komórki. Muszę to przetestować.

Robbo.

Reply to
Robbo

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.