Naprawiacz fusebitów dla rodziny avr attiny

[Pyra]

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ą

A właśnie mnie zastanawiał taki problem, że program w procku się wykonywał, a programator go nie rozpoznawał..... i nie mogłem przeprogramować.

[df]

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.

Zgadza się, choć do większości zastosowań był on wystarczający.
Znalazłem linki do tych projektów - oto one:
http://cappels.org/dproj/t12fp/t12f.htm
http://home.ict.nl/~fredkrom/pe0fko/Fus ... -ATtiny45/
http://www.microcontrollerprog.com/
Autorzy tych projektów udostępnili źródła, które pomagają zrozumieć jak to działa oraz mogą stanowić jakąś tam bazę pomysłów do podobnych rozwiązań.

Ten mój odczytuje sygnature i sam wie w jaki procek co ładować

Ale przecież sekwencje te nie różnią się między 8-pinowymi ATtiny, no może poza ATtiny15, który ma SCI na pin.3, a nie pin.2 jak reszta w rodzinie.
Czy są jakieś jeszcze inne przesłanki wymagające znajomości sygnatury układu?

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

Mój pomysł opiera się na wspólnym sterowaniu programatora na LPT, który w zależności od trybu pracy (sterowanego programowo z komputera) działałby w standardzie STK-200 (ISP) oraz HVSP i tu niestety standardu na LPT nie ma, a przynajmniej ja nie znalazłem, więc tworzę własne rozwiązanie. Pierwszym pomysłem było "podłączenie" się z własnym rozwiązaniem sprzętowym pod standard dostępnego oprogramowania, tak by zaoszczędzić czasu na pisaniu softu na PC, choć i taką ewentualność brałem pod uwagę. Znalazłem STK-500 z opcją HVSP, ale z uwagi na złożoność i koszt tego rozwiązania odstąpiłem od tego poszukując prostszych rozwiązań, bo przecież HVSP nie różni się zbytnio od ISP. Przeanalizowałem możliwości konfiguracyjne avrdude - w szczególności arvdude.conf i sekcji programmers, ale niestety nie znalazłem tam możliwości zamapowania na port równoległy sygnałów dla protokołu HVSP, a szkoda, bo oprogramowanie to wspiera HVSP.

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.

Możesz podawać na raz na pin 2 i 3 przez rezystory, tak jak zrobiłeś - SCI jest sygnałem wejściowym idącym do programowanego układu, więc stan logiczny na drugim pinie nie będzie na niego wpływać - nawet zaryzykowałbym twierdzeniem, że SCI może wychodzić z Twojego doktora na jednym porcie i rozdwajać się przez 2 rezystory na pin 2 i 3 leczonego.
Drugie rozwiązanie to 2 próby inicjalizacji - jedna na SCI na pinie 2 i jak się ona nie powiedzie, to przejście z SCI na pin 3 i ponowienie sekwencji inicjalizacyjnej.

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.

Ja podaję te 6 cykli na SCI, choć w PDF-ie są podane 2 sposoby z i bez tego.
Wydaje mi się, że mogą być one istotne gdy port resetu jest przełączony na I/O (RSTDISBL), chyba że MCU robi detekcję +12V na !Res i to dla niego jest wystarczającym wyznacznikiem razem z 0/0/0 na SDI/SDO/SII w fazie startu MCU. Ale tu niestety pewności nie mam - producent podaje 2 algorytmy i jak dla mnie nie podaje przekonujących danych, który jest wystarczający i w jakich przypadkach lub nie oraz dlaczego.

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że nie robisz za mało lub za dużo tych machań, albo zaczynasz nie tym zboczem, co trzeba? Zawsze można spróbować po tej sekwencji wysłać komendę NOP i badając SDO wykryć, gdy kontroler potwierdzi instrukcję. Pamiętam, że w ATtiny12 był błąd, który po instrukcji erase`a odbiegał od specyfikacji i trzeba było tam wstawiać sztuczne nop`y.

Możesz dac przykłąd w której nocie znalazłeś taką wzmiankę?

Oczywiście - np. dla ATtiny13a
http://atmel.com/dyn/resources/prod_doc ... oc8126.pdf

Pkt. 17.7.1
"To program and verify the ATtiny13A in the High-voltage Serial Programming mode, the following sequence is recommended"

a następnie

"If the rise time of the Vcc is unable to fulfill the requirements listed above, the following alternative algorithm can be used."

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.

Właśnie w tym drugim algorytmie nie ma słowa o czekaniu 20-60us, tylko od razu podaje się 12V jak tylko napięcie na Vcc osiągnie podaną wartość - cyt.
"3. Monitor Vcc, and as soon as Vcc reaches 0.9 - 1.1V, apply 11.5 - 12.5V to RESET."
Stąd też moje wątpliwości.

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.
[url=http://www.swiatelka.pl/upload_img/miniaturki/IMG_4b5c6eaab1c70490.jpg]Obrazek[/url]
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.

Skrócę testowo połączenie lub/i poblokuje linie pojemnościami.

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ą

avrdude ma opcję odczytu i zapisu sygnatury - spróbuj ją w ten sposób ustawić, a jak masz analizator, to może podpatrzysz jak on to robi

[df]

A właśnie mnie zastanawiał taki problem, że program w procku się wykonywał, a programator go nie rozpoznawał..... i nie mogłem przeprogramować.

Pyra, jeżeli nie rozpoznawał go ISP, to mogłeś przełączyć RSTDISBL, przez co port Resetu stracił swoją bardzo ważną dla ISP funkcję i stał się normalnym portem I/O, mogłeś wyłączyć SPIEN blokując interfejs ISP, choć programatory na tym interfejsie blokują taką opcję, mogłeś pozmieniać CKSEL zmieniając preskalery zegara lub ustawić np. zewnętrzny generator lub kwart i wówczas bez podania sygnału zegarowego procesor sam z siebie nie ruszy.
Można zrobić to przez pomyłkę lub może się to zdarzyć przypadkowo np. źle kontaktującym połączeniem ISP, nagłym obciążeniem komputera i zaburzeniem timingów, przerwaniem sekwencji programowania w nieszczęśliwym momencie, odbiciami na długiej linii strobującej (SCK - warto zablokować ją do masy pojemnością rzędu kilkuset pF) czy po prostu za szybkim programowaniem.

W takich sytuacjach najlepszym i często jedynym wyjściem jest HVSP o którym tu rozmawiamy.

[Manekinen]

Ale przecież sekwencje te nie różnią się między 8-pinowymi ATtiny, no może poza ATtiny15, który ma SCI na pin.3, a nie pin.2 jak reszta w rodzinie.
Czy są jakieś jeszcze inne przesłanki wymagające znajomości sygnatury układu?

Nie chodzi o rozkład pinów - ale o fusebity. Każdy model ma praktycznie inne fusebity, t11, t12, t13, t15 mają różne fusebity, i ładując niewłaściwe można zrobić jeszcze większy bałagan niż był Tylko t25, t45, t85, t24, t44 i t84 mają ten sam zestaw fusków. Już to wszystko sobie rozpisałem i wcisnąłem do programu Do tego starsze procki mają tylko po jednym bajcie fusków, nowsze jak t85 mają trzy bajty fusków... low, high, i extended. Więc trzeba wiedzieć co się gdzie ładuje. Wygodnie jest włożyć procek w podstawkę i się nie martwić o jakieś wybieranie modelu zworkami itp.

Możesz podawać na raz na pin 2 i 3 przez rezystory, tak jak zrobiłeś - SCI jest sygnałem wejściowym idącym do programowanego układu, więc stan logiczny na drugim pinie nie będzie na niego wpływać - nawet zaryzykowałbym twierdzeniem, że SCI może wychodzić z Twojego doktora na jednym porcie i rozdwajać się przez 2 rezystory na pin 2 i 3 leczonego.
Drugie rozwiązanie to 2 próby inicjalizacji - jedna na SCI na pinie 2 i jak się ona nie powiedzie, to przejście z SCI na pin 3 i ponowienie sekwencji inicjalizacyjnej.

No w zasadzie SCI nie jest jednym z pinów enable, ale ciekawe czy procek nie będzie się gubiłjeśli dostanie zegar na dwa piny jednocześnie, może są jakieś nieudokumentowane zależności - np podpatrzyłem analizatorem stanów, co pacjent robi na pinie SDO kiedy ładuje mu komendy i dane, w nocie x_xxxx_xxxx_xx czyli don't care, ale podczas wysyłania pacjent wystawia tam jakieś dane wraz z taktem zegara - nie wiem, może jakieś kontrolne, ale nic o tym nie napisano. Najgorsze jest to że nie mam t15 żeby to sprawdzić jak z tym podwójnym SCI.

Oczywiście - np. dla ATtiny13a
http://atmel.com/dyn/reso...nts/doc8126.pdf

Pkt. 17.7.1
"To program and verify the ATtiny13A in the High-voltage Serial Programming mode, the following sequence is recommended"

a następnie

"If the rise time of the Vcc is unable to fulfill the requirements listed above, the following alternative algorithm can be used."

No i właśnie - albo jestem ślepy albo tego tam nie ma. Sposób różni się tylko tym, że jeśli nie zpełnimy warunku i napięcie zasilające nie wzrosnie w ciągu 20us (pewnie chodzi o czas do załączenia resetu - 20-60us), to monitorujemy te napięcie i dopiero załączamy reset. Nie jest nic a nic napisane żeby podawać jakieś takty na SCI przy inicjacji. A pobrałem dokładnie tą notę którą wskazałeś. Za to w równoległych jest taka wzmianka, to na 100%.

avrdude ma opcję odczytu i zapisu sygnatury - spróbuj ją w ten sposób ustawić, a jak masz analizator, to może podpatrzysz jak on to robi

Opcja zapisu sygnatury? Pierwsze słyszę. Wg danych atmela obszar sygnatury nie jest w żaden sposób dostępny dla użytkownika, jest programowany tylko raz w procesie produkcyjnym.

Ok narazie podorabiałem nóżki układom bo wszystko co znalazłem miałem w smd Zaraz potestuje na tiny45 i t85. Płyteczke można robić, wygląda na to że będzie ok.

[ Dodano: 24 Styczeń 2010, 18:46 ]
Pyra Ne wiem jakiego programatora używasz, ale np. w avrdude jest przełącznik "-F" (force) który wymusza programowanie pomimo błędnej sygnatury. Sprawdź to.

[df]

No i właśnie - albo jestem ślepy albo tego tam nie ma.

str.113 High-voltage Serial Programming Algorithm

To program and verify the ATtiny13 in the High-voltage Serial Programming mode, the following sequence is recommended (See instruction formats in Table 55):

The following algorithm puts the device in High-voltage Serial Programming mode:
1. Apply 4.5 - 5.5V between VCC and GND.
2. Set RESET pin to “0” and toggle SCI at least six times.
3. Set the Prog_enable pins listed in Table 53 to “000” and wait at least 100 ns.
4. Apply VHVRST - 12.5V to RESET. Keep the Prog_enable pins unchanged for at least tHVRST after the High-voltage has been applied to ensure the Prog_enable signature has been latched.
5. Shortly after latching the Prog_enable signature, the device will actively output data on the Prog_enable[2]/SDO pin, and the resulting drive contention may increase the power consumption. To minimize this drive contention, release the Prog_enable[2] pin after tHVRST has elapsed.
6. Wait at least 50 µs before giving any serial instructions on SDI/SII.

Tego Ci brakowało?

[ Dodano: 24 Styczeń 2010, 19:29 ]
Hmmm... właśnie zauważyłem, że zapis taki istnieje w PDF od ATtiny13V rev.2535G–AVR–01/07 (z którego sobie lokalnie korzystam - kopię masz np. tutaj: http://www.ic-on-line.cn/IOL/datasheet/ ... 121757.pdf ), natomiast na stronach Atmela nowy PDF od ATtiny13A już tego zapisu nie posiada.

avrdude ma opcję odczytu i zapisu sygnatury - spróbuj ją w ten sposób ustawić, a jak masz analizator, to może podpatrzysz jak on to robi

Opcja zapisu sygnatury? Pierwsze słyszę. Wg danych atmela obszar sygnatury nie jest w żaden sposób dostępny dla użytkownika, jest programowany tylko raz w procesie produkcyjnym.

Wiem o tym, że Atmel tego nie podaje i że w oficjalnej specyfikacji takiego rozkazu nie ma. Stwierdziłem tylko fakt, iż są programy np. avrdude gdzie taka opcja widnieje, choć osobiście nigdy z niej nie korzystałem:

Kod: Zaznacz cały

-U signature:r:con:r
oraz
-U signature:w:000000

Natomiast podany przez Ciebie przypadek usunięcia sygnatury wskazywałby na istnienie takiej możliwości - stąd moja sugestia.

[Pyra]

A właśnie mnie zastanawiał taki problem, że program w procku się wykonywał, a programator go nie rozpoznawał..... i nie mogłem przeprogramować.

Pyra, jeżeli nie rozpoznawał go ISP, to mogłeś przełączyć RSTDISBL, przez co port Resetu stracił swoją bardzo ważną dla ISP funkcję i stał się normalnym portem I/O, mogłeś wyłączyć SPIEN blokując interfejs ISP, choć programatory na tym interfejsie blokują taką opcję, mogłeś pozmieniać CKSEL zmieniając preskalery zegara lub ustawić np. zewnętrzny generator lub kwart i wówczas bez podania sygnału zegarowego procesor sam z siebie nie ruszy.
Można zrobić to przez pomyłkę lub może się to zdarzyć przypadkowo np. źle kontaktującym połączeniem ISP, nagłym obciążeniem komputera i zaburzeniem timingów, przerwaniem sekwencji programowania w nieszczęśliwym momencie, odbiciami na długiej linii strobującej (SCK - warto zablokować ją do masy pojemnością rzędu kilkuset pF) czy po prostu za szybkim programowaniem.

Niestety "to nie ja" to był procek w AK-47, który przerabiałem, myślę, że to zabezpieczenie producenta

W takich sytuacjach najlepszym i często jedynym wyjściem jest HVSP o którym tu rozmawiamy.

I dlatego się tak cieszę z tego tematu

[Manekinen]

No właśnie miałem Ci wysyłać screena z noty że tego nie ma, i musisz mieć jakąś wcześniejszą wersję noty. Zajrzałem do listy zmian w nocie, zawsze na końcu są podawane różnice jeśli coś uaktualniają - i nie ma tam słowa o tym. Pomyślałem że to chodzi o wersję V niskonapięciową, że może wymaga innej inicjacji, ale nie. W ogóle mają niezły bałagan w tych notach, na ten przykład trzy dni walczyłem z odczytem sygnaturki, bo w tabelce gdzie są instrukcje do wysłania napisano "Repeats Instr 2 4 for each signature byte address". To że komendę ładuje się tylko raz to ja wiem, a z tego wynika że wystarczy tylko powtórzyć insr 2 i 4 aby czytać kolejne bajty sygnatury... dostawałem całkiem inne dane... dopiero otworzyłem notę od tiny12, a tam napis "Repeats Instr 2 - 4 for each signature byte address" - ten głupi myślnik onzacza że trzeba wysyłać instr 2, 3, 4 a nie 2, 4.

Dzięki za te info z avrdude, nie miałem pojęcia o tym. Zaraz wypróbuje.



EDIT



Co do sygnatury - kwestia sporna. Nigdzie nie znalazłem informacji że istnieje w ogóle opcja zapisu sygnatury przez avrdude. Chociaż po wydaniu polecenia informuje nas że ją zapisuje, w jednej z nakładek graficznych jest nawet pole do wpisania sygnatury i opcja write - ale rezultat kiepski - procek od razu wywala błąd. Skoro przez SPI nie da się, to może uda się przez HVSP? Musze podejrzeć jak wygląda transmisja odczytu i próby zapisu, może da się to jakoś przetłumaczyć na HVSP mając do dyspozycji komendy odczytu sygnatury.

Kod: Zaznacz cały

-p t13 -P com1 -c usbasp -F -U signature:w:c:\sig.txt:r

avrdude.exe: Device signature = 0xffffff
avrdude.exe: Yikes!  Invalid device signature.
avrdude.exe: Expected signature for ATtiny13 is 1E 90 07
avrdude.exe: reading input file "c:\sig.txt"
avrdude.exe: writing signature (3 bytes):

Writing |  ***failed;  
################ ***failed;  
################# ***failed;  
################# | 100% 0.02s

avrdude.exe: 3 bytes of signature written
avrdude.exe: verifying signature memory against c:\sig.txt:
avrdude.exe: load data signature data from input file c:\sig.txt:
avrdude.exe: input file c:\sig.txt contains 3 bytes
avrdude.exe: reading on-chip signature data:

Reading | ################################################## | 100% 0.03s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x1e != 0xff
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

Wracając do tematu.

Program przeportowany do tiny2313, sprawdzony na t13, t45, t85, wygląda na to że wszystko ok. Praca rozpoczyna się po przyciśnięciu przycisku, po 250ms przycisk jest znowu aktywny i jego przyciśnięcie spowoduje zresetowanie układu.

DIODY:
świeci zielona - fuski ustawione i zweryfikowane, wsio ok. Jeśli jest lockbit, to tylko sprawdza czy fuski odpowiadają fabrycznym, i jeśli tak to też się zapali.
świeci czerwona - problem z sygnaturą, brak układu, lub brak sygnatury w bazie.
migająca zielona - sygnatura odczytana, fuski się nie zgadzają z fabrycznymi, ale ustawione są lockbity i trzeba zezwolić na wymazanie pamięci aby naprawić fuski.
migająca czerwona - sygnatura odczytana, lockbity wyłączone, ale nie można zapisać nowych fusków, nie przechodzą weryfikacji po 10 próbach zapisu.

Płytka się troszke zmieniła - dodałem dodatkowy jumper, umożliwi on zapisanie fusebitów w procku z uszkodzoną sygnaturką. Niestety każdy procek ma praktycznie inaczej rozłożone fuski, bity SPIEN i RSTDISBL są w różnych miejscach. Ale udało mi się skomponować taki uniwersalny zestaw, po wgraniu którego do niemalże jakiegokolwiek procka, odzyskamy możliwość komunikacji SPI i funckonalność resetu. Ustawienia oscylatora i ogólnie w fuskach będzie namieszane, procek będzie zdatny do dalszej naprawy przez SPI. Nie używać z attiny11 i attiny15, ten zestaw fusków wyłączy im reset/spi.

W załączniku wsad dla tiny2313, fuski: zegar 4MHz bez dzielenia przez 8, dobrze będzie też przełączyć na "fast rising power". W załączniku też nowa płytka, jak ktoś chce w PDF to pisać. Testować, pisać

[ Dodano: 1 Luty 2010, 13:32 ]
I jak? Nikt nie miał czasu się pobawić?