Elektroda.pl
Elektroda.pl
X
Metal Work Pneumatic
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

manekinen 17 Lip 2010 17:15 169642 342
  • #31 17 Lip 2010 17:15
    manekinen
    Poziom 29  

    anelrob napisał:
    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

    Tzn jakie ograniczenia? Nie ma żadnych ogranicznień, to po prostu licznik, po każdej prawidłowej naprawie zwiększa się o 1, po dojściu do 65535 po prostu zacznie od zera. O ile dobrze pamiętam to jego wartość jest przechowywana w dwóch ostatnich komórkach pamięci eeprom.

    szymanczuk napisał:
    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.


    Dzięki, proszę zgłaszać co się udało naprawić a co nie, listę będe uzupełniał i ewentualnie powstaną jakieś poprawki w razie problemów :)

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

    W załączniku kod wynikowy, daj znać czy działa...

    A na stronce faktycznie miałem literówkę, oczywiście powinno być 38400, już poprawione :)

    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz pendrive 32GB.
  • Metal Work Pneumatic
  • #32 17 Lip 2010 18:43
    Kamlo
    Poziom 14  

    Witam

    Przepraszam autora wątku że wpierdzielam się tak z swoimi kodami (jeśli będzie przeszkadzało to wyedytuje i stworze osobny wątek) lecz piszę apropo aktualnego tematu naprawy mikroprocesorów z poziomu procesora innego niż Atmega8.
    Mam dwie zablokowane sztuki AT8 i aby je odblokować musiał bym kupić 3 i zbudować twój układ co dla mnie jest raczej nieopłacalne, mimo wszystko gratulacje za pierwszoplanowy projekt wśród fusedoctorów.
    W związku z powyższym postanowiłem zgodnie z aplikacją atmega8 odblokować je za pomocą attiny 2313 i tak powstał kod który udostępniam na dole, całość połączona na płytkach stykowych (co widać na dołączonym zdjęciu TUTAJ), schematu nie rysowałem bo myślę że wystarczą same opisy połączeń. A wyglądają one tak:

    Attiny 2313(doktor) <> Atmega8(pacjent)

    Sygnały sterujące
    PD0 <> BS1 (PD4)
    PD1 <> BS2 (PC2)
    PD2 <> XA0 (PD5)
    PD3 <> XA1 (PD6)
    PD4 <> XTAL1 (PB6)
    PD5 <> do LED przez rezystor do GND
    PD6 <> WR (PD3)

    Szyna danych
    PB7 <> PC1
    PB6 <> PC0
    PB5 <> PB5
    PB4 <> PB4
    PB3 <> PB3
    PB2 <> PB2
    PB1 <> PB1
    PB0 <> PB0

    -Dodatkowo w Atmega8(pacjent) OE(PD2) oraz PAGEL(PD7) odrazu do GND
    -Port RDY/BSY (PD1) można połączyć przez rezystor do led, sygnalizuj ona wejście w tryb programowania czyli praktycznie cały czas świeci.
    -Zasilanie obu układów 5V i przygotowane zasilanie 12V potrzebne do wejścia w stan programowania
    -Zasilanie przygotowane ta aby dopiero po włączeniu doktora(attiny) można było ręcznie włączyć zasilanie do pacjenta 5V do VCC i AVCC oraz 12v do RST
    -Oba układy bez kwarców

    Wszystko zrobione według aplikacji Atmega8 (memory programming) i powinno działać i co ??
    NIE DZIAŁA, albo gdzieś popełniłem błąd albo moje AT8 są zablokowane na amen, choć wchodzą w stan programowania. Więc zwracam się z prośbą jeśli ktoś miałby ochotę sprawdzić z grubsza w czym tkwi problem, to będę bardzo wdzięczny, kod mimo że trochę nieelegancki to jest w większości opisany komentarzami tak aby nie trzeba było zbyt wiele kombinować.

    W załączniku oprócz kodu znajdują się już dwa skompilowane hexy, to nic innego jak dwa sposoby wchodzenia w stan programowania (aplikacja s228):

    -AT8N_init1.hex sposób pierwszy:
    Czyli po włączeniu układów gdy dioda(podpięta do attiny) świeci należy reset pacjenta(at8) przyłączyć do gnd
    Gdy dioda zacznie migać należy przełączyć reset na 12V
    Pamiętając że na obie operacje mamy około 10 sekund (w ramach świecenia/migania diody)
    ? Między tymi czynnościami attiny musi zmienić sygnał XTALL parę razy dlatego tak to wygląda.

    AT8N_init2.hex sposób drugi:
    Czyli najpierw włączamy do 5V lekarza(attiny) który ustawia odpowiednie stany na nóżkach, gdy dioda (podłączona do attiny) zacznie migać(praktycznie odrazu) włączamy pacjenta VCC i AVCC(at8) do 5V oraz RST do 12V.
    -nie gryzmolić się z tym włączaniem , należy zmieścić się w (czas migania led)

    ps. z ewentualnymi pretensjami dotyczącymi zaśmiecania wątku pisać nie krępować się, tak jak powiedziałem, zrozumiem i założę własny, tym tylko chciałem się wstrzelić w aktualny temat.

    Pozdrawiam

  • #33 17 Lip 2010 19:08
    lucastg
    Poziom 13  

    Jeżeli ktoś będzie zabierał się za wykonywanie oryginalnej płytki do układa proszę o info na priw .

  • #34 17 Lip 2010 20:35
    PO.
    Poziom 20  

    Tak na szybko: po komendzie write fuse dla low byte powienieneś zerować xa1 i xa0 a je zamieniasz - chyba że w a8 jest inaczej ;) (podglądam swój od a16), fuse high tak samo.

  • #35 17 Lip 2010 20:40
    raptor37
    Poziom 12  

    Ja u siebie mam ustawiony bit EESAVE, pamięć danych (flash) i pamięć EEPROM mam wgraną. Jednak w dalszym ciągu przez RS232 wywala mi krzaki, włąśnie przy prędkości 38400. A jeszcze takie pytanie do autora projektu. Co oznacza zapalenie zielonej diody? Czy tylko odczytanie sygnatury, czy również sprawdzenie poprawności zaprogramowania nowych fusebitów?

  • #36 18 Lip 2010 08:32
    Kamlo
    Poziom 14  

    PO. napisał:
    po komendzie write fuse dla low byte powienieneś zerować xa1 i xa0 a je zamieniasz - chyba że w a8 jest inaczej

    Sprawdzałem niestety to nie to:
    Code:

    C. Load Data Low byte
    1. Set XA1, XA0 to "01". This enables data loading.
    2. Set DATA = Data Low byte (0x00 - 0xFF).
    3. Give XTAL1 a positive pulse. This loads the data byte.

    Zerowanie jest przy Load Address Low byte ale adresu przy fuskach (chyba ?) nie musimy wysyłać, przynajmniej nic takiego nie widziałem w aplikacji.
    No nic, będzie trzeba poczekać parę miesięcy na nową i (tanią) serie at8 od atmela i zbudować główny układ tego wątku, z ciekawości czy on odblokuje te kostki.

  • #37 18 Lip 2010 09:37
    PO.
    Poziom 20  

    Aaa, bo widzisz, w datasheecie od a16 jest ładny rysunek 131 na którym przebiegi nie zgadzają się z opisem. Właśnie się przegryzam dalej ;) .

    PS: Dobra, takie moje obserwacje:
    nie czekasz na rdy/bsy tylko jedziesz po delayu z miganiem - powinien być dłuższy ale nie wiesz czy się coś dzieje czy nie...
    jak dajesz impuls na wr czy xtal to daj kilka nopów, niech się zdąży pin przeładować.

    Porównuję sobie datsheety od a8 i od a168 i w jednym każą machnąć 6x xtal a w drugim czekać 20us :) np... A niby powinny się programować tak samo...
    Jest dodatkowa procedura awaryjna:

    Cytat:
    Note, if the RESET pin is disabled by programming the RSTDISBL Fuse, it may not be possible
    to follow the proposed algorithm above. The same may apply when External Crystal or External
    RC configuration is selected because it is not possible to apply qualified XTAL1 pulses. In such
    cases, the following algorithm should be followed:
    1. Set Prog_enable pins listed in Table 92 on page 227 to “0000”.
    2. Apply 4.5 - 5.5V between VCC and GND simultaneously as 11.5 - 12.5V is applied to
    RESET.
    3. Wait 100 ns.
    4. Re-program the fuses to ensure that External Clock is selected as clock source
    (CKSEL3:0 = 0’b0000) and RESET pin is activated (RSTDISBL unprogrammed). If Lock
    Bits are programmed, a chip erase command must be executed before changing the
    fuses.
    5. Exit Programming mode by power the device down or by bringing RESET pin to 0’b0.
    6. Entering Programming mode with the original algorithm, as described above

    W zwykłej procedurze nie musisz robić chip erase, zrobisz to sobie z isp.

    Nie wiem jak szybkie masz ręce z tym podłączeniem resetu i zasilania :) , dla a8 każą to robić "simultanously" a dla 168 w przedziale 20-60us więc pogratulować ;) .
    Rozumiem, że tak samo wychodzisz z trybu programowania, przez wyciągnięcie wtyczki.
    Podłącz się przez tranzystory i steruj sobie z programu jedno i drugie, będziesz wiedział, że na pewno robi to co ma robić.


    Aha, nie ma sensu podawać zmiennych w hexie skoro i tak rozpisujesz sobie na bity obok, podawaj binarnie, 0b zamiast 0x.
    Nie liczę Ci fusów, sprawdziłeś że ustawiasz to co chcesz? 0 programuje, 1 kasuje bit więc wrzucasz negatyw tego co chcesz mieć ustawione.


    Tyle mi w oko wpadło, staram się znaleźć wszystko co może być nie tak :P , jakoś najpradopodobniejsze wydają mi się te opóźnienia.

  • #38 18 Lip 2010 10:39
    Duch__
    Poziom 31  

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

    W załączniku kod wynikowy, daj znać czy działa...


    Niestety nie działa. Ale nie wiem czy przypadkiem nie jest to wina mojego układu który przerobiłem na SMD (może gdzieś się palnąłem przy lutowaniu). Tak więc wykonał układ jeszcze raz ale metodą przewlekaną.

    Aha, co zauważyłem. Ja programuje układ przez AVR-Burn-O-Mat. Zdziwiło mnie to że na Atmegę8 twój wsad zajmuje 8kb, a na atmegę168 aż 10kb, a nie powinno być tak dużej różnicy przy zmianie w programie sygnatury urządzenia. Zmieniałeś coś jeszcze?

    Czym ty wrzucasz wsad na procka? Możesz przy okazji zrobić screena z ustawieniami fusebitów?

  • Metal Work Pneumatic
  • #39 18 Lip 2010 11:24
    manekinen
    Poziom 29  

    Kamlo napisał:
    Wszystko zrobione według aplikacji Atmega8 (memory programming) i powinno działać i co ??
    NIE DZIAŁA

    Błąd w połączeniach, nie bez powodu u siebie każdą linię łączyłem poprzez rezystor. Nawet napisane jest o tym w nocie, że gdyby pacjent nie wszedł w tryb programowania lub pojawiły się inne problemy, a doktor będzie robił swoje, to mamy piękny konflikt stanów na liniach i popalone porty.

    Tak samo linie "prog enable" należy zwolnić zaraz po tym gdy pacjent wejdzie w tryb programowania, bo tutaj również może wystąpic konflikt na liniach (w którejś nocie wyczytałem) - u Ciebie PAGEL jest na stałe do GND.

    Największy BYK... OE to linia Output Enable - czyli ściągając ją w dół, szyna danych pacjenta pracuje w roli wyjścia - u Ciebie cały czas do GND więc jakim cudem chcesz cokolwiek przesłać do pacjenta skoro jego piny są wyjściami? Sprawdź czy nie popaliłeś tych portów już :(

    Kolejna rzecz, załączanie resetu. Powinno się to raczej odbywać wg tego co podano w nocie, czyli zasilanie, 100us, prog enable, 100ns, reset, 100ns. To są czasy minimalne, ja dawałem dwa razy więcej. U Ciebie reset załącza się ręcznie, nie wiem jak procek na to zareaguje. Być może stan wysoki na RDY może być przypadkowy, może wykonuje się jakiś kod - a procek nie wszedł w ogóle w tryb programowania.

    Dodatkowo, tak jak napisał PO., W różnych notach te sekwencje odpalania trybu programowania wyglądają nieco inaczej. Inne są czasy, inna kolejność, a w starszych prockach NIBY trzeba machnąć kilka razy zegarem przed rozpoczęciem czegokolwiek - nie trzeba ;) Tak że chyba znalazłem aż 4 różne, ale zastosowałem tylko jeden bo wszystkie testowane procki ładnie się uruchamiały. O ten:

    Code:

    1. Set Prog_enable pins listed in Table 27-12 on page 291 to “0000”, RESET pin to 0V and
    VCC to 0V.
    2. Apply 4.5 - 5.5V between VCC and GND.
    (Ensure that VCC reaches at least 1.8V within the next 20 µs.) - //nie koniecznie, nie mamy jak tego sprawdzić//
    3. Wait 20 - 60 µs, and apply 11.5 - 12.5V to RESET.
    4. Keep the Prog_enable pins unchanged for at least 10µs after the High-voltage has been
    applied to ensure the Prog_enable Signature has been latched.
    5. Wait at least 300 µs before giving any parallel programming commands.

    Troszkę te czasy zwiększyłem i chodzi bardzo ładnie. To tyle z samego hardwaru, do kodu nie zaglądałem bo w C nie siedzę, niestety. Jak dla mnie nie przeszkadza tutaj Twój post, cieszę się że ktoś w ogóle zagląda w noty i próbuje własnych sił :)


    PO. napisał:
    W zwykłej procedurze nie musisz robić chip erase, zrobisz to sobie z isp.

    Akurat Chip Erase to chyba najprostsza rzecz jaką można sobie dodać na samym początku. Po tym obserwujemy stan na pinie RDY i jeśli pójdzie w górę to znaczy że komenda wykonała się prawidłowo i mamy już porządek z pinami Action i Byte Select - a z tymi sam miałem niezłe problemy. Dodam że bez jakiegoś wyświetlacza czy UARTa cienko widzę uruchamianie takiego czegoś :(

    Duch__ napisał:
    Niestety nie działa.

    Jakie objawy?
    Co do rozmiaru wsadu... Kod kompilowany pod M8 zajmuje 99% jej pamięci, a kompilowany (bez zmian) na M168 zajmuje 60% jej pamięci - bascom żyje własnym życiem ;) Dodatkowo w kodzie na M168 masz już wszystkie nazwy procków po RSie które nie weszły w M8.

    Nie wiem skąd takie problemy z fuskami, przecież wystarczy ustawić wewnętrzny generator i włączyć EESAVE. Reszta bez znaczenia.
    Programuję przez avrdude poprzez bascom. Używam też AVR-BURN-O-MAT, fuski:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

    Używam też mkAVR Calculator, polecam ściągnąć i wypróbować, fuski:
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

  • #40 18 Lip 2010 13:00
    Kamlo
    Poziom 14  

    Cytat:
    Największy BYK... OE to linia Output Enable

    Na szczęście tylko w opisie, oczywiście że OE na 1.
    Cytat:
    Tak samo linie "prog enable" należy zwolnić zaraz po tym gdy pacjent wejdzie w tryb programowania, bo tutaj również może wystąpic konflikt na liniach (w którejś nocie wyczytałem) - u Ciebie PAGEL jest na stałe do GND.

    Racja, niestety brakło mi pinów na malutkim attiny2313 myślałem że nie będzie to robiło aż takiego problemu.
    Cytat:
    Nie wiem jak szybkie masz ręce z tym podłączeniem resetu i zasilania Smile , dla a8 każą to robić "simultanously" a dla 168 w przedziale 20-60us więc pogratulować

    Cytat:
    Kolejna rzecz, załączanie resetu. Powinno się to raczej odbywać wg tego co podano w nocie, czyli zasilanie, 100us, prog enable, 100ns, reset, 100ns. To są czasy minimalne, ja dawałem dwa razy więcej. U Ciebie reset załącza się ręcznie, nie wiem jak procek na to zareaguje.

    Jak wyżej sterowanie zasilaniem wymaga dodatkowych pinów (doktora) których niemiałem dlatego próbowałem ręcznie, a jak widać jednak czasy przełączeń są ważne w tej operacji.

    Sugerowałem się układem ręcznego programatora, http://www.ksw-funcard.civ.pl/FunCard/o_ukladzie.htm tam wszystkie czynności autor wykonuje ręcznie, widocznie nowych avr już tak się nieda łatwo oszukać.

    Wnioski: do sukcesu brakło kilku portów w attiny2313(taki tylko miałem pod ręką) którymi mógłbym sterować zasilanie, reset, oe oraz pagel (pacjenta), a najlepiej gdyby było ich jeszcze więcej na podpięcie lcd tak jak kol ~manekinen zasugerował aby mieć wgląd w cały proces.

    Dziękuje kolegą ~manekinen oraz PO. za zainteresowanie się problemem
    Pozdrawiam.

  • #41 18 Lip 2010 13:25
    manekinen
    Poziom 29  

    Kamlo napisał:

    Na szczęście tylko w opisie, oczywiście że OE na 1.

    No w górę tak, dla samego zapisu. Ale gdy chcesz cokolwiek odczytać z pacjenta, to już musisz kierunkiem sterować ściągając ją w dół na czas odczytu.
    Jeśli będą jakieś wątpliwości chętnie pomogę, proszę pytać.

    gufim napisał:
    Witam wszystkich poskladalem Doktora i udalo mi sie odblokowac moje Atmegi tak wyglada pozyteczny uklad nie tylko dla tych Atmeg ktore udalo mi sie rozblokowac dzis ale bardzo sie przyda w przyszlosci

    No to taka wersja partyzancka, radzę dać rezystorki na wszystkie linie - czemu? Czytaj post wyżej. Cieszę się że działa, jak widać może warto zainwestować te kilkanaście złotych w atmegę8 żeby odzyskać inne poblokowane - koszt się zwróci :) A jeśli układ się podoba, można zagłosować u góry strony ;)

  • #42 18 Lip 2010 13:55
    gufim
    Poziom 10  

    gufim napisał:
    Witam wszystkich poskladalem Doktora i udalo mi sie odblokowac moje Atmegi tak wyglada pozyteczny uklad nie tylko dla tych Atmeg ktore udalo mi sie rozblokowac dzis ale bardzo sie przyda w przyszlosci

    No to taka wersja partyzancka, radzę dać rezystorki na wszystkie linie - czemu? Czytaj post wyżej. Cieszę się że działa, jak widać może warto zainwestować te kilkanaście złotych w atmegę8 żeby odzyskać inne poblokowane - koszt się zwróci :) A jeśli układ się podoba, można zagłosować u góry strony ;)[/quote]

    Owszem moze i partyzancka wersja ale dziala co do rezystorow to moze na tym zdjeciu nie widac ale sa wszsystkie zgodnie ze schematem i pozniejszymi poprawkami , a co do glosowania to juz zaglosowalem i fakt warto zainwestowac pare zloty myslac przyszlosciowo

  • #43 18 Lip 2010 13:55
    anko6
    Poziom 9  

    Wykonałem programator równoległy ze strony http://elm-chan.org/works/avrx/report_e.html.. Uratowałem 2 szt.m162 i jeden m8. Mam kłopot z drugą m8. Otrzymuję informację, ze nie może odczytac sygnatury i dostep do procka nie jest możliwy. Czy tym "doctorem" jest możiwość naprawienia uszkodzonej sygnatury czy procek jest do kosza. Prawdopodobnie uszkodzenie powstało przez wyciąganie procka z układu typu "pająk" pod napięciem 5V.

  • #44 18 Lip 2010 14:44
    manekinen
    Poziom 29  

    gufim - a faktycznie są rezystorki, nie zauważyłem :)

    anko6 - układ leczy fuski, ale cudów niestety nie potrafi. Tej drugiej możesz się pozbyć bo jest martwa. Sygnatury nie da się zmienić, nie ma takiej możliwości.

  • #45 18 Lip 2010 21:00
    inventco.eu

    Poziom 29  

    Witam.
    Zrobiłem kopię tego urządzenia.
    Działa super od pierwszego uruchomienia.
    Odblokowałem sobie ATMEGE16 i ATMEGE32 (ubite przez mój błąd w CODEVISION)
    Dzięki.
    Ode mnie duży +
    W załączniku znajduje się fotka mojej płytki, podstawek nie miałem pod ręką to poskładałem z 2-ch :-)

    Pozdrawiam.
    Marek

    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity


    Ach, byłbym zapomniał.
    procedura programowania (zapisu)
    najpierw ustawiłem ATMEGE8 na wewnętrzny RC 8MHz + 0
    następnie zapisałem plik hex do pamięci uC.
    potem zapisałem plik EEP.
    na koniec zaznaczyłem bit EESAVE

  • #46 18 Lip 2010 23:16
    manekinen
    Poziom 29  

    Najważniejsze aby NIE zrobić tak:
    1.eeprom
    2.flash
    3.eesave
    Bo bez bitu eesave, przy wgrywaniu flasha, zwartość wcześniej zapisanego eepromu zostanie usunięta. Nie podawałem tego wcześniej bo wydawało mi się że jest to sprawa oczywista, ale skoro jest to układ dla osób które omyłkowo zablokowały procesor przez złe ustawienie fusebitów, to chyba taka informacja się przyda ;) Screeny z fusebitami są nieco wyżej.

  • #47 19 Lip 2010 20:20
    anko6
    Poziom 9  

    W poprzednim poście pisałem że programator równoległy przy każdym wpisywaniu polecenia "avrpp -r" odczytywał inną wartość sygnatury i dalszy dostęp do zmian fusebitów i programowania był zablokowany. Miałem nadzieję że Atmega Fusebit Doctor uratuje mi procka, ale niestety Twórca tego wspaniałego urządzenia rozwiał moje nadzieje. Już miałem wrzucić go do kosza ale zaświtała mi myśl, że do płytki testowej z prockiem podłączę zewnętrzny generator 200kHz. Tak zrobiłem i ku mojemu zdziwieniu ożył. Ustawiłem właściwe fusebity i procek jest OK!. Na przyszłość przestroga NIE WKŁADAĆ I WYCIĄGAĆ PROCKA POD NAPIĘCIEM (5V). Ja tak często robiłem i dobrze było do czasu, ale nie wiadomo kiedy jakiś przypadkowy impuls czy pakiet impulsów podczas wyciągania z podstawki coś nie uszkodzi. W moim przypadku oprogramowanie nie mogło odczytać sygnatury ponieważ jeden z uszkodzonych fusebitów ustawił sie na zewnętrzny RC. Mam nadzieję, że kol Manekinen wybaczy mi, że pisałem nie na temat

  • #48 19 Lip 2010 20:45
    manekinen
    Poziom 29  

    Napisałem Ci że jest martwa, bo myślałem że próbowałeś podpinać generator lub rezonator - to chyba najprostsza próba odratowania procka, z resztą pisałem o tym na początku ;) W samoczynne przestawienie się fusków wierzę bo też mi się zdarzyło, przepięcia i zaniki zasilania podczas programowania potrafią zdziałać cuda, w tym zmienić sygnaturkę lub nieodwracalnie zmienić fuski :)

  • #49 20 Lip 2010 09:24
    PF
    Poziom 19  

    Może spróbujecie pomóc w mojej sprawie.
    Układzik złożony i działa wyśmienicie [ od pierwszego kopa odblokował M8 ] ALE :
    Po podłączeniu zasilania układ działa od razu , wciśnięcie guzika tak jakby go wyłączało i ponowne puszczenie włącza ponownie. Mam guzik chwilowy zwierający po wciśnięciu - może tu powinien być odwrotny ?!?. Dalej po włączeniu bez "chorego" układu jeden raz zaświeca się dioda czerwona. Po odłączeniu zasilania i ponownym jego włączeniu następuje martwa cisza, żadna z diodek nie świeci do momentu włożenia jakiegoś układu.

  • #50 21 Lip 2010 10:19
    piotrva
    Moderator na urlopie...

    Dzięki za kompilacje pod mega168, ale takie pytanko, czy wyprowadzenia zgodne z oryginałem na mega8, czy zmieniałeś coś jeszcze?
    jak znajdę więcej czasu to złożę to na płytce stykowej.
    ps. warto by było, gdybyś pomyślał nad taką przejściówką isp-hvsp/hvpp, bo to byłby wspaniały projekt, gdyż dużo osób posiada właśnie ISP, a nie chcą inwestować w cały programator HV, który daje większe możliwości
    EDIT: co do optymalizacji, ja pomyślałbym nad drugą wersją sterowaną z komputera, wtedy część operacji jak np. przypisywanie nazwy do sygnaturki itp. można by zrzucić na PC

  • #51 21 Lip 2010 10:23
    PO.
    Poziom 20  

    Na ISP nie można przestawić fusebitu SPIEN więc jak już robić to raczej pełne HVPP ;) . Albo po co pełne, wystarczy reblocker, żeby odpowiednio zabezpieczać swoje projekty, już przez ISP zaprogramowane :P .

  • #53 21 Lip 2010 16:04
    PO.
    Poziom 20  

    piotrva napisał:
    hmm, jesteś pewny, że nie można?? bo wydaje mi się, że to tylko zabezpieczenie Twojego programu, choć pewności w tej kwestii nie mam, a sprawdzać nie mam ochoty :D
    a przez SPI nie można zabezpieczyć na lock-bitach?? czy nie po to zostały one stworzone??


    Datasheet a16, s.160, uwagi pod tab.105:

    Cytat:
    Notes: 1. The SPIEN Fuse is not accessible in SPI Serial Programming mode.


    Oczywiście jeśli zrobimy translator to od strony procka on będzie dostępny tylko nie wiem co z oprogramowaniem, czy ono automatycznie też nie pozwala na dostęp do tego bitu bo wie, że i tak nie mamy szans.


    Kwestia tego co i jak zabezpieczamy jest indywidualna. Są firmy, które fizycznie upalą Ci cały port od programowania, żebyś nie mógł odblokować procka nieautoryzowanymi metodami ;) .

  • #54 21 Lip 2010 17:40
    manekinen
    Poziom 29  

    PF napisał:
    Po podłączeniu zasilania układ działa od razu , wciśnięcie guzika tak jakby go wyłączało i ponowne puszczenie włącza ponownie.

    Przycisk jest podpięty do pinu resetu, który właśnie w ten sposób działa i jest to normalne.
    PF napisał:
    Dalej po włączeniu bez "chorego" układu jeden raz zaświeca się dioda czerwona. Po odłączeniu zasilania i ponownym jego włączeniu następuje martwa cisza, żadna z diodek nie świeci do momentu włożenia jakiegoś układu.

    Po uruchomieniu układ czeka na stan wysoki na pinie RDY, gdy procesor nie jest włożony, to ten stan wysoki jest uzyskiwany przez wewnętrzny pullup i program kontynuuje działanie. To że mignie czerwona i zielona dioda to normalne bo dzielą one piny z liniami adresowymi XA0 oraz XA1. A czemu układ zachowuje się w ten sposób bez włożonego pacjenta - nie wiem - ale to już chyba najmniejszy problem ;) Być może napięcie narasta zbyt wolno i trzeba ustawić większe opóźnienie w fuskach. Układ powinien być resetowany przyciskiem "start" a nie poprzez odcięcie zasilania.

    piotrva napisał:
    Dzięki za kompilacje pod mega168, ale takie pytanko, czy wyprowadzenia zgodne z oryginałem na mega8, czy zmieniałeś coś jeszcze?

    Bez zmian, tylko kompilacja, no i tak jak wspomniałem program ten pokazuje wszystkie nazwy przez uart.
    piotrva napisał:
    ps. warto by było, gdybyś pomyślał nad taką przejściówką isp-hvsp/hvpp, bo to byłby wspaniały projekt, gdyż dużo osób posiada właśnie ISP, a nie chcą inwestować w cały programator HV, który daje większe możliwości

    Nie ma problemu, zrzutka forumowa, biorę trochę urlopu, i będzie układ ;) Kolego bardzo chętnie ale kompletnie nie mam czasu :(
    piotrva napisał:
    co do optymalizacji, ja pomyślałbym nad drugą wersją sterowaną z komputera, wtedy część operacji jak np. przypisywanie nazwy do sygnaturki itp. można by zrzucić na PC

    Zauważ wolny pin uartu - RX. To taka otwarta furtka pozwalająca na rozwój projektu, jest możliwość zrobienia w ten sposób że fuski będą wysyłane z komputera poprzez terminal :) Druga strona medalu: konieczność tworzenia przejściówek usb-uart itd, co podnosi koszta i skomplikowanie. Może kiedyś...

    A co do możliwości zmniany SPIEN poprzez ISP - producent może pisać co chce, polecam popróbować ;) Albo jak producent wytłumaczy to że sygnatura może się zmienić, skoro w notach pisze że jest to niemożliwe. A co do obsługi przez programy, myślę że nie będzie problemu. W jednej z nakładek na avrdude jest możliwość właśnie zmiany sygnatury a sam avrdude ponoć to umożliwia - nigdy mi to nie działało - ale możliwość jest :) Tutaj więcej http://www.swiatelka.pl/viewtopic.php?p=35126#35126

    Ponadto, układu nie testowałem z prockami w wersji "V" pracującej już od 1.8V.
    Dostałem ostatnio informację że w obecnym stanie są problemy z tymi prockami ponieważ napięcie zasilające pacjenta nie koniecznie spada poniżej tej wartości przy starcie i są problemy.
    Humberto zaproponował takie rozwiązanie - http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/comment-page-1/#comment-1052
    I podobno to naprawia problem, być może ktoś ma możliwość sprawdzić, to bardzo proszę.

  • #55 21 Lip 2010 18:35
    piotrva
    Moderator na urlopie...

    mówię o zmianie wartości bitu SPIEN poprzez SPI, gdyż u znajomego wykładowcy na AGH podobno (wiem to tylko z opowiadań) studenci zablokowali SPI w kilku uP właśnie korzystając z ISP do programowania. Wina leżała ponoć w oprogramowaniu, którym ustawiali fusebity, gdyż jako domyślną opcję wyłączało SPI...
    a sam nie chcę próbować, bo potem, żeby procki odblokować albo musiałbym montować układ z tego projektu, albo wcześniej włączywszy JTAGEN użyć takiego programatora

  • #56 31 Lip 2010 15:17
    manekinen
    Poziom 29  

    31.07.2010 - AKTUALIZACJA #3

    Wsad 2.04:
    -poprawiono kilka błędów
    -dodano obsługę nowych procesorów, łącznie 106 (138)
    -zmiana wewnętrznego zegara na 1MHz, baudrate UARTa to 2400bps

    UWAGA, FUSEBITY! Jeśli uaktualniasz wsad do 2.04, koniecznie zmień wartość wewnętrznego generatora na 1MHz. Jeśli wykonujesz układ od początku, jedyną rzeczą jaką musisz zrobić to włączenie bitu EESAVE – 1MHz jest już ustawiony fabrycznie.

    Pełna lista poniżej:
    1kB:
    AT90s1200, Attiny11, Attiny12, Attiny13/A, Attiny15
    2kB:
    Attiny2313/A, Attiny24/A, Attiny26, Attiny261/A, Attiny28, AT90s2333, Attiny22, Attiny25, AT90s2313, AT90s2323, AT90s2343
    4kB:
    Atmega48, Atmega48P/A, Attiny461/A, Attiny43U, Attiny4313, Attiny44/A, Attiny48, AT90s4433, AT90s4414, AT90s4434, Attiny45
    8kB:
    Atmega8515, Atmega8535, Atmega8, Atmega88, Atmega88P/A, AT90pwm1, AT90pwm2, AT90pwm2B, AT90pwm3, AT90pwm3B, AT90pwm81, AT90usb82, Attiny861/A, Attiny87, Attiny88, Attiny85, AT90s8515, AT90s8535
    16kB:
    Atmega16/A, Atmega16U2, Atmega16U4, Atmega16M1, Atmega161, Atmega162, Atmega163, Atmega164, Atmega164P/A, Atmega165/P/A/PA, Atmega168, Atmega168P/A, Atmega169/P/A/PA, Attiny167, AT90pwm216, AT90pwm316, AT90usb162
    32kB:
    Atmega32/A, Atmega32C1, Atmega323/A, Atmega32U2, Atmega32U4, Atmega32U6, Atmega32M1, Atmega324, Atmega324P/A, Atmega325, Atmega3250, Atmega325P, Atmega3250P, Atmega328, Atmega328P, Atmega329, Atmega3290, Atmega329P, Atmega3290P, AT90can32
    64kB:
    Atmega64/A, Atmega64C1, Atmega64M1, Atmega649, Atmega6490, Atmega640, Atmega644, Atmega644P/A, Atmega645, Atmega6450, AT90usb646, AT90usb647, AT90can64
    128kB:
    Atmega103, Atmega128/A, Atmega1280, Atmega1281, Atmega1284, Atmega1284P, AT90usb1286, AT90usb1287, AT90can128
    256kB:
    Atmega2560, Atmega2561

    Łącznie 106 obsługiwanych różnych procesorów.
    Ukośnik wraz z P/A/PA oznacza że dany procesor w nowszych wersjach ma nadal tą samą sygnaturę i fusebity, przykładowo zapis Atmega165/P/A/PA obejmuje procesory Atmega165, Atmega165P, Atmega165PA. Gdyby liczyć to wszystko osobno, tak jak ma to miejsce na listach różnych programatorów, to wyjdzie ich razem 138.


    Proszę zgłaszać błędy itp.



    Także jeśli ktoś zna jeszcze jakiś procesor obsługujący parallel lub serial programming, zasilany do 5V, to proszę pisać.

    Oto procesory które jeszcze znalazłem, które nie spełniają tych warunków i na 99% NIE będą obsługiwane:
    AT90scr100
    Atmega128rfa1
    Atmega16hva
    Atmega16hvb
    Atmega32hvb
    Atmega8hva
    Attiny4
    Attiny5
    Attiny9
    Attiny10
    Attiny20
    Attiny40

    :arrow: wsad HEX, BIN, oraz Eeprom HEX, BIN, dla programu wersja 2.04.

  • #58 08 Sie 2010 00:44
    manekinen
    Poziom 29  

    Witaj, zwykła emalia bezbarwna w spray'u. Więcej na ten temat znajdziesz TUTAJ

  • #59 18 Sie 2010 11:42
    manekinen
    Poziom 29  

    18.08.2010 - AKTUALIZACJA #4

    Wsad wersja 2.05:
    -nie ma potrzeby programowania eepromu
    -ulepszona obsługa 20-pinowych procków, w tym poprawiony błąd przy naprawie tiny26
    -ulepszone rozpoznawianie sygnatury, gdy pierwszy bajt wynosił 1E to układ uznawał ją za odczytaną poprawnie jednak zdarzały się procki które przedstawiały się jako 1E 1E 1E. Teraz dodatrkowo sprawdzany jest drugi bajt, musi się mieścić w zakresie h90 do h98
    -brak nazw procków po uarcie, po poprawkach miejsce skurczyło się tak że postawnowiłem całkiem je usunąć - w zamian nie musimy wgrywać eepromu :)
    -znowu zmiana prędkości uart, teraz na 4800. Poprzednia 2400 była po prostu zbyt wolna i program przez to zbyt wolno naprawiał

    FUSEBITY OD WERSJI 2.04 WYMAGAJĄ ZMIAN, CZYTAJ OPIS!

    (PS, w poprzedniej aktualizacji zapomniałem zmienić numerek wersji i układ przedstawiał się jako 2.03)

    W załączniku pliki HEX oraz BIN wsadu 2.05

    Kolejnych aktualizacji nie przewiduję, chyba że ktoś znajdzie jakieś błędy.

    I jeszcze zrzut z terminala... procek tiny2313 który właśnie zrobiłem dla znajomego, fuski ładnie uwalone bo wszystkie były FF... nie wiem jak on tego dokonał ;)
    Atmega Fusebit Doctor (HVPP+HVSP) - napraw fusebity

  Szukaj w 5mln produktów