Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

manekinen 13 Jul 2010 22:23 231985 342
Nazwa.pl
  • Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity
    Atmega fusebit doctor, jak sama nazwa mówi, to urządzenie do naprawienia nieumiejętnie przestawionych fusebitów w mikrokontrolerach z rodziny AVR. Największymi problemami jest ustawienie nieprawidłowego źródła zegarowego (fusebity CKSEL), wyłączenie programowania SPI (fusebit SPIEN), lub ustawienie pinu reset w tryb I/O (fusebit RSTDISBL). To proste urządzenie w ułamek sekundy naprawi mikrokontroler nadając mu ustawienia fabryczne.

    O ile w pierwszym wypadku można poratować się generatorem zegarowym lub generatorem RC/kwarcowym, to w drugim i trzecim przywrócenie mikrokontrolera do życia nie jest możliwe przy pomocy programatora szeregowego SPI. Mało osób decyduje się na budowę programatora równoległego, a to dla tego że jest niewygodny w użyciu, a to dla tego że taniej kupić nowy mikrokontroler niż się bawić w jakieś naprawy.

    Przedstawiane urządzenie wykorzystuje możliwość programowania równoległego (oraz szeregowego od wersji 2.03) wysokonapięciowego. Urządzenie jest niezwykle proste i tanie w budowie, wystarczy tylko ATmega8 w roli doktora, dwie diody LED, zworka, stabilizator, tranzystory. W pamięci zapisano sygnatury 96 mikrokontrolerów AVR oraz ich fabryczne fusebity, wystarczy włożyć w podstawkę "uwalony" uC i wcisnąć przycisk START a układ wykona żądaną operację i nasz pacjent zostanie przywrócony do życia. Cały zabieg trwa ułamek sekundy.

    Na płytce głównej znajdują się trzy gniazda, dla procesorów zgodnych pinowo z atmega8, atmega16, i attiny2313 czyli takich najpopularniejszych. Dodatkowo na płytce znajduje się złącze goldpin żeńskie z wyprowadzonymi wszystkimi potrzebnymi sygnałami, do podłączania adapterów:
    #1 HVPP adapter” jako rozszerzenie HVPP dla procesorów kompatybilnych z 20pin Attiny26 oraz 40pin Atmega8515
    HVSP adapter” dla procesorów HVSP 8pin oraz 14 pin attiny, których nie można programować równolegle z powodu zbyt małej ilości pinów.
    Istnieje możliwość wykonania własnych dodatkowych adapterów pod inne rodzaje procesorów w obudowach DIP czy też SMD. Nie trzeba jednak wykonywać adaptera aby naprawić jeden procek, można to zrobić przy pomocy płytki stykowej łącząc sygnały z odpowiednimi pinami. Jak? Zajrzyj do noty katalogowej twojego AVRa, przejdź do "memory programming" a następnie "parallel programming" - nazwy sygnałów i pinów jak na tacy. Wszystkie piny są podpisane pod podstawką DIP40, a w załączniku znajduje się też projekt "pustego" adaptera.

    Płytka jednostronna, o wymiarach 55mm x 92mm. Na wierzchniej części należy wlutować kilka zworek, lub, płytkę można wykonać także jako dwustronną. Zasilanie 12V stabilizowane. Rezystory R7 do R23 moga mieć wartości od 100 ohm do 1K, proponuję raczej 330ohm. Należy pamiętać że trzy piny bitów z linii danych są także wykorzystywane przez programator ISP do aktualizacji programu - urządzenie nie będzie prawidłowo działało jeśli np podlutujemy się do nich z programatorem. Na płytce dodatkowo znajduje się złącze opisane jako RS232, jest to wyjście UARTa, podłączając się pod nie (38000bps), dowiemy się wszystkiego o przebiegu operacji naprawy - przykładowy zrzut poniżej. Oczywiście terminal nie jest konieczny, wszystkiego dowiemy się z samych diodek :)
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    UWAGA! Podczas montażu podstawki DIP40 należy usunąć z niej metalowe złącza od 29 do 37 pinu! Ścieżki przechodzące w tych miejscach nie mogą zostać elektrycznie połączone z pinami włożonego procesora, a biegną tamtędy aby uprościć samą płytkę. Na obrazku poniżej zaznaczyłem które to piny:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    Oznaczenia diod:
    świeci zielona - fusebity naprawione i zweryfikowane, układ naprawiony. Jeśli jest ustawione zabezpieczenie lockbit, to tylko sprawdza czy fuski odpowiadają fabrycznym, i jeśli tak to także zapali tę diodę.
    świeci czerwona - problem z odczytaniem sygnatury, brak układu, lub brak sygnatury w bazie.
    migająca zielona - sygnatura odczytana, fusebity się nie zgadzają z fabrycznymi, ale ustawione są lockbity i trzeba zezwolić na wymazanie pamięci aby je naprawić (czytaj dalej).
    migająca czerwona - sygnatura odczytana, lockbity wyłączone, ale nie można z jakichś powodów zapisać nowych fusebitów.

    Zworka ALLOW ERASE zezwala na wymazanie całej pamięci w przypadku ustawionych Lockbitów (bez ich wykasowania nie jest możliwe przestawienie Fusebitów). Po podłączeniu układu i wciśnięciu przycisku START program inicjuje tryb programowania równoległego, lub jeśli użyto adaptera HVSP - inicjuje tryb programowania szeregowego. Pacjent odpowiada stanem wysokim na pinie RDY/BSY. Pierwszą rzeczą jaką robi doktor to wymazanie całej pamięci jeśli użytkownik na to zezwolił. Po tym odczytuje sygnaturę podłączonego mikrokontrolera i sprawdza czy jest w stanie go obsłużyć. Następnie sprawdzane są lockbity, i jeśli nie blokują dostępu, doktor odczytuje fusebity i porównuje je z fabrycznymi zapisanymi w bazie. Jeśli się różnią, zapisuje te fabryczne, uwzględniając czy dany model pacjenta posiada extended fusebits, czy nie. Są także procesory z tylko jednym bajtem fusebitów i to też jest uwzględnione. Program na końcu weryfikuje ich poprawność i zapala odpowiednią diodę. Informacje przez rs232 są wysyłane na bieżąco.

    Program został napisany na podstawie opisu programowania równoległego (oraz szeregowego) zawartego w większości not katalogowych mikrokontrolerów AVR, (memory programming – parallel/serial programming).

    Projekt rozpoczęty jeszcze w 2008 roku, ale z braku czasu porzucony, teraz wykonany na nowo.

    Fusebity: Wewnętrzny zegar 8MHz, oraz włączony bit EESAVE.

    Jako że jest to 2w1 (HVPP i HVSP), 8kB pamięć Atmegi8 okazała się niewystarczająca i nie weszły wszystkie wodotryski…
    1.Nie wszystkim procesorom wyświetlają się nazwy po rs232, ale tym najpopularniejszym. Nie ma to jednak żadnego wpływu na pracę układu.
    2.Trochę tekstu wysyłanego przez rs232 zostało umieszczone w pamięci EEPROM. Nawet jeśli nie masz zamiaru korzystać z tego wyjścia, MUSISZ zaprogramować eeprom plikiem EEP.BIN lub EEP.HEX! Używanie układu z nie zaprogramowanym lub źle zaprogramowanym eepromem narobi więcej szkód niż pożytku!

    Jeśli zapaliła się zielona dioda to możesz mieć 100% pewność że fusebity zostały zresetowane. Jeśli układ nadal nie odpowiada dla zwykłego programatora ISP, to znaczy że ma uszkodzony sprzętowy SPI, posiada inne uszkodzenie, lub xle wgrałeś eeprom. Jeśli zapala się dioda czerwona, jedyną rzeczą jaką możesz zrobić to sprawdzenie co doctor wysyła przez rs232 – wtedy mogę pomóc rozwiązać problem.

    Liczba obsługiwanych procesorów: 96
    Liczba obsługiwanych w podstawkach: 53

    Reszta to obudowy SMD, nie ma dla nich jeszcze adapterów.

    Pełna lista obsługiwanych procesorów:
    (testowane oznaczone na zielono)

    1kB:
    AT90s1200, Attiny11, Attiny12, Attiny13, Attiny15
    2kB:
    Attiny2313, Attiny26, Attiny261, Attiny28, AT90s2333, Attiny22, Attiny25, AT90s2323, AT90s2343
    4kB:
    Atmega48, Atmega48P, Attiny461, Attiny43U, Attiny4313, Attiny48, AT90s4433, AT90s4414, AT90s4434, Attiny45
    8kB:
    Atmega8515, Atmega8535, Atmega8, Atmega88, Atmega88P, AT90pwm1, AT90pwm2, AT90pwm2B, AT90pwm3, AT90pwm3B, AT90pwm81, AT90usb82, Attiny861, Attiny88, Attiny85
    16kB:
    Atmega16, Atmega16U4, Atmega16M1, Atmega161, Atmega162, Atmega163, Atmega164, Atmega164P, Atmega165, Atmega168, Atmega168P, Atmega169, AT90pwm216, AT90pwm316, AT90usb162
    32kB:
    Atmega32, Atmega32U4, Atmega32M1, Atmega324, Atmega324P, Atmega325, Atmega3250, Atmega325P, Atmega3250P, Atmega328, Atmega328P, Atmega329, Atmega3290, AT90can32
    64kB:
    Atmega64, Atmega64M1, Atmega649, Atmega6490, Atmega640, Atmega644, Atmega644P, Atmega645, Atmega6450, AT90usb646, AT90usb647, AT90can64
    128kB:
    Atmega103, Atmega128, Atmega1280, Atmega1281, Atmega1284, Atmega1284P, AT90usb1286, AT90usb1287, AT90can128
    256kB:
    Atmega2560, Atmega2561

    Galeria:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    Render Eagle 3D:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    Prototyp - Atmega8 czyta sygnaturę i fuski Atmegi32 z uszkodzonym SPI, i wyświetla info na LCD:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    Adaptery:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    Kompatybilność z podstawkami - czyli co gdzie umieszczamy:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    W załączniku wszystkie pliki:
    Projekt płytki oraz adapterów (eagle 5.4.0) wersja 2.0d: BRD, SCH, oraz wersje do druku PDF
    Kod wynikowy (bascom 1.11.9.0) wersja 2.03: HEX oraz BIN
    Obraz eepromu wersja 2.03: HEX oraz BIN

    Krótkie objaśnienie dla nie będących w temacie:
    HVPP = high voltage parallel programming = wysokonapięciowe programowanie równoległe.
    HVSP = high voltage serial programming = wysokonapięciowe programowanie szeregowe.
    Czyli metody programowania pozwalające dobrać się do procesora pomimo wyłączonego resetu czy isp, czyli takiego naszego umarlaka. Z programowania szeregowego korzystają procesory z niewielką ilością nóżek, bo ten rodzaj wymaga tylko kilku linii. Z programowania równoległego korzystają procesory które posiadają przynajmniej 20 nóżek, czyli wszystko powyżej tiny2313 włącznie.

    Powyższy opis i załącznik zawierają wszystkie aktualizacje, natomiast pełny opis i wszystkie załączniki z różnymi wersjami hardware i software - dla dociekliwych - są dostępne na stronie projektu:
    http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/
    Znajduje się tam także spora ilość komentarzy, polecam poczytać w razie problemów, ale tutaj równie chętnie odpowiem o ile znajdę czas. Układ wykonało sporo osób, więc jest przetestowany i działa prawidłowo.




    _______________________________
    UWAGA AKTUALIZACJA #11 - TUTAJ -
    -145 obsługiwanych układów
    -wsady dla Atmega88, Atmega88P, Atmega168, Atmega168P, Atmega328, Atmega328P.
    -dwustronna komunikacja przez UART, można m.in. wysyłać własne fuski
    -duuużo duuużo poprawionych błędów, również na płytce

    Skrócona lista zmian i ulepszeń znajduje się w changelogu, ale polecam przeczytać cały temat (raptem 5 stron).
    FAQ - najczęściej zadawane pytania i odpowiedzi na nie.
    _______________________________

    Cool? Ranking DIY
    About Author
    manekinen
    Level 29  
    Offline 
    manekinen wrote 1629 posts with rating 2323, helped 76 times. Live in city Kętrzyn. Been with us since 2006 year.
  • Nazwa.pl
  • #2
    TormentedSoul
    Level 10  
    Super! Właśnie niedawno uwaliłem 2 ATmegi8 tymi fusebitami. ;)
  • Nazwa.pl
  • #3
    profesorek_96
    Level 16  
    Fajny projekt, bardzo przydatny.
    Mam pytanie odnośnie pcb które są bardzo ładnie wykonane?
    Czy warstwę z napisami jak i samą płytkę wykonywałeś przy pomocy żelazka czy laminatorem?
  • #4
    Duch__
    Level 31  
    A może autor przerobił by program główny na jakiś inny procesor niż Atmegę8. Jak wiadomo ciężko ją dostać w rozsądnej cenie, a jest jeszcze wiele innych procków w obudowach DIP28, o identycznej pinologi.
  • #5
    Jdsoul
    Level 23  
    Czy tą zabawką da się odblokować procesor w obudowie TSOP - czy są jakieś projekty adapterów???
  • #6
    krzysiek_p
    Level 14  
    Duch__ wrote:
    A może autor przerobił by program główny na jakiś inny procesor niż Atmegę8. Jak wiadomo ciężko ją dostać w rozsądnej cenie, a jest jeszcze wiele innych procków w obudowach DIP28, o identycznej pinologi.

    Ja również popieram cytowanego - szczególnie, że już od dłuższego czasu nie używałem m8 i jedyna jaką mam już teraz jest wlutowana na stałe w analizatorze logicznym, więc nie wykorzystam jej. Mam za to 48 (która odpada ze wzgledu na flasha), 88 i 168. Miło by było złożyć sobie coś takiego, szczególnie, że mam m16 zablokowaną. No i jeszcze dochodzi możliwość wykorzystywania pinu reset uC jao gpio.
  • #7
    piotrva
    VIP Meritorious for electroda.pl
    Jdsoul, owszem można zrobić adapter, ale koszt byłby gigantyczny (podstawki typu CLIP lub specjalne nakładane od góry złącza stykowe kosztują krocie, a ich dostanie dla zwykłego elektronika często graniczy z cudem). Ja osobiście tylko raz spotkałem się z taką podstawką na żywo, cena zaledwie ~130 zł o ile dobrze pamiętam. Zawsze możesz podłączyć drucikami na płytkę na której masz wlutowany uP w TSOP, o ile inne elementy nie zakłócą pracy. lub możesz zastosować coś takiego: http://diy.elektroda.eu/przystawka-smd-do-programatora/#more-634
    Co do samego projektu, to bardzo pożyteczny. I tu moja prośba, bo nie mam atmegi8, ale inne uP, czy mógłbyś więc zamieścić kody źródłowe oprogramowania? ew. kompilację pod atmega168 (taki uP wykorzystałbym do tych celów, mam zablokowanych parę meg2560 :D)
  • #8
    omicronNs
    Level 21  
    No i nie lepiej byłoby zrobić sobie programator równoległy? Więcej nim zrobisz bo przy okazji możesz procesor zaprogramować, jak potrzebny pin reset jako i/o nie ma problemu ze zmianą w programie gdy już uK zaprogramowany, i przecież programator równoległy jakby nie patrzeć prostszy w budowie bo mikrokontrolera nie potrzeba. Jedyną wadą programatora równoległego to to że z każdym odblokowywaniem trzeba bawić się na komputerze, no i port LPT może sprawiać niektórym problem.
  • #9
    piotrva
    VIP Meritorious for electroda.pl
    cóż, najciekawszym rozwiązaniem, choć nie wiem czy to by się udało, byłby konwerter ISP->HVPP/HVSP
    ja osobiście zainwestowałbym w prog. równoległy, o ile nie byłby na LPT lub jeśli znalazłbym wirtualny LPT na USP
  • #10
    Gostek
    Level 17  
    Hmm, uzywane STK500 chyba bedzie tansze....
  • #13
    pwlu10
    Level 12  
    "tani"? Przecież Atmega8 teraz nawet 15zł kosztuje
  • #14
    GruX
    Level 18  
    Gostek wrote:
    Hmm, uzywane STK500 chyba bedzie tansze....


    Tak, i na pewno odblokujesz fusebity ;]
  • #16
    piotrva
    VIP Meritorious for electroda.pl
    cóż, ceny atmeg8 są bardzo różne:
    http://www.bujnowicz.com/szukaj/?szukaj=atmega+8&x=0&y=0
    w tej sytuacji bardziej opłaca się kupić jakiegoś większego uP, np. mega32
  • #17
    ZbeeGin
    Level 39  
    GruX wrote:
    Tak, i na pewno odblokujesz fusebity ;]

    piotrva wrote:
    stk500 to ISP a nie HV

    Wszem i wobec należy uświadomić, że STK500 to płyta prototypowa, która poza możliwościami uruchomieniowymi zawiera także programator równoległy. Jego kopię można znaleźć w sieci. Dlatego też proszę odświeżyć sobie swoje wiadomości na temat STK500 przed wypisywaniem kolejnych takich bzdur.

    manekinen wrote:
    Jako że jest to 2w1 (HVPP i HVSP), 8kB pamięć Atmegi8 okazała się niewystarczająca i nie weszły wszystkie wodotryski…

    Jako, że pisałeś oprogramowanie w BASCOM Basic-u to niestety miało prawo się nie zmieścić wszystko. Proponuję przepisać oprogramowanie w dialekcie C (AVR GCC). Jak wykazuje praktyka program wynikowy skróci się o jakieś o parę procent, uwalniając nieco pamięci do wykorzystania.

    pwlu10 wrote:
    "tani"? Przecież Atmega8 teraz nawet 15zł kosztuje

    Dlatego warto zdjąć klapki z oczu i rozejrzeć się za innymi układami z rodziny AVR, a nie tylko ATMega8/Tiny2313/Mega16. Staje się nudne oglądanie projektów robionych na jedno kopyto.
  • #18
    piotrva
    VIP Meritorious for electroda.pl
    ZbeeGin, racja, pisząc to miałem na myśli AVR PROG USB częściowo kompatybilny z stk500. AVR PROG USB posiada jedynie ISP.
    ja znalazłem atmega32 w cenie 8, także megi 8 nie opłaca się w ogóle kupować.
    Nadal ponawiam prośbę do autora o kody źródłowe, o ile chce je udostępnić
  • #19
    MasMas
    Level 16  
    Bardzo fajne urządzenie. Sam ostatnio "uwaliłem" m8 przez złe fuse zegarowe, ale naszczęście uratował mnie zewnętrzny RC. Urządzenie bardzo pomysłowe.
    Mam takie pytanie : W opisie pisze, że jeśli to wina lockbitów to trzeba dać zworkę, która pozwoli całkowicie wymazać pamięć... I tak się teraz zastanawiam. W lockbitach jest przecież ustawienie uniemożliwiające przeprogramowanie czy odczyt pamięci programu. To skoro autor (czyli teoretycznie każda osoba znająca się na elektronice) może wyczyścić te lockbity i dobrać się do procesora to po co jest takie zabezpeczenie ? Przed czym ono chroni, skoro można je tak łatwo wyłączyć ?
    A to jest tak , że jak się wyczyści te lockbity to również czyści się cała pamieć programu i dlatego nie można odczytać programu ?
  • #20
    piotrva
    VIP Meritorious for electroda.pl
    lockbity uniemożliwiają odczyt i programowanie uP
    maja one za zadanie zabezpieczyć oprogramowanie przed nieautoryzowanym kopiowaniem (np. kupujesz jakieś urządzenie, kopiujesz elektronikę, zczytujesz program i wgrywasz do nowego urządzenia).
    Lockbity można usunąć tylko poprzez Chip Erease, czyli kasowanie pamięci Flash i Eeprom układu, czyli dokładnie tak jak stwierdzasz na końcu.
  • #21
    PO.
    Level 20  
    Że Ci się chcialo :) ... Ja mam na pająka polutowane dwie podstawki - dip28 i dip40 i sobie potrzebne linie przestawiam zworkami a potem prosty wsad na trzy bajty i jeden odblokowuje drugiego (który którego to zależy od potrzeb). Reszta zabaw oczywiście w isp potem.
  • #22
    Duch__
    Level 31  
    PO. wrote:
    Że Ci się chcialo :) ... Ja mam na pająka polutowane dwie podstawki - dip28 i dip40 i sobie potrzebne linie przestawiam zworkami a potem prosty wsad na trzy bajty i jeden odblokowuje drugiego (który którego to zależy od potrzeb). Reszta zabaw oczywiście w isp potem.


    Mógłby kolega szerzej rozwinąć swoją myśl?
  • #23
    PO.
    Level 20  
    Duch__ wrote:
    PO. wrote:
    Że Ci się chcialo :) ... Ja mam na pająka polutowane dwie podstawki - dip28 i dip40 i sobie potrzebne linie przestawiam zworkami a potem prosty wsad na trzy bajty i jeden odblokowuje drugiego (który którego to zależy od potrzeb). Reszta zabaw oczywiście w isp potem.


    Mógłby kolega szerzej rozwinąć swoją myśl?


    Nie ma się czym chwalić, ale na życzenie...
    Opisy procków są w datasheetach, większość linii jest na tych samych pinach więc nawetnie potrzeba nadmiarowych linii robić, zaledwie jedna czy dwie, reszta zależy od tego, który procek wysyła.
    ISP wyprowadzone dla każdego osobno. Zworki od resetów. Sterowania resetu w tej chwili nie pamiętam który odblokowywałem, trzeba przelutować w razie czego albo też zworki dorobić. Diody sobie informacyjnie robiłem do zasilań, resetów i sygnalizacji. Zasilanie z kompa i z programatora isp, władowany do działającego procka program chwilę czeka i potem wysyła co trzeba do zablokowanego.
    Samo odblokowanie fusebitów to trzy bajty do wysłania + sterowanie. Ponieważ lockbitów nie da się i tak odblokować to chip erase można już potem robić po ISP.

    Używane do procków w tych obudowach tylko, więc oczywiście mniejsza funkcjonalność niż przedstawionego projektu.

    Myśl:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity
  • #24
    biglolo94
    Level 16  
    Świetny projekt.
    Właśnie mam zamiar uratować moją ATMEGE168, ale mam problem i prosiłbym autora o dokładne podanie ustawień fusebitów jakie zastosował w sercu całego układu, czyli ATMEGA8.

    Poniżej podaje moje ustawienie fusebitów.
  • #25
    raptor37
    Level 12  
    Witam,
    zrobiłem ten układ. Mam zablokowane 4 atmegi8. Gdy włożę pierwszą, po wciśnięciu przycisku żadna dioda się nie zapala, gdy włożę drugą pali się dioda czerwona (tak jakby tej atmegi wogle nie było), po włożeniu kolejnych dwóch atmeg zapala się dioda zielona. Jednak atmeg dalej nie da się zaprogramować. Próbowałem zobaczyć co wyrzuca na RS232, jednakże widać tylko krzaki. Prędkość próbowałem ustawić tak jak na stronie projektu 38000, jednak nie było możliwe ustawienie takiej prędkości. Ustawiłem więc 38400, dalej są krzaki...
    Płytkę sprawdzałem kilka razy, parę zwarć znalazłem, jednak to nic nie pomogło.
    Układ "doktora" również kilka razy programowałem.
    Fusy ustawiłem tak aby układ chodził na wewnętrznym generatorze 8MHz CKSEL=0100. Bit EESAVE zaznaczałem i odznaczałem w żadnym przypadku nie pomogło.
    Ma ktoś może jakiś pomysł co z tym układzikiem dalej zrobić? Co może być przyczyną?
  • #26
    Gostek
    Level 17  
    GruX wrote:
    Gostek wrote:
    Hmm, używane STK500 chyba będzie tańsze....


    Tak, i na pewno odblokujesz fusebity ;]


    :) A STK500 albo 600 to kiedyś miał? To są zestawy które maja wszystkie możliwości programowania... ( tzn prawie, bo PDI n.p. trzeba z AVRISP lub JTAGICE )
  • #27
    manekinen
    Level 29  
    Witam!
    Duch__ wrote:
    A może autor przerobił by program główny na jakiś inny procesor niż Atmegę8. Jak wiadomo ciężko ją dostać w rozsądnej cenie, a jest jeszcze wiele innych procków w obudowach DIP28, o identycznej pinologi

    krzysiek_p wrote:
    Ja również popieram cytowanego - szczególnie, że już od dłuższego czasu nie używałem m8 i jedyna jaką mam już teraz jest wlutowana na stałe w analizatorze logicznym, więc nie wykorzystam jej. Mam za to 48 (która odpada ze wzgledu na flasha), 88 i 168. Miło by było złożyć sobie coś takiego, szczególnie, że mam m16 zablokowaną. No i jeszcze dochodzi możliwość wykorzystywania pinu reset uC jao gpio.

    piotrva wrote:
    I tu moja prośba, bo nie mam atmegi8, ale inne uP, czy mógłbyś więc zamieścić kody źródłowe oprogramowania? ew. kompilację pod atmega168 (taki uP wykorzystałbym do tych celów, mam zablokowanych parę meg2560

    ZbeeGin wrote:
    Staje się nudne oglądanie projektów robionych na jedno kopyto.


    Więc czemu atmega8? Jak zaczynałem projekt to układy te kosztowały 3,50zł/szt. Niefortunnie podrożały, trudno, nie będe teraz zmieniał płytki aby dopasować inny procesor. Oczywiście można zastosować Atmega88, 168, czy inny kompatybilny z odpowiednią ilością pamięci. Kodów źródłowych nie udostępniam, na życzenie mogę skompilować program pod inny procesor, według podesłanego schematu. Kompilowałem już na M88 i M32, zobaczcie w komentarzach na mojej stronce. Niestety autorzy tych komentarzy nie dali znaku czy programy prawidłowo działają (a nie testowałem ich w praktyce). Tak więc śmiało pisać, program przekompilować żaden problem.

    Natomiast jesli chodzi o jakiś wgląd w źródła, udostępniłem źródła poprzedniego układu "attiny fusebit doctor" obsługujacego jedynie malutkie procki z HVSP - można pobrać tutaj https://www.elektroda.pl/rtvforum/viewtopic.php?p=8055689#8055689 Cała inicjacja jest taka sama, zasada taka sama, jedyna różnica w transmisji szeregowej a nie równoległej.

    Jdsoul wrote:
    Czy tą zabawką da się odblokować procesor w obudowie TSOP - czy są jakieś projekty adapterów???

    Oczywiście, nie ma żadnych przeciwwskazań. Ale tak jak napisałem w opisie, adapterów pod SMD nie ma i raczej nie będzie. Będzie się trzeba podlutować bezpośrednio do układu lub stworzyć własny adapter, korzystając z projektu "pustego" adaptera umieszczonego w paczce.

    piotrva wrote:

    To jest tylko do ISP, gdzie są trzy linie. Takie rozwiązanie się sprawdza, wystarczy dobrze docisnąć układ do płytki. Natomiast tutaj gdzie mamy ponad 20 linii, będzie dużym problemem układ docisnąć tak aby wszystkie miały dobre połączenie :(

    piotrva wrote:
    cóż, najciekawszym rozwiązaniem, choć nie wiem czy to by się udało, byłby konwerter ISP->HVPP/HVSP

    Myślałem nad tym, nad taką przystawką tłumaczącą dla programatora ISP - stworzenie nie będzie trudniejsze od stworzenia takiego samodzielnego rozblokowywacza, a tym bardziej bazując się już na nim. Wystarczy odbierać komendy i adresy z ISP, rozpoznawać co które, i wysyłać dalej równolegle. Nie jestem pewien czy kolejność jest taka sama, być może są jakieś małe różnice.

    leonow32 wrote:
    Jak robisz napisy na płytkach? To jest toner pomalowany kalafonią z rozpuszczalnikiem? Jakim?

    Już kolega niżej dał link, dziękuję, tam wszystko ładnie wyjaśnione :)
    http://diy.elektroda.eu/plytki-drukowane-od-a-do-z/

    ZbeeGin wrote:
    Jako, że pisałeś oprogramowanie w BASCOM Basic-u to niestety miało prawo się nie zmieścić wszystko. Proponuję przepisać oprogramowanie w dialekcie C (AVR GCC). Jak wykazuje praktyka program wynikowy skróci się o jakieś o parę procent, uwalniając nieco pamięci do wykorzystania.
    Te komunikaty przez RS należy traktować raczej jako taki dodatek, i właśnie te wszystkie nazwy procków zajmują ogromną ilość flasha. Program optymalizowałem jak się dało, pytałem również tutaj na elektrodzie i bez rezultatu, programu nie udało mi się już bardziej zmniejszyć. O tutaj https://www.elektroda.pl/rtvforum/topic1684304.html jest temat. Widać fragment pokazujący w jaki sposób program "szuka" odpowiedniego procka po kolejnych bajtach sygnatury, niestety nie udało mi się tego inaczej rozwiązać, jeśli ktoś ma pomysł to może się podzielić ;)

    MasMas wrote:
    W opisie pisze, że jeśli to wina lockbitów to trzeba dać zworkę, która pozwoli całkowicie wymazać pamięć... I tak się teraz zastanawiam. W lockbitach jest przecież ustawienie uniemożliwiające przeprogramowanie czy odczyt pamięci programu. To skoro autor (czyli teoretycznie każda osoba znająca się na elektronice) może wyczyścić te lockbity i dobrać się do procesora to po co jest takie zabezpeczenie ? Przed czym ono chroni, skoro można je tak łatwo wyłączyć ?
    A to jest tak , że jak się wyczyści te lockbity to również czyści się cała pamieć programu i dlatego nie można odczytać programu ?

    Całkowicie wymazać pamięć, czyli usunąć wszystko. Po tym oczywiście odblokujesz zabezpieczenie i dobierzesz się do pamięci, ale co z tego jeśli będzie ona już pusta :) Te zabezpieczenie chronić ma wsad przed odczytem i skopiowaniem, a nie sam procesor przed ponownym przeprogramowaniem i wykorzystaniem :)

    PO wrote:
    Ja mam na pająka polutowane dwie podstawki - dip28 i dip40 i sobie potrzebne linie przestawiam zworkami a potem prosty wsad na trzy bajty i jeden odblokowuje drugiego (który którego to zależy od potrzeb). Reszta zabaw oczywiście w isp potem.

    O właśnie, od takiego czegoś zaczynałem :) Jest też w sieci mnóstwo takich dedykowanych układów (wraz z wsadami) do odblokowania tylko jednego modelu procesora. Układ taki wysyła tylko bajty z fusebitami, proste jak drut a jednocześnie pełni swoją rolę. Mój układ jest rozbudowany, różni się tym że odczytuje najpierw sygnaturkę żeby wiedział co naprawia, a po naprawie jeszcze fuski weryfikuje. Zmieszczenie prawie 100 sygnatur i fusków i obśługa tego jednak trochę miejsca zajmie w pamięci. A taki prosty układ który może sobie zrobić każdy to 15 minut z nosem w sekcji "parallel programming" noty katalogowej, polecam pobróbować :)

    biglolo94 wrote:
    Świetny projekt.
    Właśnie mam zamiar uratować moją ATMEGE168, ale mam problem i prosiłbym autora o dokładne podanie ustawień fusebitów jakie zastosował w sercu całego układu, czyli ATMEGA8.

    Poniżej podaje moje ustawienie fusebitów.

    :o załącznik w postaci 2MB BMP, człowieku! Tak czy siak ustawione źle, włącz jeszcze bit High G (czyli eesave) aby program nie kasował eepromu przy przeprogramowaniu.

    raptor37 wrote:
    Witam,
    zrobiłem ten układ. Mam zablokowane 4 atmegi8. Gdy włożę pierwszą, po wciśnięciu przycisku żadna dioda się nie zapala, gdy włożę drugą pali się dioda czerwona (tak jakby tej atmegi wogle nie było), po włożeniu kolejnych dwóch atmeg zapala się dioda zielona. Jednak atmeg dalej nie da się zaprogramować. Próbowałem zobaczyć co wyrzuca na RS232, jednakże widać tylko kszaki. Prędkość próbowałem ustawić tak jak na stronie projektu 38000, jednak nie było możliwe ustawienie takiej prędkości. Ustawiłem więc 38400, dalej są kszaki...
    Płytkę sprawdzałem kilka razy, pare zwarć znalazłem, jednak to nic nie pomogło.
    Układ "doktora" również kilka razy programowałem.
    Fusy ustawiłem tak aby układ chodził na wewnętrznym generatorze 8MHz CKSEL=0100. Bit EESAVE zaznaczałem i odznaczałem w żadnym przypadku nie pomogło.
    Ma ktoś może jakiś pomysł co z tym układzikiem dalej zrobić? Co może być przyczyną?

    Pierwszy i drugi układ jest prawdopodobnie martwy, 3 i 4 są dobre a sam układ doctora działa ropawidłowo, skoro zapala zieloną diodę to znaczy że dobrze odczytuje sygnaturkę - problem leży po Twojej stronie. Nie zaprogramowany lub źle zaprogramowany eeprom. NAJPIERW ustawiasz fusebit EESAVE a potem programujesz flash i eeprom odpowiednim plikiem. Co do prędkości 38400 to taka jest prawidłowa, wskaż proszę gdzie ja napisałem 38000 - może jakaś literówka
  • #28
    anelrob
    Level 11  
    Witam.
    Wykonałem układ według twojego projektu i działa znakomicie.

    mam tylko pytanie czy licznik który liczy naprawione mikrokontrolery daje jakieś ograniczenia czy to tylko taka informacja dodatkowa.

    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity
  • #29
    szymanczuk
    Level 2  
    Na szybko zbudowałem pająka żeby przetestować i przy okazji odblokować kilka AVR, u mnie pomogło z ATMEGA644p ATMEGA16, ATMEGA8, i tiny2313, więc projekt godny polecenia.
  • #30
    Duch__
    Level 31  
    manekinen wrote:

    Więc czemu atmega8? Jak zaczynałem projekt to układy te kosztowały 3,50zł/szt. Niefortunnie podrożały, trudno, nie będe teraz zmieniał płytki aby dopasować inny procesor. Oczywiście można zastosować Atmega88, 168, czy inny kompatybilny z odpowiednią ilością pamięci. Kodów źródłowych nie udostępniam, na życzenie mogę skompilować program pod inny procesor.


    No to poproszę pod atmegę 168. Nic nie mam do staracenia, a mogę odzyskać zablokowane procesorki.

    manekinen wrote:

    Co do prędkości 38400 to taka jest prawidłowa, wskaż proszę gdzie ja napisałem 38000 - może jakaś literówka


    Cytuje z twojej strony: "Na płytce dodatkowo znajduje się złącze opisane jako RS232, jest to wyjście USARTa, podłączając się pod nie (38000bps), dowiemy się wszystkiego o przebiegu operacji naprawy"