www.swiatelka.pl

Hej, pracuje właśnie nad doktorem dla maleńkich avrów, wszystkich które posiadają możliwość szeregowego programowania wysokonapięciowego, czyli (chyba) wszystkich 8 nóżkowych czyli attiny 11, 12, 13, 15, 25, 45, 85, oraz 14 nóżkowych 24, 44, 84. Cała reszta (wg tego co wygooglowałem) posiada już możliwość programowania wysokonapięciowego równoległego.

O co chodzi? Doktor taki po prostu sprawdzi jaki procek mu włożono, i ustawi wszystkie fusebity do wartości fabrycznych, czyli np wyłączony reset (fusebit RSTDISBL) czy wyłączoną możliwość programowania ISP (fusebit SPIEN) - wyłączonych celowo czy niechcący.

Na razie mózgiem uładu jest mega8, wyświetlacz do "debugowania", oraz analizator stanów logicznych do pc. Mózg jednak planuje wymienić na tiny2313 lub nawet tiny13 jak mi kod wejdzie, zamiast wyświetlacza będą tylko dwie diody kontrolne - czyli prosto i tanio.

Całą męczarnie mam już za sobą, protokół HVSP działa, odczytuje sygnaturkę, odczytuje i zapisuje fusebity, wymazuje flash - eksperymentuje na attiny13, dodanie reszty procków to już tylko formalność.

Będe potrzebował testerów, jeśli ktoś ma jakiś procek z wymienionych powyżej, i chciał by sobie takiego doktorka wykonać, to zapraszam. Na dniach zamieściłbym kod oraz (jakże prosty) schemat.

Hmm?

zaiste światła to idea!
Mam i procki, i dobry programator którym moge sobie mieszać w fusach do woli żeby miec co "naprawiać", jak znajdę chwilę może bym potestował.Kiedyś mi tego brakowało....
Sporo driverków z DX-a czy KAI na Attiny ma namieszane w fusach tak, że np. Ponyprog już nic z nim nie zrobi...

Myślę, że znajdzie się tu kilka osób, które mają w szufladzie kilka zblokowanych uC. Fajnie było by je odzyskać

Attiny13, 45, i 85 mam, te sprawdze, dobrze by było gdyby ktoś miał jakieś inne

Co do gotowych driverków - myślę że mają ustawione lockbity i nic się z tym nie zrobi. Przy ustawionych lockbitach nie można nawet zresetować fusebitów, ale dam zworkę którą będzie można zezwolić na wymazanie całej pamięci, co jest niezbędne do skasowania lockbitów, a co z kolei jest niezbędne do skasowania fusebitów. A może macie jakieś pomysły? Chętnie wysłucham

A tu wersja tymczasowa-poligonowa

Właśnie zresetowałem fuski w tiny13 bo miała wyłączony reset. W takim razie dzięki za chęci, niebawem dam znać co i jak

No piękna robota, zdaje się, ze mam jakieś ATtiny13, które z niewiadomych przyczyn nie chcą się zaprogramować.
Widzę, że zaczynamy dysponować coraz potężniejszym "arsenałem" narzędzi.

Pozdrawiam

Manekinen, ty zawsze trafisz w to co potrzeba akurat człowiekowi Parę dni temu, że tak powiem, uwaliłem (chyba) attiny13 i zacząłem się właśnie zastanawiać jak zrobić mu taki "master reset". Nie za bardzo orientuję się w programowaniu wysokonapięciowym - mógłbyś ogólnie przybliżyć mi (nam) jak to jest zrealizowane? Do jakich portów mikrokontrolera podpina się taki programator?

Pozdrawiam!

To nie jest programator, ale drugi procek który będzie potrafił tylko odblokowywać. Zajrzyj do noty katalogowej np swojej tiny13, rozdział Memory Programming > High-Voltage Serial programming.

Najpierw sekwencja wprowadzająca w stan programowania wyskonoapięciowego, trzeba m.in. podać 12V na pin resetu. Potem masz dane w tabelce które trzeba wysyłać wraz z impulsem zegarowym. Niby proste, ale uruchomić to w praktyce...

Mnie tez chyba by sie przydal taki wynalazek bo cosik chyba namieszalem zaraz po zakupie programatora i mam Attiny do ozywienia

Świetna sprawa , u mnie też zalega z kilka attiny z zablokowanymi fuse'ami .

Mnie osobiście przydałaby się możliwość odblokowywania popularnych procków 2313 i atmeg8 bo to z nimi najcześciej są największe problemy

Czekam na efekt i chętnie przyłącze się do testów.

