logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

ATTINY13 programowany ISP dzialal a po DDRB = 0xFF nie wykry

lorak17 25 Lut 2008 21:41 2614 7
REKLAMA
  • #1 4845779
    lorak17
    Poziom 15  
    Posty: 165
    Pomógł: 4
    Ocena: 9
    Witam mam następujący problem:

    Zmontowałem poprawnie układ, programowałem go przez LPT (ISP)
    wszystko ładnie pięknie uruchomiłem kilka napisanych przez siebie programów aż do momentu w którym w programie nie dodałem
    linijek:

    DDRB = 0xFF;
    PORTB = 0xFF;

    Po przesłaniu programu do uP nie mam już komunikacji z uP poprzez ISP
    w ISP Programmer Dybkowskiego sygnatura jest FF,FF,FF

    Podejrzewam ze mój 'programator' nie może wymusić na pinie reset stanu niskiego i układ nie wchodzi w tryb ISP.

    Jeśli miał ktoś podobny problem i go rozwiązał był bym wdzięczny za jakieś sugestie.

    Wiem na 100% ze uP jest sprawny a sprawa jest związana z przełączeniem portu b na wyjście i ustawieniem samych jedynek.

    FUSEBITS nie ruszałem i były ustawione tak jak fabrykę opuszczają:)
  • REKLAMA
  • #2 4845829
    don diego
    Poziom 32  
    Posty: 1557
    Pomógł: 165
    Ocena: 63
    Tylko co ma wspólnego reset z portem B? Sprawdź PonyProgiem, czy uda Ci się nawiązać komunikację. Na 99% masz przestawione fuse bity albo coś namieszane w konfiguracji ISP Programmera.
  • REKLAMA
  • #3 4845838
    mirekk36
    Poziom 42  
    Posty: 9195
    Pomógł: 964
    Ocena: 2289
    nigdy w życiu programowe ustawienia portu B tak jak to opisałeś nie mogły spowodować zablokowania procka. Pin reset można przedefiniwać tylko za pomocą fusków.
    Jeśli mówisz, że pin reset ci nie działa to sam sobie odpowiedziałeś - fusebity są spaprane.

    spróbuj sobie jescze odczytać to za pomocą PonyProg'a czy innych może
  • REKLAMA
  • #4 4845844
    lorak17
    Poziom 15  
    Posty: 165
    Pomógł: 4
    Ocena: 9
    Port B pin 5 to właśnie reset z noty: PB5 (PCINT5/RESET/ADC0/dW)

    A co do Fusebits to ich nie ruszałem to raczej nie to


    chyba ze przy programowaniu może wystąpić błąd i Fusebits przestawić??
  • Pomocny post
    #5 4845864
    don diego
    Poziom 32  
    Posty: 1557
    Pomógł: 165
    Ocena: 63
    Sprawdź PonyProgiem i napisz jakie są rezultaty.
  • #6 4845891
    lorak17
    Poziom 15  
    Posty: 165
    Pomógł: 4
    Ocena: 9
    Możliwe bo pobrałem ostatnio z atmel.com.

    A co do tematu udało mi sie to rozwiązać zmniejszając napięcie, widocznie programator nie radził sobie z poziomem sygnału na pinie reset po włączeniu tych programowych opcji i przy mniejszym napięciu ruszyło:)

    Chyba pora zainwestować i zrobić USBASP bo tak nie da sie pisać programów pod AVR-y bo pod 8052 działało idealnie:)
  • REKLAMA
  • #7 4845911
    mirekk36
    Poziom 42  
    Posty: 9195
    Pomógł: 964
    Ocena: 2289
    w trybie ISP nie da się pracować z AVRkami??? to chyba jakaś pomyłka - ja od wielu miesięcy działam i to głównie poprzez ISP gdzie procki pracują w układzie i tam je bezpośrednio programuję, bez ich wyciągania.

    coś mi się wydaje, że masz albo coś nie tak z progrmatorem albo nie podłączasz napięcia zasilania do niego
  • #8 4845939
    lorak17
    Poziom 15  
    Posty: 165
    Pomógł: 4
    Ocena: 9
    Programator dybkowskiego również ma dwa cykle niezależnie uruchamiane od siebie, w jednym programuje sie pamięć programu a w drugim fusebits.

    Co do Ponyproga nie jestem przekonany jak kiedyś go używałem nie miał za wiele procków w obsłudze ale możliwe, że się coś zmieniło. Jednak myślę ze USBASP będzie lepszym pomysłem na przyszłość.


    Nie chodzi mi o tryb ISP tylko o programator używam cos w stylu STK200 oczywiście z zasilaniem :) a USBASP również pracuje w trybie ISP z ta różnica, że transmisja danych odbywa sie po USB z mniejszymi zakłóceniami (lepsze ekranowanie)

Podsumowanie tematu

✨ Problem dotyczył programowania mikrokontrolera ATTINY13 przez interfejs ISP za pomocą programatora podłączonego do portu LPT. Po dodaniu w kodzie ustawień DDRB = 0xFF i PORTB = 0xFF komunikacja z mikrokontrolerem przestała działać, a programator zwracał sygnaturę FF,FF,FF. Podejrzewano, że ustawienie portu B na wyjście z podciągniętymi stanami wysokimi blokuje linię reset, uniemożliwiając wejście w tryb programowania ISP. Dyskusja wskazała, że pin reset (PB5) jest powiązany z portem B i może być problem z fusebitami, choć autor twierdził, że ich nie zmieniał. Rozwiązaniem okazało się zmniejszenie napięcia zasilania, co pozwoliło programatorowi wymusić niski stan na linii reset i nawiązać komunikację. Wskazano również, że programatory takie jak USBASP, pracujące w trybie ISP z interfejsem USB, oferują lepszą stabilność i mniejsze zakłócenia niż programatory oparte na LPT lub STK200. Zalecano także sprawdzenie komunikacji za pomocą oprogramowania PonyProg oraz zwrócenie uwagi na poprawne ustawienia fusebitów i zasilanie układu podczas programowania.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA