ID Mikroprocesora...

Jakiego dokladnie? Rozprogramowac przypadkowo sygnatury kilku AVRow mi sie udalo.

pewnie się kiedyś okaże, że istnieje nieudokumentowana komenda ISP, która pozwala zmienić sygnaturę (;

w.

Dnia 2005-01-29 15:00, Użytkownik Wojtek Kaniewski napisał:

Ty się nie śmiej - sygnatura jest jedną z pierwszych rzeczy, która pada w prockach serii 89Cxx51 albo od przeciążeń samego procka albo od ładunków statycznych. Kiedyś 89C4051 zamieniło mi się w 89C1051 i po automatycznym wykryciu procka przez programator nie mogłem wgrać programu powyżej 1kB :-(

nie możesz po prostu użyć innego programatora?

w.

nie napisałeś, jakiego programatora używasz, ani jak dokładnie to próbujesz robić. ciężko cokolwiek wywnioskować. tak czy inaczej, sugestia zostaje ta sama -- nie prościej użyć innego programatora, skoro masz z aktualnym problemy?

w.

A dobry wynik daje zaprogramowanie całego EEPROMu wartościami 0xFF? Wyjdzie jak skasowanie. Kasowanie może nie działać jeżeli masz aktywny fusebit nakazujący takie zachowanie procesora.

Czy sprawdziłeś na 100%, że _programowanie_ EEPROMu nie działa, a nie np. błędny jest odczyt lub kasowanie scalaka? Sprawdź, czy dobrze ustawiłeś fusebity - może pomerdały mi się opisy bitów.

Jeżeli dobrze działa programowanie i weryfikacja Flasha, napisz krótki program na AVRa zapisujący coś i czytający z EEPROMu. Wtedy upewnisz się, gdzie jest problem. A ja go będę mógł poprawić. :-) Akurat nie dysponuję żadnym ATTiny2313 do testów praktycznych.

W artykule <cteeuq$ker$ snipped-for-privacy@atlantis.news.tpi.pl> autorem którego mieni się Adam Dybkowski, napisano:

U mnie też - ATmega128. W układzie, w którym to nastąpiło, było możliwe podciągnięcie resetu do napięcia +5V (przez R kilka k), podczas gdy uC był zasilany z 3.3V. Być może w ten sposób jest znoszona jakaś sprzętowa blokada programowania sygnatury (tzn. sekwencja typu "ciąg poleceń programowania - zmiana stanu RESETu z 0 na VCC+coś").

u mnie jeden AT89S51 zmienił sygnaturę na 0xff 0xfd 0xff przy 5V, więc to pewnie nie to.

poza tym, dla zabawy zacząłem wysyłać do ATmega8 różne komendy po ISP, _wyłączając_ te udokumentowane. na komendę 0xa8000000 odpowiedział 0xff, mimo że o takiej komendzie w PDFie nic nie piszą. potem zacząłem wysyłać

0xacXX0000, również wyłączając te opisane, żeby sobie nie rozprogramować fusów. po paru seriach przestał odpowiadać, oscylator nie rusza. całkiem ciekawe.

w.

Wytłumaczenie jest bardzo proste. Stosowanie kodów spoza udokumentowanych jest (teoretycznie) zabronione więc można było zrobić prostszy automat w VHDLu z niepełnym dekodowaniem. No i przykładowo choć w dokumentacji jakieś polecenie ISP może być wydane przez wysłanie 4 oktetów: 12 34 56 78 to w praktyce może się okazać, że układ reaguje na większy zbiór, np. komendy 12 34 xx x8 albo jeszcze dziwniejszą kombinację zawierającą niektóre bity właściwe, a niektóre wszystko-jedno-jakie ("don't care"), zależy jak im się ułożyły bramki po kompilacji VHDLa.

Tak że nie szukaj spisku ani nieudokumentowanych komend ISP, to po prostu uproszczenie struktury scalaka.

byłem przekonany, że uproszczenia widać po xxx w kodach komend, których jest pełno w dokumentacji. takie komendy pomijałem. poza tym, przestał działać po którymś z kolei potwórzeniu dokładnie tej samej operacji.

tak czy inaczej, bawię się tylko, nie szukam spisków.

w.

W artykule <ctp13p$hak$ snipped-for-privacy@atlantis.news.tpi.pl> autorem którego mieni się Adam Dybkowski, napisano:

Bardzo możliwe - zaoszczędzi się parę um^2 krzemu, a przy skali produkcji to procentuje ;)

IMO są przesłanki, by przypuszczać że takie polecenia istnieją (przynajmniej w odniesieniu do zapisu sygnatury).

Po pierwsze - da się to zrobić przez przypadek ;) Po drugie - jeśli producent uznał za stosowne umieszczenie sygnatury w pamięci reprogramowalnej, to i pewnie ma wygodny sposób na jej zmianę (a ISP dobrze tu pasuje). Po trzecie - podczas testowania uC na końcowym etapie produkcji prawdopodobnie potrzebne jest sprawdzenie działania pamięci sygnatury, a więc jej zapisanie i skasowanie - przed wpisaniem tam docelowej treści (i znowu ISP tu pasuje).

Choć dopuszczam i to, że możliwość modyfikacji sygnatury jest przypadkowym efektem ubocznym. Jeśli przy zgodnym z dokumentacją użyciu ISP nie istotnej szansy na ujawnienie się takiego zachowania, w zasadzie nie jest to 'silicon bug' i producent może z czystym (niemal) sumieniem o tym nie informować.