Reszta procków potrzebuje RÓWNOLEGŁEGO wysokonapięciowego, prace nad takim odblokowywaczem zacząłem już jakieś pół roku temu ale porzuciłem z braku czasu i dziwnych anomalii które mi tam się pojawiały... komunikacja niby działała, czytałem sygnaturkę itp ale coś było skopane... na pewno wrócę do tamtego projektu ale nie wiem kiedy

Czekamy na wyniki

Jakiś czas temu był podobny projekt tyle że do atmega8 i tiny2313 w elektronice dla wszystkich, z tym ze układ miał błędy nie tylko w pcb ale także w sofcie.
Trochę się bawiłem nim, zmieniłem wtedy soft żeby odblokować sobie atmega168.

Teraz chętnie bym sprawił sobie coś takiego do 8pinowych MCU

Wiem że mówiłem że będzie to proste, schemat prosty, mała płytka i kilka elementów... cóż, jednak postanowiłem zrobić to porządnie. Tak na chwilę obecną wygląda płytka, mam nadzieję że nie będzie trzeba niczego zmieniać. Schemat wygląda na skomplikowany ale nie jest... po prostu najpierw zrobiłem płytke tak jak mi pasowały ścieżki, a potem zrobiłem połączenia na schemacie Dzięki temu płytka jest mała i nie ma zbędnych zworek. Na każdej linii są rezystory 330 ohm, można dać w szerokim zakresie nawet do 1K, można też zamiast nich dać zwory ale na własne ryzyko - bowiem jeśli pacjent nie wejdzie z jakiegoś powodu w tryb programowania, i będzie się w nim wykonywał zapisany kod, piny zwarte na sztywno do masy bądź vcc mogą się uszkodzić. Układ tranzystorowy załączający napięcie 12V też można uprościć, ale nie będzie odporny na stany nieustalone na wyjściach doktora podczas resetu - i może podać 12V wtedy gdy nie trzeba. Gniazda ISP można nie montować - ale ułatwi ono wrzucenie nowego softu. Zasilanie stabilizowane 12V (11.5 do 12.5 max). Założona zworka "chip erase" zezwoli na całkowite wymazanie pamięci. Stabilizator może być nawet w obudowie TO-92, 100mA z pewnością wystarczy.


(czemu forum nie przyjmuje plików PNG? W przypadku takich grafik jak wektorowe, obrazki zajmują naprawde bardzo mało miejsca i wyglądają o wiele lepiej niż jpg)


W załączniku pliki projektu eagle.

Doktorem jest Attiny2313, wsad dodam później (raczej dzisiaj) bo najpierw musze znaleźć taki procek, złożyć prototyp, i potestować.

Witam,
ponieważ ostatnie 2 tygodnie poświęciłem na opracowanie rozwiązania odblokowywania Atmeli chętnie dołączę się do dyskusji, tym bardziej, że udało mi się uzyskać pozytywne rezultaty.

Pierwsze od czego zacząłem to poszukiwanie w internecie sprawdzonych rozwiązań, ale tu niestety niewiele udało się znaleźć.

Drugie, to przestudiowanie specyfikacji Atmela dot. metod programowania: ISP, HVSP, Parallel

Trzecie, to serie prób przy użyciu sterowania z portu LPT z garścią dodatkowych elementów i protokołu HVSP wg. specyfikacji Atmela.
Podchodziłem do tego bez spodziewanych rezultatów przez kilka nocy na różne sposoby, aż w końcu mi się udało.

W tej chwili pracuję nad połączeniem w jedno interfejsu zgodnego z STK-200 oraz rozwiązania HVSP.

Moje wnioski:
- poszukując rozwiązań w internecie znalazłem projekty "kasowników" do ATtiny które mają podstawkę DIP-8 i nie wymagają komputera - jako kasowniki są one wystarczające, ale dla mnie HVSP to nie tylko zmiany prowadzące do przywrócenia komunikacji ISP, ale także programowania pamięci programu i danych
- uważajcie na układy ATtiny15, gdyż SCI jest na pinie 3, a nie drugim jak w reszcie "małych" ATtiny
- napięcie HV nie musi być +12V, z praktyki wynika, że może być od ok. +7V w górę
- większe układy np. tiny2323 oraz megi mają programowanie równoległe, więc trzeba wchodzić danymi na 8-miu bitach, reszta komunikacji wygląda podobnie

To czego nie jestem pewien:
- w specyfikacji Atmelowej są przedstawione dwie sekwencje inicjalizacji HVSP: jedna zakłada sekwencje 6x zmiany SCI przy niskim stanie resetu i SDO/SDI/SII w wymuszonym stanie niskim, a zaraz później jest opisane, że można wejść w tryb HVSP bez owej sekwencji na SCI
- nie jest dla mnie jasne, czy należy sterować w czasie napięciem +12V na linii resetu, czy też można od razu podać +12V na res, a następnie wymusić pozostałe warunki "000" jednocześnie z podaniem +5V na Vcc

