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

[Attiny4/5/9/10][usbasp][avrdude] Testy wsparcia dla TPI

BoskiDialer 27 Gru 2010 09:23 16555 38
REKLAMA
  • #1 8917576
    BoskiDialer
    Poziom 34  
    Ostatnio zakupiłem sobie kilkanaście sztuk attiny10-tshr, a jako że jestem przyzwyczajony do używania usbasp, postanowiłem napisać swoje wsparcie dla TPI na usbasp. Jako że całość napisałem przez ostatnią noc, to może tam być kilka błędów, jednak generalnie programowanie działa.
    Moja prośba jeśli ktoś ma usbasp (z atmegą8: firmware przekroczył 4KB, więc m48 się nie sprawdzi) oraz któryś attiny z TPI, czy mógł by przetestować też u siebie moje modyfikacje? Czy nie ma problemów typu niedogrywanie ostatniego bajtu gdy firmware ma nieparzystą ilość bajtów, czy istnieje możliwość wgrania lockbitów i zdjęcia ich poprzez kasowanie układu, czy dobrze czyta sygnaturę i inne takie podstawowe rzeczy (wszystko sprawdziłem, ale chciał bym się upewnić, że w innych warunkach też będzie to działać)
    Zależało by mi też na testach, czy przypadkiem nie uśmierciłem obsługi samego SPI na usbasp.
    Dodatkowo czy jest w ogóle sens dawać do usbasp wsparcie dla TPI?

    Interfejs do TPI prawie pokrywa się z SPI: RESET=RESET, SCK=TPICLK, MOSI=TPIDATA (dwukierunkowe)

    Firmware który modyfikowałem to było usbasp.2009-02-28, natomiast avrdude brałem prosto z svn'a (v5.10 lub trochę dalej: rev:952), kompilowane pod mingw. Firmware na usbasp wrzucam w postaci jaką uzyskałem po przeróbkach, łatka do avrdude poleciała do twórcy usbasp, jak będzie wszystko ok to się tutaj pojawi
  • REKLAMA
  • #2 8917845
    mirekk36
    Poziom 42  
    BoskiDialer --> takie "cacuszko" to powinieneś w DIY wystawić ;) .... Coś pięknego i super pomysł.

    Szkoda, że nie mam teraz pomiędzy świętami możliwości przetestowania tego :( .... chociaż może uda mi się znaleźć jakiś USBASP z ATmega8 to przynajmniej od tej strony sprawdzę czy działa poprawnie nadal USBASP o ile ktoś wcześniej nie pomoże w tej sprawie.

    Tuż po sylwestrze jak coś, to w razie czego deklaruję każdą pomoc w testowaniu takiego rozwiązania ;)
  • #3 8922734
    BoskiDialer
    Poziom 34  
    Nie wiem czy jest sens umieszczać to w DIY, to nie jest gotowe rozwiązanie tylko coś, co po przetestowaniu będzie gotowym rozwiązaniem. W DIY może bym to umieścił, ale jako dodatek do tematu w którym wrzucił bym kilka przykładowych projektów na attiny10, a do tego musiał bym je najpierw zrobić.

    Przy okazji testowałem ten firmware u siebie, na razie pojawiają mi się problemy przy wchodzeniu do programowania - czasami nie wykrywa układu, trzeba na chwilę odłączyć zasilanie - jak i przy wychodzeniu z programowania - układ nie przechodzi do wykonywania programu. Prawdopodobnie brakuje sterowania pinem RESET.
  • #4 8922841
    tmf
    VIP Zasłużony dla elektroda
    Możesz zgłosić patch do twórców avrdude?

    Dodano po 6 [minuty]:

    Poprawda - stosowny patch do avrdude jest już dostępny od pół roku :)
  • REKLAMA
  • #5 8922900
    BoskiDialer
    Poziom 34  
    Patch co poprawiający jest dostępny od pół roku?

    Mój patch jak na razie został przesłany do twórcy usbasp, jak pamiętam to kiedyś on zatwierdzał jakąś tam moją łatkę do avrdude, więc nie ma potrzeby wysyłać tego osobno do samego avrdude.

    Tutaj w załączniku wrzucam łatkę gdyby ktoś chciał przetestować całość pod linuxem

    -- edit:
    Chodziło Ci o łatkę #7244? Nie została ona chyba jeszcze zatwierdzona a i jest w niej kilka niedociągnięć (z tego co czytam)
    Załączniki:
  • #6 9251775
    manekinen
    Poziom 29  
    Czy Attiny20 i Attiny40 również będą/są wspierane?
  • REKLAMA
  • #7 9251828
    BoskiDialer
    Poziom 34  
    Jeśli protokół ich programowania jest taki sam oraz jeśli zostaną dodane do avrdude (do pliku konfiguracyjnego z definicjami procesorów), to powinien normalnie obsługiwać.

    Swoją drogą cały czas czekam aż ktoś przetestuje ten firmware lub jego nowszą wersję z tematu "ATmega2561 + USBasp - nie mogę wrzucić dużego flasha" (nowszy ma tylko poprawioną obsługę procesorów z flash>128KB).
  • #8 9253143
    piotrva
    VIP Zasłużony dla elektroda
    Mam parę m2560 ale brakuje mi paru elementów do budowy programatora:
    Zenerki mam najbliższą wartość na 2,7 a kwarce 11 059 200 16000000 125xxxxx.
    Czy dało by się przepompować na takie parametry kwarcu (tzn czy będzie działać, bo kompiluje się bez problemów :D )?
    I czy te zenerki mogą być na 2,7 zamiast 3,6?
    Jeśli tak to mogę potestować
  • Pomocny post
    #9 9482380
    manekinen
    Poziom 29  
    Tak więc STĄD pobrałem avrdude i firmware dla usbasp. Męczę tego tiniego i nie mogę się z nim dogadać. Avrdude zwraca target doesn't answer.

    [Attiny4/5/9/10][usbasp][avrdude] Testy wsparcia dla TPI

    RST=niebieski
    MOSI=pomarańcz
    MISO=żółty
    SCK=biały
    czerwony i czarny zasilanie

    Wszystkie sygnały ładnie dochodzą, a tiny nie odpowiada. Próbowałem zmniejszać prędkość w avrdude nawet do 500Hz ale nic to nie daje.

    Jakieś pomysły?

    /dodano

    Używałem pliku wynikowego main.hex, ale prze kompilowałem program i otrzymałem identyczny plik - więc raczej wrzucam co trzeba :cry:

    /dodano

    Ok problem był po mojej stronie! Taką głupotę zrobiłem że nawet nie pytajcie :oops:

    Wszystko śmiga jak ta lala, zapis i weryfikacja pamięci flash - za każdym razem sukces. Wrzucony program także działa jak trzeba. Attiny10, bo chyba nie dopisałem :)

    [Attiny4/5/9/10][usbasp][avrdude] Testy wsparcia dla TPI

    BoskiDialer - świetna robota! ;)



    /kolejna edycja...

    Uwaga literówka:
    [Attiny4/5/9/10][usbasp][avrdude] Testy wsparcia dla TPI
  • #10 9509598
    BoskiDialer
    Poziom 34  
    Cieszę się, ze działa. Na dniach odezwał się Thomas, możliwe więc że łatka pojawi się oficjalnie w najbliższym czasie jak tylko uda nam się usunąć jeden mały problem.

    Występuje u Ciebie problem typu, że procesor nie wstaje wprost po programowaniu, tylko trzeba odpiąć na chwilę zasilanie albo wymusić na nim dodatkowy reset?
  • Pomocny post
    #11 9512903
    manekinen
    Poziom 29  
    Wcześniej nie zwróciłem na to uwagi, faktycznie tak się dzieje. Nawet nic nie trzeba programować, wystarczy dać "avrdude -p t10 -c usbasp" i po samym odczytaniu sygnatury układ samodzielnie nie wstaje. Ani razu.

    Nie zaglądałem w źródła, ale aby wyjść z trybu programowania nie wystarczy tylko zwolnić reset:
    14.3.2 Disabling napisał:

    Provided that the NVM enable bit has been cleared, the TPI is automatically disabled if the
    RESET pin is released to inactive high state or, alternatively, if VHV is no longer applied to the
    RESET pin.
    If the NVM enable bit is not cleared a power down is required to exit TPI programming mode.
    See NVMEN bit in “TPISR – Tiny Programming Interface Status Register” on page 107.

    oraz
    14.6 Accessing the Non-Volatile Memory Controller napisał:
    NVM programming is disabled by writing a logical zero to the NVMEN bit in TPISR.


    Być może tu jest problem ;)
  • #12 9512955
    BoskiDialer
    Poziom 34  
    Właśnie w tym miejscu dzieją się najciekawsze rzeczy, próbowałem wpisywać zera do każdej już lokalizacji (SOUT), wysyłałem zerowy SKEY z nadzieją, że coś się zmieni, dawałem powielanie wysyłania, robiłem kombinacje - układ cały czas pozostawał w trybie programowania. Jedyne rozwiązanie jakie znalazłem, to po zwolnieniu resetu wymusić dodatkowy reset. Zależnie czy uda się uruchomić przewidziany przez producenta sposób wychodzenia z trybu programowania, wydanie łatki będzie miało miejsce wcześniej lub później.
  • REKLAMA
  • #13 9513055
    manekinen
    Poziom 29  
    Nawet w sekcji "memory programming" napisano że wystarczy: wyczyścić bit NVMEN, zwolnić RESET. I to wszystko. Może trzeba odczekać kilka ms przed zwolnieniem resetu? Może trzeba machnąć 16 razy (lub więcej) zegarem tak jak ma to miejsce przy wchodzeniu w tryb programowania? A czy po wyczyszczeniu SKEY, bit NVMEN czyści się sam?

    Więcej pomysłów nie mam, może warto napisać do atmela i zapytać. Pytanie tylko czy będą chętni do pomocy, bo jak by nie patrzeć sami przyłożą się do spadku sprzedaży własnych programatorów :(
  • #14 9616228
    BoskiDialer
    Poziom 34  
    Przed chwilą dostałem maila, że moje łatki (dodanie TPI + poprawienie obsługi programowania >128KB) zostały zatwierdzone (ściślej to zostały zatwierdzone już dawniej do avrdude, ale teraz zgłoszenie zostało zamknięte). Nowy firmware do usbasp w obszarze moich łatek nie różni się zbytnio od tych wrzuconych tutaj (dodano dodatkowy impuls reset po zakończeniu programowania).

    Nowy firmware ma oznaczenie usbasp.2011-05-28.
  • #15 9619417
    manekinen
    Poziom 29  
    Aha czyli aktualizować warto bo rozumiem że rozwiązano problem z prockami TPI?
  • #16 9620360
    BoskiDialer
    Poziom 34  
    Problem może nie został rozwiązany, ale zastosowano jego obejście - jeśli procesor nie chce sam wyjść z trybu programowania, to dodatkowy impuls resetu mu w tym pomaga. Myślę, że warto aktualizować.
  • #17 9629814
    BoskiDialer
    Poziom 34  
    Właśnie szukając czegoś przez google natrafiłem na "2,5KV optoisolated USBASP, 1.8V-6V"
    manekinen napisał:
    Przy układach TPI, linia MOSI jest dwukierunkowa. Więc nici z izolacji. Trzeba tą linię wyprowadzić bezpośrednio z procka programatora.

    Otóż edytując tpi.S lub modyfikując Makefile można dodać dodatkową stałą TPI_WITH_OPTO, która powoduje, że do nadawania używany jest MOSI, natomiast do odbierania MISO. Pod warunkiem że optoizolacja wyjściowa (od MOSI) powoduje zwieranie do masy oraz warunkiem połączenia MISO oraz MOSI po stronie złącza, powinno dać się programować z użyciem TPI przy obecności optoizolacji.

    -- edit:
    A przynajmniej tak powinno być, wszak nie miałem tego jak przetestować.
    -- edit:
    Rozwiązanie pierwsze to dodanie w pliku tpi.S zaraz za includami linii:
    Kod: text
    Zaloguj się, aby zobaczyć kod

    Rozwiązanie drugie to zmodyfikowanie Makefile
    Kod: text
    Zaloguj się, aby zobaczyć kod

    -- edit:
    Dołączam skompilowany firmware na atmega8 uwzględniający optoizolację przy TPI. Firmware miał problemy się kompilować ze względu na brak zdefiniowanego TPI_DATAIN_PORT, co dało się poprawić jedną linijką.
    Załączniki:
  • #18 9646013
    manekinen
    Poziom 29  
    TPI nie sprawdzałem, po wgraniu tego wsadu przestaje działać ISP (target doesn't answer).

    Dodano po 17 [minuty]:

    Dokładnie wygląda to tak że komunikacja działa tylko raz. Tzn po podłączeniu USBASP do portu. Można zrobić odczyt, zapis, czy co tam, ale tylko raz. Za drugim razem i za n-tym już wywala błąd.
  • #19 9658447
    BoskiDialer
    Poziom 34  
    Bardzo ciekawe.. Niestety po wgraniu powyższego firmware nie udało mi się odtworzyć opisanego problemu: testując komunikację z t2313 wszystko działa bez problemu za każdym razem. Przy komunikacji z t10 też nie ma żadych problemów (symulacja optoizolacji z użyciem diody oraz opornika jako że nie posiadam usbasp z optoizolacją - mosi potrafił tylko ściągać pin TPIDATA do masy).
  • Pomocny post
    #20 9658807
    mirekk36
    Poziom 42  
    manekinen napisał:

    Dokładnie wygląda to tak że komunikacja działa tylko raz. Tzn po podłączeniu USBASP do portu. Można zrobić odczyt, zapis, czy co tam, ale tylko raz. Za drugim razem i za n-tym już wywala błąd.


    potwierdzam, u mnie dokładnie takie same efekty w USBASP, a próbowałem programować ATmega32, ATmega168, ATmega8.
  • #21 9658855
    BoskiDialer
    Poziom 34  
    Hm.. to bardzo interesujące.. Jako że dokładnie nie wiem od czego zacząć szukanie i jako że sam nie potrafię odtworzyć problemu przygotowałem 5 firmware'ów skompilowanych w różny sposób z różnymi modyfikacjami, przy czym nie napiszę jakie dokonałem zmiany. Zależało by mi na informacji na którym firmware błąd występuje a na którym nie. Można założyć, że nie wspierają one TPI. Na chwilę obecną nie napiszę jakich dokonałem zmian.
  • Pomocny post
    #22 9659037
    manekinen
    Poziom 29  
    B - błąd nie występuje.
    F - tylko pierwsza operacja, potem target nie odpowiada.
    G - błąd jak wyżej.
    J - błąd jak wyżej.
    N - błąd jak wyżej.

    Odczyt sygnatury i fusków, Atmega328P.
  • #23 9659073
    BoskiDialer
    Poziom 34  
    main_b.hex: W całości poprzedni firmware
    main_g.hex: Ten sam firmware co na forum
    main_f.hex: Przywrócony poprzedni usbdrv
    main_j.hex: Przywrócony poprzedni usbdrv, -Os zamiast -O2
    main_n.hex: Przywrócony poprzedni usbdrv, bez TPI_WITH_OPTO

    Muszę przeanalizować wszystkie zmiany dokonane pomiędzy wersjami, jeśli nie uda mi się znaleźć błędu tylko będę miał pewne przypuszczenia to ponownie wrzucę taką paczkę.. Obym znalazł błąd... Aktualnie jedyna poszlaka, to że pierwszy firmware ma mniej niż 4KB a pozostałe mają więcej niż 4KB
  • #24 9659310
    manekinen
    Poziom 29  
    Zacząłem badać sygnały i zauważyłem że błąd nie występuje przy prędkościach do 32kHz włącznie. Większa prędkość daje błąd. Czy to nie było jakoś tak że on używa softowego SPI od jakiejś tam prędkości w dół? Zdaje się najniższa sprzętowa to 12MHz z 256 dzielnikiem daje 46,875kHz, a niżej już programowo. Być może to jakiś błąd typu nie odczytania flagi z rejestru SPI po zakończeniu operacji...
  • #25 9659469
    BoskiDialer
    Poziom 34  
    Hm.. to już zaczyna brzmieć ciekawiej.. mam pewne przypuszczenia co do jednej linijki która została dodana do kodu.. W załączniku 4 wersje jak poprzednio...

    Nie udało mi się odtworzyć problemu, ale to co podejrzewam może powodować ten problem w przypadku elektroniki, która w sposób znaczący ogranicza stromość zbocza reset (rezystory w linii reset, duży kondensator w układzie RC do resetu).
  • Pomocny post
    #26 9666337
    manekinen
    Poziom 29  
    E - błąd jak wcześniej
    P - ok
    R - błąd
    Z - błąd

    TPI nie sprawdzałem. Jeśli założy się zworkę SLOW SCK i wykona odczyt, to po jej zdjęciu można wykonać znów jeden odczyt na zwykłej prędkości.

    Na linii reset nie mam żadnych rezystorów czy kondensatorów.
  • #27 9666407
    BoskiDialer
    Poziom 34  
    main_e.hex: Wersja podstawowa z sck_sw_delay=1
    main_p.hex: Wersja z poprawionym sck_sw_delay=10
    main_r.hex: Usunięta felerna linijka
    main_z.hex: Wersja z poprawionym sck_sw_delay=2

    Felerna linijka jest w isp.c w okolicy linii 37. Główny problem polega więc na tym, że mimo iż do komunikacji używany jest SPI sprzętowy, impulsy resetu są zbyt krótkie lub odstęp pomiędzy resetem a rozpoczęciem komunikacji jest zbyt krótki. Problem pojawił się w nowej wersji, gdyż razem z moimi zmianami dotyczącymi TPI oraz adresów rozszerzonych zmienił się sposób wznawiania próby połączenia z procesorem (funkcja ispEnterProgrammingMode): wcześniej po nieudanej próbie wejścia do trybu programowania pojawiało się dodatkowe zbocze na pinie SCK (aby w którejś próbie odzyskać synchronizację). Teraz sterowanie jest pinem RESET - dodatni impuls na pinie reset pomiędzy próbami. Jeśli układ nie wyrabia się z resetem, nie nadąża wstać, wewnętrznie blokuje go POR, BOR lub układ wydłużania resetu (który można przestawić fusami, chyba na 4ms lub 64ms), jest zewnętrzny układ zapewniający reset lub układ RC, to programator zbyt szybko próbuje zmusić procesor do odpowiedzi i całość nie działa w każdej z 32 prób połączenia się z procesorem. Wczoraj wysłałem notkę do autora usbasp, poprawki będzie można się spodziewać.. nie wiem kiedy...
    -- edit:
    Coś mi nie pasuje w mojej wypowiedzi, układ wydłużania resetu działa na wysokim poziomie, programowanie jest na niskim poziomie. Jakkolwiek sprawa wygląda tak, że problem jest ze zbyt szybkim wchodzeniem do trybu programowania po resecie.
  • #28 9666469
    manekinen
    Poziom 29  
    BoskiDialer napisał:
    Problem pojawił się w nowej wersji, gdyż razem z moimi zmianami dotyczącymi TPI oraz adresów rozszerzonych zmienił się sposób wznawiania próby połączenia z procesorem

    Z tym że ta oficjalna nowa wersja pracuje bardzo dobrze z moja optoizolacją, problemy są tylko z tą modyfikacją którą wprowadziłeś na potrzeby optoizolacji i TPI.

    W swoim programatorku procek inicjuję tak jak przykazała nota (nie wiem która, pewnie są jakieś rozbieżności), czyli:
    -ściągam reset i sck w dół
    -czekam 1ms
    -podnoszę reset
    -czekam 1ms
    -ściagam reset
    -czekam 50ms
    -ślę "programming enable" i sprawdzam czy wraca H53.

    Działa to za każdym razem, zawsze jest synchronizacja :)

    Dodano po 1 [minuty]:

    Chętnie bym podejrzał jak te przebiegi wyglądają, ale nie mam sprzętu który mógłby zbadać takie częstotliwości :(
  • #29 9666520
    BoskiDialer
    Poziom 34  
    Właśnie sęk w tym, że razem z moimi modyfikacjami pojawiły się też inne modyfikacje, nie moje - właśnie one powodują problemy. W main_p.hex opóźnienie pomiędzy zwolnieniem resetu a wejściem w tryb programowania wynosiło 3,2ms w pozostałych opóźnienie to było zbyt małe. W załączniku wersja, w której zmieniłem czas opóźnienia na adaptacyjne - począwszy od 3,2ms w pierwszej próbe, do 75,2ms w szesnastej próbie. Zaraz będę musiał przetestować czy nie ma problemów typu 'avrdude wywalające, że operacja na usb przekroczyła czas' - tutaj wejście próba wejścia do trybu programowania może zająć 1,2 sekundy lub więcej w przypadku braku podłączenia jakiego kolwiek procesora.
    Załączniki:
  • #30 9666938
    manekinen
    Poziom 29  
    Ok, obydwa działają. Mam rozumieć że main_tpi_with_opto.hex powinien obsługiwać TPI przez izolację? Sprawdzać to?
REKLAMA