Atxmega123A3U - bootloader DFU

Ok, problemów ciąg dalszy. Zdobyłem programator PDI (klon AVRISP MKII), podłączyłem go do płytki (wydaje mi się, że prawidłowo) i ustawiłem w tryb przeznaczony do współpracy z AVRDUDE. Tym razem Linux wykrywa programator (jest widoczny pod lsusb). Jednakże gdy tylko spróbowałem odczytać ID układu za pomocą wspomnianego wcześniej programu, zaczął on sypać błedami w stylu:

avrdude: stk500v2_recv_mk2: error in USB receive avrdude: stk500v2_getsync(): timeout

W parametrze polecenia umieściłem "-c avrisp2 -P usb".

Ciągle nie wiem, czy atxmega w ogóle jest sprawna, bo tym razem wydaje się, że problem leży gdzieś w sofcie odpowiedzialnym za komunikację komputera z programatorem.

Ktoś ma jakiś pomysł jak mógłbym to rozwiązać?

Dla jasności - próbowałem też podłączyć programator do Raspberry Pi i uruchomi≥ć programator z jego poziomu. Miałem taki sam objaw.

W dniu 2019-08-24 o 14:58, Atlantis pisze:

Jeżeli to jest klon z 10-pinową taśmą (chociaż on się chyba trochę inaczej nazywa) to xmegi na nim możesz nie uruchomić. Kiedyś kupiłem coś takiego ale xmegi na liście obsługiwanych układów nie było i nie działało. A jeżeli ma taśmę 6-pinową to spróbuj najpierw podłączyć do Atmel Studio. A w poleceniu do avrdude chyba brakuje jeszcze paru parametrów - w szczególności określenia typu układu który chcesz podłączyć. Tak z pamięci piszę.

Pozdrawiam

DD

Szerokość taśmy nie ma tutaj nic do rzeczy. Pierwotnie mikrokontrolery AVR korzystały ze standardu ISP. Posiadał on sześć linii sygnałowych, ale dość długo wyprowadzano je na złaczu IDC-10. Dopiero późnej zoptymalizowano to, wprowadzając złącze programowania z sześcioma pinami. To jednak ciągle był protokół ISP, więc układu z rodziny XMega się na nim nie zaprogramuje.

Te układy korzystają ze standardu PDI, który posiada cztery sygnały, również wyprowadzone na złączu o sześciu ponach.

Posiadany przeze mnie klon AVRISP MKII jest dość uniwersalny - potrafi programować ISP, PDI oraz dodatkowo TPI (standard stosowany w nowszych układach AtTiny).

Określenie układu dodałem. Pominąłem tę część, bo nie ma wielkiego znaczenia - odczytanie sygnatury układu powinno zwrócić taki sam efekt, bez względu na to, jaki układ podamy. Zresztą... Wyskakujący błąd wskazuje na problem w komunikacji pomiędzy komputerem i programatorem, a nie programatorem i układem.

Dwa hinty: a) wepnij przez HUB usb b) sprawdź pod Linuxem

Teraz wyjaśnienie: Windows w *niektórych* implementacjach sterowników i hardware nie potrafił się dogadać z conajmniej kilkoma programatorami. Miałem swego czasu kilkadziesiąt róznych sprzetów pod ręką i kilka nie było w stanie obsługiwać wprost urządzeń takich jak programatory (i nie tylko, ale głównie takich). Przykładem by PICkit bodaj 2, fabryczny, oryginalny z microchipa. Nie działał na niewielkim procencie hardware z windowsami 7. Aplikacja microchipa albo go nie widziała albo zgłaszała różne błędy podczas zabawy. Nie spodziewam się że to jest jakiś problem z uszkodzonym systemem bo to pracownie komputerowe zaraz po instalacji.

*Zawsze* udawało się to naprawić wpinając takie urządzenie przez najtańszy HUB usb.

Co do b) to chodzi głównie o to że dostaniesz większą diagnostykę co się stało. Kiedyś okazało się że urządzenie w trakcie pracy samodzielnie się wypina bo przekraczałem dopuszczalny prąd zasilania zasilając układ przez programator... i w dmesg było to widać.

PS. Istnieje problem z urządzeniami implementującymi stack USB softwareowo, np. na zwykłych AVR, przykładem jest programator USBASP. Tam wpięcie HUBa tez pomaga ale z innych przyczyn, chodzi o bulk-transfer który jest niedopuszczalny dla low-speed ale jednocześnie

*czasami* obsługiwany w OSach i bardzo często w HUBach. Ale przypuszczam że tutaj nie chodzi o ten problem.

Jest pewien postęp.

1) Przyczyna niedziałania AVRISP MKII okazała się być banalna. Wychodzi na to, że nie wystarczyło dodać plik konfiguracyjny w /etc/udev/rules.d/ i zrestartowac konfigurację z linii poleceń. Konieczny był całkowity restart systemu, Po tej operacji urządzenia zaczęły się komunikować. 2) Przez programator byłem w wstanie wgrać hexa z bootloaderem. Wychodzi więc na to, że nie był on wgrany fabrycznie. 3) Ponieważ flash MCU był pusty, bootloader wystartował samoczynnie. Pojawił się na liscie urządzeń zwracanych przez lsusb. Program dfu-programmer także go widział, za jego pomocą byłem w stanie wgrać prosty przykład z miganiem diodą, który uruchomił się po resecie.

I tu kończy się dobra pasa. Nie jestem w stanie ponownie wejść w tryb bootloadera. Wciskam przycisk zwierająct PE5 do masy, naciskam reset, trzymam przez chwilę, puszczam reset a następnie PE5. Uruchamia się program migający diodą, zamiast bootloadera.

Ta nota mówi, że w przypadku atxmega128a3u odpowiednim pinem jest PE5.

BTW, tak przy okazji. Na płytce mam też układ Wiznet W5100. Jeszcze nie jest obsłużony programowo, ale po podpięciu kabla ethernetowego do gniazdka świeci dioda informująca o połączeniu i miga ta oznaczająca aktywność. Zauważyłem natomiast, że przy odpiętym kablu scalak grzeje się dużo mocniej, niż przy podłączonym. W tym pierwszym przypadku jest zauważalnie rozgrzany - nie na tyle, żeby parzył i nie dało się go dotknąć, ale jednak. W drugim przypadku jest ledwie ciepły. To normalne?