Mam nadal problem z kilkoma sztukami, które poprawnie się przy pomocy mojego rozwiązania czytają, ale przy próbie zapisu (erase lub zmiana fuse-bit`ów) się zawieszają. Co ciekawe ten problem mam z 3-ma sztukami z jednej serii - pozostałe 5-sztuk odblokowałem bez problemu. Podejrzewam, że problemem są odbicia na linii (między programatorem, a MCU mam ok. 50cm taśmę) lub nieprawidłowe timingi poszczególnych sekwencji rozkazów.

Też widziałem te projekty, ale były to dedykowane dla konkretnego modelu, np t13 czy t12. Układ taki nie odczytywał nic, nic nie sprawdzał, po prostu wysyłał dane i tyle. Ten mój odczytuje sygnature i sam wie w jaki procek co ładować

A pomysł takiego "tłumacza" SPI>HVSP (bo chyba o tym piszesz) też mi się w głowie zrodził, jest to możliwe do wykonania, czemu nie

Wiem że tiny15 ma portb.3 na innym pinie niż reszta 8 nóżkowców, uzwględniłem to i jest osobna ścieżka dla niego. Jeszcze nie wiem jak to oprogramuje, nie wiem czy jednocześnie na dwie moge podawać zegar, czy w razie niepowodzenia przełączać te nóżki i próbować ponownie z nadzieją że to t15 a nie 13.

Co do inicjalizacji HV - czytałem na zagraniczncyh forach że niby jest jakaś różnica, że trzeba kilka razy machnąć zegarem przed dawaniem jakichś komend. Otóż wszystkie noty 8-nóżkowców jakie przeglądałem nie mają takiego czegoś napisane - i inicjuje bez machania zegarem. Ponadto - na próbę sprawdzałem jak się zachowa pacjent jeśli dma mu kilka taktów zegara na początku... przy dalszej komunikacji wysyła spowrotem błędne dane. Prawdopodobnie traktuje on te takty jako początek transmisji, bo każdy bajt zaczyna się jednym pustym taktem a kończy się dwoma. Natomiast wzmiankę o machaniu zegarem przy inicjacji posiada każda nota procków z interfejsem równoległym - i przy zabawach takie coś stosowałem i to działało. Możesz dac przykłąd w której nocie znalazłeś taką wzmiankę?

Hmm nie bardzo rozumiem ostatniego pytania... nie można od razu podawać resetu, należy to zrobić w ściśle określonym czasie (20 - 60us) - wprawdzie nie próbowałem inaczej, ale robie wszystko wg noty, bo jeden procek może wejść w tryb programowania a inny będzie kapryśny.

Co do timingów, tak wygląda u mnie cała sekwencja odczytania sygnatury (linia odbioru była tutaj odłączona) - zarejestrowane analizatorem stanów logicznych, dane naniosłem ręcznie.

Czyli najpierw wystawiam dane na linie, zegar w górę, a wraz z wyłączeniem zegara zmieniam dane. Przy odczycie dane dostajemy z lekkim przesunięciem. Do tego odczytując dane nie ma pierwszego pustego taktu, ale w tym miejscu jest już najstarszy bit bajtu. Jeśli masz długą taśmę to to może być przyczyna, producent pisze o 220ns każdego taktu, ile ty stosujesz? U mnie lata to na 1us góra i 1us dół, czyli 2us cały takt. Równie dobrze chodzi przy zegarze 2ms czy większych, możesz zwiększyć to pozbędziesz się problemu.

I jeszcze chciałbym poruszyć temat sygnatur, bo widzę że jesteś w temacie. Można znaleźć w internecie szczątkowe informacje na temat wymazanej, usuniętej sygnatury. Sygnatura wraz z bajtami kalibracji i innymi nie jest na stałe zapisana we wnętrzu struktury, ale w specjalnej części flasha. Mi się już dwukrotnie przydażyło że usunąłem sobie sygnaturkę, objaw jest taki że procek przedstawia się jako FF FF FF ale funkcjonuje w pełni normalnie, fusebity, flash, eeprom działają, program się wykonuje. Właśnie przy zabawie z tym HVSP kilka dni temu wymazałem sobie sygnaturkę z t13, po wykonaniu polecenia chip_erase sygnatury już nie było. Co jest dziwne a nigdzie nie można znaleźć info na ten temat, dokumenty atmela milczą

[ Dodano: 24 Styczeń 2010, 17:21 ]
A tak wygląda równoległy doktorek, zacząłem go tworzyć jeszcze przed tym wynalazkiem z EDW. gniazda na t2313, m16/32/inne, m8/m88/inne. Doktorem była mega8.