[ATMega16/32] - Cyklicznie padające EEPROMy w ATMegach

Witam serdecznie,

zajmuję się profesjonalnie pisaniem aplikacji na AVRy i dziwna sprawa, którą zauważyłem - po powiedzmy 50 (+-100) zaprogramowaniach EEPROMu, EEPROM pada (tzn. weryfikacja się nie powodzi). Dzieje się to cyklicznie w najprzeróżniejszych układach, które programuję. W tej chwili mam już trzy padnięte w ten sposób ATMegi (16-stki i 32-ójki), które działają wyśmienicie, Flash daje się zaprogramować, fusebity również, ale nie EEPROM.

Zasilanie zawsze mam stabilne, zawsze ściągam z siebie ładunek przed dotknięciem kości, zawsze ustawiam fusebit EESAVE - mimo iż dla EEPROMu 100 tys. zapisów to normalka wg. dokumentacji (a jeden z użytkowników elektrody doszedł nawet do 7 mln zapisów!). Oczywiście nigdzie nie zapisuje do EEPROMu w pętli nieskończonej (w zasadzie to nigdzie nie zapisuje wewnątrz programu, jedynie odczytuje) ani nie robię innych głupstw. EEPROMy padają mi w ATMEGach cyklicznie. Ale nie tylko mnie. Znajomemu dzieje się dokładnie to samo.

Jaka może być tego przyczyna? Czy macie podobne problemy? Czy da się jakoś przedłużyć żywotność? Zaznaczam, że ATMegi pochodzą z różnych serii, tak więc nie jest to wina jednej serii.

Używam: JTAG ICE i STK500

elektronik_hobbysta wrote:

zajmuję się profesjonalnie pisaniem aplikacji na AVRy

W takim razie Ty powinieneś odpowiadać na pytania

elektronik_hobbysta wrote:

po powiedzmy 50 (+-100) zaprogramowaniach EEPROMu, EEPROM pada (tzn. weryfikacja się nie powodzi). Dzieje się to cyklicznie w najprzeróżniejszych układach, które programuję. W tej chwili mam już trzy padnięte w ten sposób ATMegi (16-stki i 32-ójki), które działają wyśmienicie, Flash daje się zaprogramować, fusebity również, ale nie EEPROM.

Ustaw w programie inkrementację zmiennej, w miejscu gdzie dokonywany jest zapis do EEPROM-u. Sprawdzisz łatwo ile tych zapisów jest faktycznie, bo na pewno więcej niż te "50 (+-100)".

Fusebit EESAVE powoduje tylko, że EEPROM nie jest kasowany w czasie wykonywania polecenia chip erase. Dla większości programów do programowania AVR jego stan jest obojętny - jeśli widzą plik eep to i tak użyją go do programowania, chyba, że dodatkowo odznaczysz opcję programowania pamięci EEPROM. Napisz coś więcej o tych błędach - kiedy występują? Wyrzuca je programator (jeśli tak to jakie?), czy dostęp i zapis do takiego EEPROM z poziomu aplikacji jest prawidłowy?

Witam ponownie, dziękuję za odpowiedzi.

