-
1. Data: 2019-08-24 11:05:18
Temat: Atxmega123A3U - bootloader DFU
Od: Atlantis <m...@w...pl>
Złożyłem sobie prostą płytkę prototypową z układem Atxmega128A3U oraz
kilkoma peryferiami. Ponieważ w tej chwili nie mam dostępu do
programatora PDI, postanowiłem przetestować jej działanie za pomocą
bootloadera DFU.
Poniższa nota twierdzi, że w celu uruchomienia bootloadera w tym
konkretnym układze trzeba zewrzeć z masą pin PE5 podczas resetu.
https://www.mouser.com/ds/2/268/doc8429-1066104.pdf
Ponieważ w moim projekcie ten pin jest również linią SCK w interfejsie
SPI podłączonym do karty SD, wstawiłem tam bufor trojstanowy, który
łączy linię z przyciskiem tylko wtedy, gdy linia reset również jest w
stanie niskim.
Nie zadziałało. Wciskam przycisk DFU, nie puszczając go wciskam reset,
potem puszczam reset i przycisk DFU. Zgodnie z opisami znalezionymi w
internecie w tym momencie komputer powinien wykryć nowe urządzenie USB.
Pod Linuksem jednak niczego nie widać w lsusb, Windows także niczego nie
wykrywa.
Pomyślałem, że może winny jest bufor - jeśli sprawdzanie nie odbywa się
w stanie resetu, ale na początku pracy mikrokontrolera, to po puszczeniu
przycisku reset na linii DFU znów pojawi się stan wysokiej impedancji.
Wylutowałem więc bufor i wstawiłem zworę (na tym etapie rzecz jasna
karty SD nie było w gnieździe).
To samo. Komputer ciągle go nie widzi.
Sprawdziłem, czy gniazdko micro USB jest podłączone do właściwych linii
i tu si>=ę wszystko zgadza. Jedyna różnica w stosunku do schematu
aplikacyjnego to zastosowane diodowego zabezpieczenia USBLC6-2, które
zwykle stosuję w swoich urządzeniach z USB.
Układ zasilania działa, zasilanie podłączone prawidłowo, pin RESET/PDI
podciągnięty do plusa zasilania rezystorem 10k. Rzecz jasna MCU zasilany
z 3,3V.
Ktoś ma jakiś pomysł o co może chodzić? Mógł mi się trafić układ bez
fabrycznie wgranego bootloadera? To w ogóle możliwe, czy one mają go na
stałe zapisywanego maską na etapie produkcji, jak w przypadku niektórych
ARM-ów?
-
2. Data: 2019-08-24 14:58:51
Temat: Re: Atxmega123A3U - bootloader DFU
Od: Atlantis <m...@w...pl>
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.
-
3. Data: 2019-08-24 16:43:29
Temat: Re: Atxmega123A3U - bootloader DFU
Od: Dariusz Dorochowicz <_...@w...com>
W dniu 2019-08-24 o 14:58, Atlantis pisze:
> 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.
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
-
4. Data: 2019-08-25 00:21:40
Temat: Re: Atxmega123A3U - bootloader DFU
Od: Atlantis <m...@w...pl>
On 24.08.2019 16:43, Dariusz Dorochowicz wrote:
> 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.
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).
> 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ę.
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.
-
5. Data: 2019-08-25 09:04:06
Temat: Re: Atxmega123A3U - bootloader DFU
Od: heby <h...@p...onet.pl>
On 25/08/2019 00:21, Atlantis wrote:
> 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.
-
6. Data: 2019-08-25 10:54:00
Temat: Re: Atxmega123A3U - bootloader DFU
Od: Atlantis <m...@w...pl>
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.
https://www.mouser.com/ds/2/268/doc8429-1066104.pdf
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?