Utrata danych z EEPROM w ATmega8, 16 i 32 przyczyny i rozwiązania?

Thu Jul 12, 2007 12:15 pm   

Witam,

W różnych aplikacjach jakie robiłem na AVR (ATmega8, 16 i 32)
zdarzają się problemy z utratą danych zapisanych w EEPROM.
Jedno z urządzeń pracuje blisko transformatorów zgrzewalniczych
i w praktyce nie ma problemów... może ze 2 razy w ciągu kilku
lat zdarzyło się, że po wyłączeniu i włączeniu zasilania dane z EEPROM
zniknęły (ATmega32).
Inne urządzenie, nienarażone na zakłócenia miało cyklicznie
problemy z utratą danych -- średnio na 3 wyłączenia i włączenia, jedno
przynosiło utratę danych z EEPROM (ATmega8).
Robiłem też inny układ na ATmega32, w którym raz na jakieś 20 wyłączeń
i włączeń, dane w EEPROM potrafiły się zmienić.
W jednym z układów (ATmega16) był podobny problem -- wtedy
pomiędzy (piszę w C, WinAVR, standardowe funkcje odczytu i zapisu
do EEPROM) funkcjami zapisu i odczytu wstawiałem pętle z oczekiwaniem
na gotowość pamięci -- to pomogło, pomimo, że nie powinno, gdyż
funkcje odczytu i zapisu robią wewnętrznie to samo.
Byłbym wdzięczny za podpowiedzi, jakie mogą być przyczyny
takiego zachowania? Może jakieś spadki napięcia...
Czy jeżeli takie problemy są powszechne, to dotyczą one całej
pamięci, czy tylko niektórych komórek -- bo może wtedy można
zapisywać te same dane w np. 5 różnych miejscach, a podczas
wczytywania przyjmować za prawidłową tę wartość, która
występuje więcej razy w tych różnych miejsach.

Robbo

Thu Jul 12, 2007 12:23 pm   

Prawdopodobnie trzeba ustawić fusebity BODLEVEL.

Paweł

Thu Jul 12, 2007 12:27 pm   

Robbo denied rebel lies:


Masz włączone Brown-out detection?
Jeszcze nie słyszałem żeby u nas były problemy z danymi w eepromie - a
trochę tego jest.

--
MoonWolf
Sygnaturka poszła tędy -->

Thu Jul 12, 2007 12:40 pm   

Użytkownik "Robbo" <przykre@ale.nie.mam> napisał w wiadomości
news:f752h4$dtp$1@atlantis.news.tpi.pl...


tak przy Atmega8
Piotr

Thu Jul 12, 2007 12:45 pm   

Może nie tak jest z twoją procedurą do zapisu EEPROM.... Bo jak
przypuszczam powielasz ją w swoich projektach.

Thu Jul 12, 2007 1:26 pm   

Robbo napisał(a):


Sa to dość powszechnie znane problemy w Atmelach, przynajmniej tych
starszych. Daje się je obejść sztuczkami, ale najlepiej używać produktów
lepszych firm.

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Thu Jul 12, 2007 1:27 pm   

On Thu, 12 Jul 2007 14:26:21 +0200, A. Grodecki wrote:

....a każdy pijak to złodziej :)

Pzdr.
Marcin Stanisz

--
"A lie will go round the world before the truth has got its boots on"
Terry Pratchett, "Truth"

Thu Jul 12, 2007 1:41 pm   

Marcin Stanisz napisał(a):

Pijaków bym w to nie mieszał A od niepoważnych (w sensie strategii)
producentów lepiej trzymać się z daleka. Nigdy nie wiadomo z czym nowym
wyskoczą, co okaże się "po fakcie".

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Thu Jul 12, 2007 1:47 pm   

On Thu, 12 Jul 2007 14:41:16 +0200, A. Grodecki wrote:


Ależ. Nie powtarzaj "legend urbana" ;)

Sam jestem autorem kilku przemysłowych sterowników na AVR-kach. W żadnym
nie miałem problemów z pamięcią EEPROM (z której notabene korzystałem).

Co do strategii producenta się nie wypowiadam, bo nie o tym mówimy w tym
wątku.

Pozdrawiam
Marcin Stanisz

--
"A lie will go round the world before the truth has got its boots on"
Terry Pratchett, "Truth"

Thu Jul 12, 2007 1:57 pm   

Użytkownik "Piotr Pitucha" <piotrpitucha@poczta.onet.pl> napisał w
wiadomości news:f753t4$j42$1@atlantis.news.tpi.pl...

Swego czasu zauważyłem, że dobrze jest "wycelować" rejstrem EEAR po każdej
procedurze zapisu / odczytu eeproma w nieużywany fragment tejże pamięci.
Eeprom potrafił zmienić zawartość, gdy w pobliżu procka następowało
wyładowanie o napięciu ~80 kV. I jak dotąd problem ten się nie powtórzył.

Pzdr,
Maciek Wywrocki

Thu Jul 12, 2007 2:05 pm   

Marcin Stanisz napisał(a):


I tak, i nie. Wprowadzenie do sprzedaży produktu(-ów) ze zidentyfikowaną
wadą (niech będzie - niedopracowaniem) do czego miałbym zaliczyć?
Albo wstrzymanie produkcji popularnego elementu na bliżej nieokreślony
czas, bo duży klient się trafił?

--

Pozdrawiam,

A. Grodecki

"Wszystkie zwierzęta sa równe.
Ale te, które mają futerko w trzykolorowe pasy, są równiejsze."

Thu Jul 12, 2007 2:23 pm   

Ustawiam i potem w programie dodatkowo obsługuję
start po wykryciu BOD, że tak się wyrażę :)

Robbo

Thu Jul 12, 2007 2:28 pm   

Korzystam ze standardowo dostarczenej z WinAVR biblioteki
i tamtejszych procedur.

Jeszcze mi do głowy przyszły takie rzeczy jak np. to, że na ogół
obsługuję w programach przerwania sprzętowe i czasem zegary.
Może jak podczas zapisu (choć nie powinno mieć to teoretycznie
miejsca, gdyż maszyna nie pracuje podczas odczytu/zapisu do/z EEPROM)
bądź odczytu do/z pamięci program skarcze do obsługi przerwania
i stąd problemy. Ale to by były jakieś rzadkie sytuacje -- np. encoder
da impuls i uruchomi się procedura obsługi licznika drogi... maszyna
niby stoi, ale może np. miało miejsce jakieś drgnięcie mechaniki.
Z drugiej strony, odczytu/zapisu dokonuję na początku programu,
zanim zezwolę na przerwania.
Sam nie wiem.

Robbo

Thu Jul 12, 2007 2:42 pm   

Też słyszałem o problemie z adresem 0. I uważam, że to szczera prawda.
W moim urządzeniu zrobionym na ATmega8 w pamięci trzymałem jeden
jedyny bajt, właśnie pod adresem 0 i właśnie z tym urządzeniem było
najwięcej problemów -- niezmiernie często ten bajt był tracony po
wyłączeniu i włączeniu zasilania.
Na innych wersjach ATmega miałem więcej danych, ale także
pod adresem 0 coś trzymałem i choć problemy były, to nie tak częste,
jak na ATmega8.

Robbo

Thu Jul 12, 2007 4:38 pm   

Użytkownik "Robbo":

A masz projekty, w ktorych nie korzystasz z tej pamieci ? Jesli tak to
zapisz eeprom roznymi wartosciami i po dluzszym czasie sprawdz czy zawartosc
pamieci sie zmienila. Jesli nie to wniosek prosty - Atmel ok, a ty zle
zapisujesz.

Heliogabal