@megao Sprawdziłem z ciekawości dzisiaj zapisywanie EEPROMu z poziomu programu dla AVRa (z racji, że cierpię na chroniczny brak czasu zrobiłem to dopiero teraz). EEPROM działa poprawnie (tj. zapisana liczba zostaje w EEPROMie). Przykładowo, wiem, że pierwszy bajt (często sporny bajt o adresie 0 z którym sporadycznie były kiedyś problemy) u mnie wynosi 12 (zapisałem do niego liczbę 12). Sprawdziłem, czy ta komórka rzeczywiście wynosi 12 (instrukcja warunkowa i dioda . Wynosi właśnie tyle.

Okno programowania w AVRStudio po nieudanej weryfikacji:


Odczyt obecnej pamięci EEPROM za pomocą programatora (z wpisaną liczbą 12 w bajt nr 0) następuje prawidłowo (załącznik w formacie Intel HEX). Udaje się odczytać całą pamięć EEPROM w sposób prawidłowy i powtarzalny.

Natomiast zapisać do EEPROM - jak się okazuje - udaje się tylko z wnętrza układu.
Co ciekawe oba programatory (STK500 i JTAG) nie chcą mi zapisać EEPROMu. Zrozumiałbym gdyby to był jeden - pomyślałbym, że szlag go trafił, ale dwa? Poza tym przypominam, że zapisywanie EEPROMu pada dopiero po jakimś czasie, co świadczy o tym, że przynajmniej początkowo programator dogaduje się z układem, po kilku tygodniach coś się jednak zmienia.



@tmf - wiem co powoduje EESAVE i dlatego właśnie go ustawiam. Zauważ, że okienko do programowania w AVR Studio automatycznie czyści chip (opcja "Erase device before flash programming") przy każdym programowaniu flash. Chcę przez to powiedzieć, że nie wgrywam EEPROMu przy każdym programowaniu Flash. Wgrywam go na początku, no i kilkukrotnie potem, gdy zmieniam dane.

elektronik_hobbysta
Większość ludzi zapisuje EEPROM właśnie z programu.
W kodzie programu
Wystarczy sprawdzić, czy jakaś tam komórka w EEPROMIE np. 5 jest niezaprogramowana(z tego co pamiętam wynosi FF) i jeśli nie jest to wgrać EEPROM i zmienić jej wartość np. na 1

Tak, czy siak dziwne, że nie możesz zaprogramować EEPROM przez programator;/

@xamrex, zupełnie nie rozumiem jak Twoja wypowiedź ma się do przedstawianego problemu i wcale większość ludzi nie zapisuje eeprom z poziomu programu.

Co do sprawy, to rzeczywiście bardzo dziwne, mam jeszcze pomysł, żeby sprawdzić całość na programatorze równoległym HVPP (widzę, że Kolega tez z Królewskiego Miasta Krakowa, więc jkbc zapraszam do kontaktu na PW).

Mam w szufladzie trochę m8, więc jak będę miał trochę wolnego czasu to je potorturuję w celach badawczych.

elektronik_hobbysta wrote:

@tmf - wiem co powoduje EESAVE i dlatego właśnie go ustawiam. Zauważ, że okienko do programowania w AVR Studio automatycznie czyści chip (opcja "Erase device before flash programming") przy każdym programowaniu flash. Chcę przez to powiedzieć, że nie wgrywam EEPROMu przy każdym programowaniu Flash. Wgrywam go na początku, no i kilkukrotnie potem, gdy zmieniam dane.

To dobrze, że wiesz co robi EESAVE, dobrze też wiedzieć, że jeśli nie odznaczysz w AS programowania pamięci EEPROM to programujesz ją przy każdej okazji i EESAVE nie ma tu nic do rzeczy.
Natomiast twoje problemy być może związane są niepewnymi połączeniami programatora z MCU. Podczas programowania masz zawsze błąd tej samej komórki, czy to się zmienia? Jakiego JTAGa używasz? Próbowałeś zmieniać częstotliwość taktowania interfejsu? Jak długa jest taśma łącząca programator z układem?

No właśnie, jakie to konkretnie modele programatorów (oryginały czy klony?)

Dziękuję Wam, @tmf i @piotrva i @xamrex za odpowiedzi. Już odpowiadam.

@tmf Nie chodzi o ustawienia. Po prostu przy każdym programowaniu AVRPog wykonuje Chip Erase. Gdy EESAVE byłoby odznaczone, musiałbym za każdym razem zapisywać jeszcze (prócz Flasha) pamięć EEPROM (właśnie przez to, że przed programowaniem następuje Chip Erase). Nie chodzi o ustawienia automatycznego programowania, bo z niego nie korzystam (ręcznie klikam na przycisk Program w sekcji Flash w okienku AVRProg). Podejrzewam, że myślimy o tym samym, więc dajmy temu spokój i załóżmy, że wiem o co chodzi Za każdym razem programuję jedynie Flash, tylko czasami EEPROM.

@piotrva Oba programatory to klony. Połączenia na płytce układu możemy wykluczyć, bo EEPROMU nie mogę zaprogramować zarówno w konstruowanym teraz układzie, jak i na swojej płycie testowej.
Przy programowaniu EEPROM błąd występuje już w komórce 0x00. Gdy z ciekawości zapisałem prawidłową wartość komórki 0x00 EEPROMU z wnętrza układu, to przy kolejnym programowaniu EEPROM miałem błąd w 0x01 (która była nieprawidłowa) - logiczne (tą sytuację widać na screenie). Zachowanie to jest zawsze identyczne.
Częstotliwość JTAGA - szczerze przyznam, że nawet nie wiem jaka jest (nie mogę jej zmienić, nie mam w nią wglądu), natomiast częstotliwość ISP to ~44kHz (na niższych częstotliwościach dzieje się to samo). Kable połączeniowe mają długość ok. 15cm (programowałem kiedyś na 2 metrowych i nie było problemu, ale to jako ciekawostka

Przy czym, rąbnięte kable powodowałyby według mnie również błędy w pamięci Flash (która jest znacznie większa od EEPROM, przez co większe jest prawdopodobieństwo błędu w transmisji). Jeszcze mi się nie zdarzył błąd w pamięci Flash (w zdrowym kontrolerze). Poza tym - wiecie - wsadzam nowy układ i EEPROM mogę zapisywać od razu, bezbłędnie.

Ogólnie dzięki Wam (przez to, że przetestowałem zapis z wnętrza programu) sytuacja wygląda na taką, jakby był uszkodzony układ w AVRze odpowiadający za część programującą EEPROM z zewnątrz (z programatora). Co ciekawe, zarówno interfejs SPI jak i JTAG ma bezpośredni dostęp do pamięci Flash, ale aby zapisać do EEPROMu, musi wysłać dane na główną magistralę AVRa. (Bardzo) Teoretycznie, mogło by coś być nie tak z komunikacja interfejsów programowania z szyną danych, ale tak naprawdę... sam nie wiem co. To bardziej wróżenie z fusów.

Dodano po 4 [minuty]:

Nie mam już pomysłu. Jutro znowu muszę lecieć po nowe AVRy do sklepu. Wiem, że po kilku tygodniach padną.

A próbowałeś inne oprócz M16 i M32? Było tak samo? A jeśli odznaczysz EESAVE i wykonasz chip erase, tak, żeby cały EEPROM miał 0xFF i zaprogramujesz to też wyskakuje błąd? W jaki sposób jest zasilany procesor i taktowany? Te błędy, które wyskakują to zawsze błędy typu odczyt 0, w miejsce 1, czy zdarza się także odczyt 1 w miejsce zera? To pierwsze wskazywałoby na jakiś dziwny problem ze zużywaniem się EEPROM, co wydłuża operację kasowania. Programator powinien mieć odpowiednio długi czas oczekiwania na koniec tej operacji (albo działać przez pooling), ale jeśli to jakiś klon to kto wie, może się rozjeżdża. Z drugiej strony miałem kiedyś podobny problem, jak pisałem własną obsługę programową ISP, timingi były na styk i niewielkie pojemności linii powodowały rozjeżdżanie się SCK i MISO, w efekcie, sporadycznie czytałem poprzedni bit. Także spróbowałbym jeszcze na innym programatorze i z innym programem do programowania. W ostateczności, jeśli masz taki uszkodzony egzemplarz w DIPie to prześlij mi, w wolnej chwili sprawdzę jak się u mnie zachowa. Można też wysłać zapytanie do Atmela podając nr serii, jeśli wiedzą o jakimś problemie to ci napiszą.

Właśnie, jeśli do DIP to możesz mi tez podrzucić taki egzemplarz. Wrzucę go w wolnej chwili na fabryczny Atmel'owski HVPP, JTAG i ISP, a jakby co jeszcze można poszperać analizatorkiem.

Wiesz @tmf, wyczyściłem bit EESAVE, wykonałem Chip Erase, zaprogramowałem EEPROM, wszystkie ATMegi przyjęły. Trochę mi głupio, że to połowiczne rozwiązanie okazało się tak banalne - mam tylko jedno pytanie: Czy ktoś tu coś rozumie?

Teraz jest sytuacja taka: na wszystkich tych problematycznych ATMegach (na nowych jest OK) można teraz zaprogramować EEPROM pod warunkiem wyczyszczenia EESAVE i wykonania Chip Erase przed zapisem EEPROMU. Potem programujemy EEPROM, EEPROM zostaje zaprogramowany poprawnie - ale gdy chcemy zaprogramować go drugi raz (bez wykonania Chip Erase) następuje błąd weryfikacji - EEPROM nie zostaje zapisany.

Innymi słowy, nie mogę teraz wymienić samego EEPROMu bez kasowania całego układu.

Tak więc to połowiczne rozwiązanie zdaje się działać, jednak co jest przyczyną tak dziwnego zachowywania się tych trzech ATMeg - nie wiem.
Dzięki @tmf, dzięki @piotrva za doprowadzenie mnie do rozwiązania. Klikam Wam "pomógł".

Hmm, EESAVE powoduje, ze przy komendzie CHIP EREASE nie jest wykonywane kasowanie EEPROM. Ale teraz czy przy zapisie komórki komendą Write EEPROM Memory dana komórka jest kasowana I czy ewentualne timingi są zachowane?
---
Jak widzimy tu: http://www.atmel.com/images/doc2486.pdf strona 232, zapis do eeprom musi mieć określone timingi. Jeśli programator je miesza, to może być tak, że nowiutkie komórki eeprom kasują się szybciej, a potem jak się "dotrą" to ich kasowanie przebiega ściśle zgodnie z timingiem i programator czegoś nie łapie.
---
Mój ostatni problem z układami RFM12B - też jedno zbocze miało przesunięcie względem drugiego rzędu setek nanosekund, a powodowało niemalże całkowity brak komunikacji z układem.
---
Swoją drogą kiedyś miałem (w sumie nigdy nie wyjaśnioną tajemnicę) problem z bootloaderem Arduino - w pewnych sytuacjach (gdy sporą część flasha zajmowała grafika na LCD) bootloader nie potrafił poradzić sobie z wykasowaniem pewnych stron pamięci flash. Ale to pewnie jego wina programowa, bo normalnie przez ISP wsad wgrywał się i weryfikował poprawnie.
---
Tak czy siak sprawa mnie zainteresowała i z miłą chęcią bym taki jeden AVR zbadał na fabrycznym programatorze Atmela.

piotrva wrote:

Hmm, EESAVE powoduje, ze przy komendzie CHIP EREASE nie jest wykonywane kasowanie EEPROM. Ale teraz czy przy zapisie komórki komendą Write EEPROM Memory dana komórka jest kasowana I czy ewentualne timingi są zachowane?

Według mnie, jak najbardziej tak, ponieważ w przeciwnym wypadku ta sama sytuacja występowałaby w nowych ATMegach. To już nawet chyba nie kwestia komendy, ale organizacji zapisu do EEPROM w ATMedze.

piotrva wrote:

Tak czy siak sprawa mnie zainteresowała i z miłą chęcią bym taki jeden AVR zbadał na fabrycznym programatorze Atmela.

Możemy się umówić na któryś dzień (ale to już przez PW).

Dziękuję Wam serdecznie za wszystko!

P.S. Ciekawostki z dziwnym działaniem układów - bardzo ciekawe. Ja też miałem różne przygody - ostatnio z układem ENC28j60 na którym niestety oparłem sieć w przemysłowym, wielkim urządzeniu. Zawieszało się to to po paru daniach ciągłej, ostrej pracy (bardzo dużo pakietów przechodziło). Program w ATMedze działał OK, ENC zawieszał się tak, że traciłem z nim jakąkolwiek komunikację (nawet softwarowy reset nie działał). Do tej pory zagadka jest nierozwiązana do końca (zastosowałem brzydki workaround w postaci wykorzystania sprzętowego pinu resetującego ENCa). Podejrzewam zakłócenia napięcia (nie do końca zawsze można wszystko odfiltrować) - jest na nie bardzo czuły (sprawdzałem). Oczywiście w domu wszystko chodziło mi doskonale, bez zawieszki, pod ciągłym kilkudniowym floodingiem. Złośliwość rzeczy martwych.

Ja bym podejrzewał raczej błąd programu programatora. Sprawdź czy np. AVRDude ma taki sam problem z programowaniem EEPROM. Najpewniej podczas programowania oprogramowanie nie czeka na gotowość EEPROM przez pooling, tylko ma na sztywno wpisany jakiś czas. Typ błędu który występuje (zera zamiast jedynek) wskazuje na kłopot z kasowaniem pamięci. Jeśli taki sam problem występuje na oryginalnym programatorze to wskazywałoby to na błąd AS. Warto to sprawdzić i zgłosić Atmelowi.
Co do ENC - mam wrażenie, że to chip dla amatorów, niestety powszechne są narzekania na ten chip, lubi się zwieszać szczególnie jeśli jest duży ruch (duża liczba pakietów).

Jest dosyć prawdopodobne, że możesz mieć rację @tmf. Umówię się z kolegą @piotrva na testy tych układów Atmel'owskim programatorem, jeśli nie ruszą mogę opisać sprawę Atmelowi w miarę wolnego czasu. Również tutaj dam znać jak poszło.

Co do ENC, mam takie samo odczucie, mimo, że nie wykluczam, że mogłem gdzieś się pomylić (na bibliotece enc28j60.c działo się to samo). Jednak mimo wszystko, cokolwiek bym nie zrobił, nie powinien się aż tak zawieszać, aby następowała utrata komunikacji. O ENC bym pogadał, bo spędziłem nad pracą z nim z pół roku. Ale nie chcę schodzić z tematu.

Hmm, co do żywotności samych eeprom, testy Kol. Manekinen: https://www.elektroda.pl/rtvforum/topic1568124.html

Cóż, jestem lekko zaskoczony tą sytuacją z EEPROM, bo przygotowałem sobie plik, który wgrywa do pamięci same 0xFF. Pierwsze 225 komórek nie zostało zapisanych poprawnie (były tam śmieci).
Następnie wgrywamy do pamięci 0x00 - tym razem zapis i weryfikacja poprawne.
Potem wgrywam znów same 0xFF i tu największe zaskoczenie - tym razem cała pamięć ma wartość 0x00.
Po chip erease 0xff zapisuje się poprawnie, 0x00 też, potem znów 0xFF - i znowu cała pamięć 0x00.
Czyli zupełnie interfejs programowania eeprom nie kasuje pamięci w trybie globalnym.
Wszystkie testy przeprowadzałem w trybie HVPP na fabrycznym AVRDragon z dostarczonym procesorem ATMega32A.
Co ciekawe te same testy przeprowadziłem ze swoim ATMega644p i ku swojemu zaskoczeniu - efekt ten sam. Inna atmega32A - to samo.

Zaczynam się więc zastanawiać czy to wada, czy ten typ tak ma.
Czytając sekcje dot. programowania procesora nigdzie nie ma określonej komendy kasującej całą pamięć eeprom, pytanie tylko jak powinna zachowywać się komenda zapisująca pojedynczy bajt do tej pamięci z poziomu interfejsu programowania (bo z poziomu programu na pewno pierwsze komórka jest kasowana, a potem dopiero zapisywana).

Może na początku po prostu do eeporm wgrywałeś akurat takie dane, które tylko kasowały jedynki (patrząc bitowo na komórki), a potem jak się zaczęło wgrywanie takich, które miałyby ustawiać jedynki to były problemy?

Nie wiem, w każdym razie na pewno przyczyna nie leży w programatorze, ale w tych układach.
---
EDIT: Co ciekawe przy procesorach atmega8 ten problem nie występuje...
---
EDIT2: Podpiąłem otrzymany układ pod ISP dragona i ku mojemu zdziwieniu problem nie występuje... I to niezależnie od stanu bitu EESAVE...
----
EDIT3: Spowrotem pod HVPP - i znów mamy ten sam problem
----
Co ciekawe w trybie ISP zapis eeprom przebiega stopniowo (zgodnie z dokumentacją wnioskuję, że wg. stron). Czyli zapisuje trochę, czeka, zapisuje kolejne trochę, czeka. A w trybie HVPP wzium i już. Sytuacja jest bardzo dziwna, bo z programowaniem w jednym trybie nie radzi sobie nawet fabryczny układ atmela.
----
Dotychczasowe testy prowadzone na AVRStudio 4.18, po upgrade firmware do wersji współpracującej z Atmel Studio 6.0 w trybie ISP problem zaczyna ponownie występować, dokładnie tak jak to opisał Autor wątku...

Tutaj muszę najpierw dopowiedzieć, że spotkałem się z kolegą @piotrva (bardzo sympatyczny młody geniusz) i przekazałem jedną z dziwnie zachowujących się ATMeg do testów - dlatego teraz testy wychodzą spod jego pióra.

W piątek kupiłem nową ATMegę32 (na Wrocławskiej) i już chciałem napisać, że oczywiście wszystko jest OK (bo zaprogramowałem od razu EEPROM swoim wsadem - przyjął, zweryfikował) - ale pomyślałem, że aby być rzetelnym - wykonam kilka testów. Wygenerowałem EEPROM składający się z 256 wartości 0xFE - spróbowałem zaprogramować (bez wykonania ChipErase) - już nie przyjął (nowiutki układ!). Tak wiec z tego by wynikało, że zaraz po kupnie ATMega przyjęła EEPROM tylko dlatego, że fabrycznie zostało na niej wykonane ChipErase.


Wykonałem więc ChipErase, zaprogramowałem EEPROM wsadem z 256 wartościami 0xFE. Weryfikacja się powiodła.
Wygenerowałem następnie wsad z 256 wartościami 0x01 i przy próbie zapisania EEPROMu - błąd weryfikacji:
"WARNING: EEPROM address 0x0000 is 0x00 (should be 0x01).. FAILED!"
Proszę zwrócić uwagę na to, że nie wykonywałem ChipErase, a więc zawartość komórki 0x0000 powinna być 0xFE, a jest 0x00. Z tego można lekko wywnioskować, że ATMega programując swój EEPROM, najpierw kasuje komórkę (nie było to jasne w poprzednich postach), ale potem coś się dzieje, że nie jest ona zapisywana nową wartością.
Cały czas podkreślam, że jest to układ świeżo przyniesiony ze sklepu, EESAVE wyłączone.

Aby potwierdzić, że to samo dzieje się nie tylko w pierwszym bajcie, ale również w bajcie o adresie 0x00FF, zapisałem pamięć EEPROM 256 wartościami 0x01 (a więc ChipErase i programowanie EEPROMU), a następnie wygenerowałem EEPROM z 255 wartościami 0x01 i jedną wartością 0xFE (pod adresem 0x00FF) i spróbowałem zapisać go w ATMedze bez wykonywania ChipErase:

"WARNING: EEPROM address 0x00FF is 0x00 (should be 0xFE).. FAILED!"

A więc stało się to samo.


Aby sprawdzić, sytuację opisaną przez kol. @piotrva (którą też na początku podejrzewałem):

piotrva wrote:

Może na początku po prostu do eeporm wgrywałeś akurat takie dane, które tylko kasowały jedynki (patrząc bitowo na komórki), a potem jak się zaczęło wgrywanie takich, które miałyby ustawiać jedynki to były problemy?

... wygenerowałem EEPROM z 256 wartościami 0xFE, ChipErase, zapis. Następnie wygenerowałem EEPROM z 255 wartościami 0xFE i jedną wartością 0xFF, zapis - przy próbie weryfikacji błąd:
"WARNING: EEPROM address 0x00FF is 0xFE (should be 0xFF).. FAILED!"
Proszę jednak zwrócić uwagę, że teraz wartość komórki nie uległa skasowaniu! (w poprzednich przykładach wynosiła zawsze 0x00).

Pomyślałem sobie wtedy "o ty gagatku, potrzebowałbym ustalić kiedy kasujesz pamięć, a kiedy nie". Wygenerowałem więc EEPROM z 255 wartościami 0xFE i jedną wartością 0xFD (sprytnie tym razem stała się rzecz ciekawa (przypominam, że EEPROM ma w tym momencie, przed zaprogramowaniem, 256 wartości 0xFE) po próbie zaprogramowania EEPROMU:
"WARNING: EEPROM address 0x00FF is 0xFC (should be 0xFD).. FAILED!"
Tak więc jak widać zera się na siebie nałożyły.

To co obserwujesz akurat jest zupełnie normalne. Zauważ, że programowanie EEPROM polega na programowaniu wyłącznie bitów o wartości 0. Bity o wartości 1 ne są programowane, bo takie one są po operacji kasowania. Czyli jeśli masz w komórce 0xFF, a wpiszesz 0xFE to będzie ok, jeśli do komórki 0xFE wpiszesz 0x01 to otrzymasz 0x00 - dlatego, że najmłodszy bit, który chcesz ustawić był już wyzerowany, a pozostałe bity z 0x01 mają już zera, więc zapis spowoduje że otrzymasz w wyniku 0x00. Czyli tak jak jest u ciebie.
Też sobie to w międzyczasie testowałem i w XMEGA jest dokładnie tak samo. Także wygląda, że przy ustawieniu EESAVE niemożliwy jest zapis nowych wartości do EEPROM z poziomu programatora. Pytanie brzmi, czy to błąd oprogramowania programatora, które nie wykrywa takiej sytuacji i przyjmuje, że EEPROM jest skasowany po EESAVE? Niekoniecznie tak musi być, bo jak się przejrzy listę poleceń SPI dla ATMega to okazuje się, że jest Write EEPROM Memory, ale nie ma Erase EEPROM Page. Stąd też jeśli programator zapisuje stronami (a tak jest), to nie ma możliwości skasowania EEPROM. Aby to zadziałało należałoby zapisywać EEPROM bajtami, co mniej więcej nawet 32 razy wydłuży programowanie tej pamięci. Przypuszczam więc, że obserwowany efekt jest kompromisem pomiędzy czasem programowania, a częstością użycia EESAVE.

tmf wrote:

To co obserwujesz akurat jest zupełnie normalne. Zauważ, że programowanie EEPROM polega na programowaniu wyłącznie bitów o wartości 0. Bity o wartości 1 ne są programowane, bo takie one są po operacji kasowania. Czyli jeśli masz w komórce 0xFF, a wpiszesz 0xFE to będzie ok, jeśli do komórki 0xFE wpiszesz 0x01 to otrzymasz 0x00 - dlatego, że najmłodszy bit, który chcesz ustawić był już wyzerowany, a pozostałe bity z 0x01 mają już zera, więc zapis spowoduje że otrzymasz w wyniku 0x00.

Tak, na to wychodzi @tmf - masz rację. Logiczne wnioski. Jednak sam zapis bajtów w ATMegach powinien być już sprzętowo poprzedzony wykasowaniem komórki (czyli ustawieniem bitów na 1) przed jej zapisem. Ciekawe jest dlaczego tak się nie dzieje (mimo iż przy zapisie z wnętrza programu tak się dzieje). Skutkuje to opisywanymi błędami w zapisie. Było nie było pamięć EEPROM, w przeciwieństwie do Flash jest zapisywana komórkami, a nie stronami (niezależnie od tego jak to jest zorganizowane wyżej, w protokole czy interfejsie) i o ile w przypadku Flasha bym zrozumiał to, że nie da się zmienić pojedynczych bajtów bez kasowania całej strony, o tyle w przypadku EEPROM wydaje się być to faktycznie czymś dziwnym (że przed zapisem nie kasuje komórki, aby uzyskać prawidłowy zapis).

Dziękuję @tmf za sprawdzenie tego w XMegach.

Hmm, z opisu metody programowania wygląda, że przy programowaniu EEPROM na początku dane wędrują do bufora strony, a dopiero potem, po podaniu odpowiedniego sygnału, są kopiowane do EEPROM i trzeba czekać na kolejny sygnał, zonaczający zakończenie zapisu strony. Nic nie pisze o tym, że cokolwiek jest kasowane, ani jak wygląda to przenoszenie danych z bufora do pamięci. I jak pisałem pewnie tu komórki nie są kasowane przed zapisem.

Pewnie nie są, tym bardziej, że operacje kasowania i zapisu są rozdzielne. Tak jak pisze piotrva, zapis polega na odczycie pamięci do bufora, uaktualnieniu bufora, skasowaniu strony i zapisie z bufora do pamięci. Najlepiej ten mechanizm widać właśnie w XMEGA, gdzie ma się do bufora zapisu dostęp programowy i można na raz zapisywać cała stronę, także w programie.

Bufor strony to część interfejsu. Sama technologia pamieci EEPROM pozwala na swobodny zapis do dowolnej komórki, więc jeśli w ATMegach jest EEPROM to można zapisać dowolną komórkę, bez wymazywania całej strony. Wprowadzony bufor strony ma znaczenie (podejrzewam) tylko wydajnościowe.
Jeśli zapisujesz coś do EEPROMu z wnętrza programu, to nie musisz najpierw kasować komórek. Wydajesz tam przykładowo instrukcje:



i masz zapisaną komórkę EEPROM (pominąłem pętle oczekiwania na pamięć EEPROM).

Stąd mój wniosek, że kasowaniem zawartości komórek przed ich zapisem (tak aby zapis był prawidłowy) zajmuje się już sam sprzęt (sam moduł EEPROM) i programiście ani programatorowi nic do tego. Wydaje się więc, że Twoje umiejscowienie problemu @piotrva jest mniej więcej prawidłowe. Niemniej, jeśli kasowaniem bajtu przed zapisem do EEPROM zajmuje się sama pamięć EEPROM, to zagadką pozostaje fakt dlaczego w takim razie z wnętrza procesora mogę zapisać do EEPROM, a z poziomu interfejsu_programowania_z_zewnątrz (nazwę go wewnątrzukładowym modułem programowania) - nie. Otóż jedynym rozsądnym wnioskiem wydaje się być brak czasu oczekiwania wewnątrzukładowego modułu programowania na zakończenie operacji zapisu pamięci EEPROM (bit EEWE).

Dodano po 32 [minuty]:

W trakcie kiedy odpisywałem, @tmf napisał:

tmf wrote:

Tak jak pisze piotrva, zapis polega na odczycie pamięci do bufora, uaktualnieniu bufora, skasowaniu strony i zapisie z bufora do pamięci.

Czy jesteś tego pewien @tmf? To się bardzo kłóci z tym co ja wiem o funkcjonowaniu EEPROM. To co opisujesz dużo bardziej pokrywa się ze sposobem działania pamięci Flash niż EEPROM. Ja zrozumiałem, że @piotrva pisał o buforze który znajduje się w wewnątrzukładowym module programowania.
Główną różnicą pomiędzy pamięciami Flash (które również są pamięciami EEPROM swoją drogą), a zwykłymi pamięciami EEPROM jest właśnie to, że we Flashu zapis odbywa się stronami.


-- EDIT --
Teraz dopiero wyczytałem w dokumentacji - oni w dokumentacji stroną nazywają 4 bajty (!) Tak więc pamięć EEPROM jest zorganizowana w 32bitowe komórki. Nazywanie tego stronami jest niestosowne

Nie ma znaczenia jak fizycznie jest realizowana pamięć EEPROM. Zauważ, że proces kasowania i zapisu jest rozdzielny, nawet w niektórych ATMegach możesz konfigurując odpowiednio rejestr kontrolny EEPROM tylko skasować wybraną komórkę, lub tylko ją zapisać (bez kasowania). Domyślnie te operacje są połączone, zapis z programu wywołuje najpierw kasowanie, a potem właściwy zapis - stąd operacja ta jest 2-krotnie dłuższa niż sam zapis lub samo kasowanie.
Ale wracając do tematu - spójrz na instrukcje ISP. Jest instrukcja zapisu bufora, ale ona najwyraźniej nie kasuje go. W tym celu trzeba wykonać chip erase. W XMEGA kontroler NVM ma osobną instrukcję kasowania strony i osobną zapisu (a także instrukcję łączące poprzednie w sekwencje). Stąd myślę, że programator musiałby zmienić tryb zapisu EEPROM ze stron na bajty (wtedy kontroler ISP automatycznie kasuje komórki przed zapisem). Tyle, że ten zapis jest 16-32 razy wolniejszy i pewnie dlatego nie jest domyślnie stosowany. Zmiana tego wymagałaby wcześniejszego odczytu fusebitów, albo EEPROM i sprawdzenia jaka taktyka jest sensowniejsza. Myślę, że programiści poszli po prostu na skróty i dlatego to działa tak jak działa. Swoją droga jeśli zaznaczasz EESAVE to znaczy, że nie zmieniasz zawartości EEPROM więc takie działanie programatora ma sens.

Ciekawe rzeczy piszesz @tmf. Warto wiedzieć, choć w tym przypadku doszliśmy myślę do granicy i wypadałoby aby ktoś z Atmela się wypowiedział.

tmf wrote:

Swoją droga jeśli zaznaczasz EESAVE to znaczy, że nie zmieniasz zawartości EEPROM więc takie działanie programatora ma sens.

Warto jeszcze raz podkreślić, że tak jak wspomniałem w poście #19, od początku testów na nowo zakupionym układzie EESAVE mam wyłączone (odznaczone) (!) i mikrokontroler zachowuje się w opisany sposób (nieprawidłowo).

To też przecież nie może być tak, abym ja nie mógł w żaden sposób wymienić samego EEPROMa w układzie bez kasowania wszystkiego (a więc i EEPROMA i FLASHA). A więc uznaje to zachowanie za błąd.

I też dałbym sobie rękę uciąć, że to dopiero od jakiegoś czasu tak się dzieje i nie było tak zawsze. Dawniej (wydaje mi się), że to działało normalnie. Ale tutaj akurat nie daje słowa, bo pamięć płata różne figle (mogłem po prostu nie zauważyć - choć bardzo wątpię).

Informacje, które podaje pochodzą z Atmela, nie jesteś pierwszą osobą zainteresowaną pamięcią EEPROM Co do wymiany zawartości EEPROM - bo ja wiem, w gotowym projekcie i tak ustawia się lockbity, więc chip erase to jedyna możliwość wpisania nowego wsadu. Po prostu obawiam się, że program odpowiedzialny za programowanie MCU jest robiony pod typowe przypadki, stąd twój pech

Cóż, jak ustaliliśmy - programowanie eeprom z zewnątrz nie wywołuje procesu kasowania komórek. Jeśli konieczna byłaby zmiana zawartości eeprom bez zmiany flasha (w jakichś ekstremalnych przypadkach, gdzie byłby to mus i nie mogłoby być bootloadera) to można w programie dać jakąś funkcję kasującą eeprom z poziomu programu i potem użyć programatora i wgrać nową zawartość. Taka ekstremalna metoda na specjalne okazje.

Otrzymałem odpowiedź z supportu Atmel'a. Takie zachowanie jak się okazuje jest normalne.
W trybie programowania pamięć eeprom kasowana jest tylko podczas komendy chip erease.
Czyli to że parę razy działało to był czysty przypadek, czyli sytuacja opisana przeze mnie kasowania wcześniej ustawionych bitów.
Komórki są kasowane tylko i wyłącznie podczas komendy chip erease (przy niezaprogramowanym fusebicie eesave) lub podczas zapisu pojedynczymi komórkami z poziomu programu.