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

Problem z Attiny2313 - brak łączności - kontynuacja

markosik20 28 Nov 2007 00:57 2716 17
Computer Controls
  • #1
    markosik20
    Level 33  
    Pozwoliłem sobie na kontynuację zamknietego już tematu bo problem jest nie rozwiązany :wink:.
    A więc do rzeczy.
    Na pokładzie Attiny2313 programowany przez STK200 przez ISPProg Dybkowiskiego. Nadmieniam że tym programatorem i tym programem zaprogramowałem niejedną Atmegę czy '51. Programatora używam również jako Wigglera do ARM'ów.
    Problem jest taki że po wgraniu pewnego programu (raptem kilkaset bajtów) Attiny przestaje sie zgłaszać po ISP. Program to głównie ustawienie całego portu B i D na wyjście i wyrzucenie na nie inkrementowanych zmiennych. Ciekawe jest to że program się poprawnie wykonuje oraz bez problemu reaguje na reset z aplikacji na PC (tym twierdzeniem odrzucam wszystkie błędy w FuseBit itp.). Próby dokonałem na trzech Attiny (które są już "zablokowane"). Pisząc program (jak zwykle) zaczynam od prostych funkcji, wgrywam i sprawdzam. I w tym przypadku było podobnie. Po wgraniu zmienionego programu w pewnym momencie uK przestał odpowiadać po ISP. Po włożeniu drugiego w podstawkę zmieniłem FuseBity na kwarc zewnętrzny. Kilka razy odłączyłem zasilanie, zresetowałem i Attiny się pieknie zgłasza :wink:. Wgrywam ostatnią wersję programu i bach....program chodzi, Attiny się nie zgłasza :(.
    No to włożyłem trzeci powróciłem do starszej wersji programu :wink: i wgrałem go chyba ze 50razy.....wszystko w porządku Attiny sie złasza program chodzi (miga LED na PD0). Wgrałem tą nieszczęsną wersję i.....cisza :-(. Zostaly mi jeszcze dwie Attiny więc chciałbym wspólnymi siłami dojść co jest nie tak. Załączam przekompilowany plik.hex (spakowany) oraz żródło w C (może ktoś u siebie spróbuje :wink:.
    Z pozdr.
    MK
    PS: Attiny to wersja 20PU - DIP20.
  • Computer Controls
  • #2
    arturt134
    Level 27  
    Po pierwsze, sprawdź plik io.h. Zdarzyło mi się kiedyś, że w pliku z definicjami rejestrów, dostarczonym przez producenta procka, był błąd i zapisywałem coś nie pod ten adres co trzeba.

    Po drugie, jeżeli nie masz zewnętrznego kwarca, to spróbuj go dołączyć. Z jakiegoś powodu zdarzyło mi się kiedyś, że ATTiny2313 przestał odpowiadać po ISP (był puszczony z wewnętrznego oscylatora RC). Po kilku nieudanych próbach dołączyłem zewnętrzny kwarc i nawiązałem połączenie. Po ponownym zaprogramowaniu odłączyłem kwarc i było OK.

    A po trzecie, to dobrze byłoby, żebyś do kodu dołączył definicję makra _BV(), schemat, plik io.h.
  • #3
    markosik20
    Level 33  
    arturt134 wrote:
    Zdarzyło mi się kiedyś, że w pliku z definicjami rejestrów, dostarczonym przez producenta procka, był błąd i zapisywałem coś nie pod ten adres co trzeba.


    A co to ma wspólnego z tym że procek nie zgłasza się po ISP?
    Mnie nie chodzi o poprawność w działaniu programu.
    Kwarc jest podłączony na stałe.
    W fabrycznej aplikacji pracował AT89C2051 i okazało się że wystarczy zmodyfikować jedynie RESET i Attiny2313 idealnie tam pasowała.
    Pod cały port B podpięty jest wejście 74HCT573, pod RXD max232 i jeszcze dwa piny do sterowania zatrzaskiem (nie pamiętam teraz które).

    Jeżeli widzicie problem w programie to mam pytanie:
    Czy sam program może być powodem "wyłączenia" ISP w Attiny?
  • Computer Controls
  • #4
    User removed account
    User removed account  
  • #5
    markosik20
    Level 33  
    W starym programie brak zadeklarowanej tablicy w pamięci programu oraz ustawiam tylko jeden pin PD0 jako wyście na LED'a. W nowym jest tablica oraz cały portB i D jest ustawiony jako wyjście.
    Zasilanie nie ma prawa siadać, zresztą sprawdzone, wysterowanie każdej lini z programatora sprawdzone, jest piękne +5V lub ~0,1V. Moim zdaniem program nie ma tu żadnego znaczenia bo przecież przy odczycie sygnatury resetujemy procka. Chyba że się mylę, już sam nie wiem :-(.
    Może ustawienie całego portuB (gdzie są linie ISP) jako wyjście jest problematyczne? Nie chcę za bardzo kombinować bo jak pisałem zostały mi jeszcze dwie sztuki.
  • #6
    User removed account
    User removed account  
  • #7
    seba_x
    Level 31  
    w fusach masz reset jako "reset" czy "PA2" ?
  • #8
    kamyczek
    Level 38  
    A poustawiałeś dzielnik zegara ? Czy masz kwarc 4M dzielnik przez 8 i proc pracuje 500kHz ? Moze wystarczy ustawić pedkość magistrali spi w programatorku na 100kHz albo mniej ...
  • Helpful post
    #9
    szymtro
    Level 30  
    W to że uP zablokuje sam sobie isp nie uwierzę.
    Zrób test.
    Wyłącz totalnie zasilanie całej płytki uK. Zewrzyj reset tak aby cały czas resetowany był uK i zobacz wtedy.
    Jak ruszy to masz problem projektowy - coś podpięte równolegle do pinów isp jest w pewnym momencie tak wysterowane że zwiera piny isp uK.
  • #10
    markosik20
    Level 33  
    szymtro wrote:
    W to że uP zablokuje sam sobie isp nie uwierzę.

    Ja też nie wierzę :wink:.
    Dzięki koledze szymtro udało mi się "odblokować" (no nie wiem jak to nazwać) Attiny. Juz opisuję jakie u mnie jest zajwisko. Musiałem reset przylutować na stałe do masy i Attiny się zgłosiła. Ciekawe jest to że napięcia z programatora są idealne +5,1V dla "1" i ~0,02V dla "0" a nie mam oscyloskopu żeby sprawdzić co się dzieje podczas załączania napięcia na pinie RESET (nawet jak w programie ISPProg reset jest już załaczony). Fakt jest jeden - żeby Attiny sie zgłosiła trzeba jej było przylutować na stałe GND na RESET. Po wykonaniu kilkunastu eksperymentów doszedłem do ciekawego wniosku (na każdym z pięciu uC ten sam). Problem jest z wykonaniem takiego kodu

    Code:
    DDRB = 0x80;
    
    PORTB = 0x80;


    Jest to pin SCK dla ISP. Jako że mam Attiny na podstawce poprostu pozostawiłem ten pin w powietrzu i przylutowałem do niego sygnał SCK z programatora. Za każdym razem jak program ma wykonać takie ustawienia jak wyżej w kodzie Attiny już sie ponownie nie zgłosi i trzeba wtedy przylutować GND na stałe do pinu RESET.
    Dlaczego tak jest...nie wiem :-( .

    A co do
    kamyczek wrote:
    A poustawiałeś dzielnik zegara ? Czy masz kwarc 4M dzielnik przez 8 i proc pracuje 500kHz ? Moze wystarczy ustawić pedkość magistrali spi w programatorku na 100kHz albo mniej ...


    Jakąbym nie ustawił prędkość w programie obsługującym ISP PRog to jak wszystko jest OK to AVR'y zawsze mi się zgłaszały :wink:.

    Dzieki za wszelkie uwagi.
  • #11
    zumek
    Level 39  
    Spójrz na schemat oryginalnego STK200/300.Nie trudno zauważyć , że sygnał RST wykorzystuje 3 bufory połączone równolegle.Podobnie jest z SCK - 2 bufory.Jak myślisz , czy to przypadek :?:

    Piotrek
  • #12
    markosik20
    Level 33  
    zumek wrote:
    sygnał RST wykorzystuje 3 bufory połączone równolegle

    Hmm, co racja to racja ale ja mam dodatkowo na sterowaniu pinem RESET tranzystor, więc teoretycznie mogę "przepuścić" przez programator z tego pinu 100mA. A jak uC się już zresetuje to jego piny z ISP powinny już "wisieć w powietrzu" ?
    Tutaj schemat (nie jest to może oryginalny STK200 ale prawie identyczny :wink: ). Opisy pinów są dla JTAGA więc prosze sie nimi nie sugerować. Jedynie sygnał RST jest taki sam.
  • #13
    zumek
    Level 39  
    Hmm... Ale w takim układzie jak Twój , pin RESET ma odwrotną polaryzację :| Czy masz zaptaszkowaną w ISPProg-u opcje Inverted reset :?:

    Piotrek
  • #14
    markosik20
    Level 33  
    zumek wrote:
    Czy masz zaptaszkowaną w ISPProg-u opcje Inverted reset :?:


    Dokładnie , bez zaptaszkowania nie ma programowania :wink:.
  • Helpful post
    #15
    majekw
    Level 13  
    markosik20 wrote:
    Zasilanie nie ma prawa siadać, zresztą sprawdzone, wysterowanie każdej lini z programatora sprawdzone, jest piękne +5V lub ~0,1V.


    Sprawdzałeś na SCK i wyjściu sterującym tranzystor przy zawieszeniu się?
    Wygląda na to, że płynie sobie duży prąd (jak na te scalaki), po SCK (tiny wyjście 1, SCK=0) i napięcie wewnątrz któregoś scalaka siada, co albo nie wysterowuje już reseta (o ile w 244), albo cały procek głupieje i nie daje się programować (o ile w tiny).
    Na szybko, to zwiększ po prostu R3(?, ten od SCK) w programatorze (może nawet do 1k) i sprawdź.
  • #16
    markosik20
    Level 33  
    majekw wrote:

    Wygląda na to, że płynie sobie duży prąd (jak na te scalaki), po SCK (tiny wyjście 1, SCK=0) i napięcie wewnątrz któregoś scalaka siada, co albo nie wysterowuje już reseta (o ile w 244), albo cały procek głupieje i nie daje się programować (o ile w tiny).
    Na szybko, to zwiększ po prostu R3(?, ten od SCK) w programatorze (może nawet do 1k) i sprawdź.


    BINGO!!! :-). Zawsze twierdzę że co wiele głów to niejedna a na najprostsze rozwiązanie czasami ciężko wpaść :wink:.
    Wniosek jeden:
    Wystarczyło zwiększyć rezystor do 500Ω aby ograniczyć "prąd zwarcia" między programatorem a uC w chwili resetu (jutro przelutuje wszystkie w programatorze).
    Jednak zastanawia mnie jeszcze cały czas jeden szczegół. Skoro najpierw podaję sygnał reset na uC (nawet "czyste" GND) a później próbuję odczytać sygnaturę to czy wszystkie piny portów używanych jako I/O nie powinny wejść w tryb wysokiej impedancji?? No i wtedy nie powinno być "zwarcia". A wyraźnie widać że RESET działa prawidłowo bo program przestaje się wykonywać. I dlaczego tak się dzieje tylko na SCK?? :wink:.
  • #17
    majekw
    Level 13  
    Jak nie przylutujesz reseta do gnd, to po podłączeniu zasilania procek robi swoje. W międzyczasie robi Ci się 'zwarcie' i już nie masz szans na poprawne wystawienie reseta. I dlatego też czyste procki się spokojnie programują, a problem masz z 'brudnymi' :-)
  • #18
    markosik20
    Level 33  
    majekw wrote:
    W międzyczasie robi Ci się 'zwarcie' i już nie masz szans na poprawne wystawienie reseta.


    Ale podczas pracy bez problemu się resetuje i program zaczyna od początku. Chyba że jest to swego rodzaju "reset oszukany" :wink:.
    Przylutowałem nawet "na żywca" podczas pracy to gnd i też nie pomogło. Widocznie jest jak piszesz, nastapiło "zwarcie" w Attiny i już nie umiała sobie wysterować odpowiednio pinów pod obłsugę ISP.