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

Czy komuś działa JTAG-lock-pick Tiny 2 z jakimś AVRem z JTAG pod Linuksem?

kk.krz 23 Lis 2017 18:49 1449 20
  • #1 16844238
    kk.krz
    Poziom 4  
    Witam,

    pytanie jak w temacie.
    Próbuje pod OpenOCD.


    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Wygląda ok.
    No to:
    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Patrze w okienko z openocd i tam mam:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Czy ktoś ma jakiś pomysł?
    Może FCh? :)

    Pozdrawiam
  • #3 16845570
    kk.krz
    Poziom 4  
    I najprawdopodobniej nigdy nie będzie? Chyba że sobie napiszę sam ... i się dorzuci do OpenOCD? :)

    FCh ... w opisie Swojego JTAGa twierdziłeś, że obsługuje AVR. W jaki sposób udawało Ci się
    tego dokonać. Działało tylko programowanie czy debuggowanie też?
  • #4 16845668
    Freddie Chopin
    Specjalista - Mikrokontrolery
    kk.krz napisał:
    I najprawdopodobniej nigdy nie będzie? Chyba że sobie napiszę sam ... i się dorzuci do OpenOCD?

    "Nigdy" to mocne słowo, niemniej jednak raczej nikt nad tym nie pracuje, bo AVR32 to martwa platforma i to już od dłuższego czasu.

    kk.krz napisał:
    FCh ... w opisie Swojego JTAGa twierdziłeś, że obsługuje AVR. W jaki sposób udawało Ci się
    tego dokonać. Działało tylko programowanie czy debuggowanie też?

    Ale ustalmy fakty (; AVR - rozumiany jako np. AtMega128 - to nie jest to samo co AVR32. To pierwsze jest w jakimś tam stopniu obsługiwane przez OpenOCD (nigdy osobiście nie używałem), to drugie - jak już pisałem wyżej - jest martwą architekturą, więc raczej nie oczekiwałbym że takie wsparcie pojawi się zbyt szybko, jeśli kiedykolwiek...
  • #5 16845895
    kk.krz
    Poziom 4  
    Taa... znów coś poknociłem. Mam programować Atmege32, a config OpenOCD wziąłem dla AVR32 :).

    Z tym, że jak się zorientowałem, to użyłem konfiga dla AtMega128 i wtedy też dostałem błędy. Sprawa kończyła się segfaultem OpenOCD. Ale w tej chwili jestem poza domem i nie mogę dokładnie określić jakie komunikaty wyrzucał OpenOCD. Zrobię to wieczorem i najpewniej znów będę liczył na pomoc.

    Dodano po 6 [godziny] 37 [minuty]:

    Ok...więc jest tak:

    plik atmega128.cfg wygląda tak:
    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    W nim zmieniam sygnature procka, bo pluje błędami...
    Dalej...o ile dobrze rozumiem podpowiedzi z pliku config , wywołuje OpenOCD tak:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Odpala się OpenOCD i mówi tak:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Po zrobieniu w arm-gdb : target remote :3333
    OpenOCD wywala się tak:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Dodano po 21 [minuty]:

    Jeszcze uzupełnie:

    Gdy wywołam openocd bez "gdb_memory_map disable"

    przy próbie połączenia dostaje:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Gdy włącze gdb_memory_map disable dostaję segfault'a
  • #6 16846983
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Niestety nie używałem tego z AVRami, więc pewnie wiele nie pomogę, ale może akurat AtMega32 nie zadziała?

    Info : device id = 0x8950203f
    Error: 0x9502 is not support for avr


    No i czemu "verify_ircapture disable"?
  • #7 16848123
    kk.krz
    Poziom 4  
    Podglądnij wyświetlony przeze mnie atmega128.cfg. Tam są podpowiedzi. Ta opcja to realizacja jednej z tych podpowiedzi. Chyba, że coś źle rozumiem...
  • #9 16848679
    kk.krz
    Poziom 4  
    Uruchomiłem OpenOCD:

    openocd -f /usr/local/share/openocd/scripts/interface/ftdi/jtag-lock-pick_tiny_2.cfg -f atmega128.cfg -c "gdb_memory_map disable; init; reset init; halt; poll;"

    bez verify_ircapture disable.

    i po próbie połączenia się z avr-gdb znów segfault

    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    Jak się łącze telnetem na 4444 i próbuje go "reset init"
    dostaję:

    JTAG tap: avr.cpu tap/device found: 0x8950203f (mfg: 0x01f (Atmel), part: 0x9502, ver: 0x8)

    :/
  • #11 16849853
    kk.krz
    Poziom 4  
    Próba zaprogramowania:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod


    czyli coś nie tak :/
  • Pomocny post
    #12 16849893
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Patrząc tu - http://repo.or.cz/openocd.git/blob/HEAD:/src/flash/nor/avrf.c#l64 - obstawiam, że jednak AtMega32 nie jest obsługiwana. Jeśli ma ona interfejs JTAG i nie różni się jakoś znacząco od tych które są obsługiwane, to zapewne dodanie wsparcia polegać będzie na uzupełnieniu tej tablicy o dodatkowy wpis.
  • #13 16850220
    kk.krz
    Poziom 4  
    Próbuje to uzupełnić i widzę w tej tabeli nieścisłości:

    Atmega 128 ma:

    – 128Kbytes of In-System Self-programmable Flash program memory
    – 4Kbytes EEPROM
    – 4Kbytes Internal SRAM

    A w tabeli jest:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    czyli wg tabeli 256kB Flash i 8kB EEPROM... więc już niezgodność z DS.
    No i nie wiem co to jest flash_page_num i eeprom_page_num?
    Możesz mi podać co mam wpisać dla Atmega32 albo wskazać "klucz" do znalezienia
    tego co mam tam wpisać?

    Dodano po 9 [minuty]:

    No ok, nie to ma być, tylko trzeba pogrzebać w DS...

    Hm...więc szukam w DS i dla Atmega128 na stronie 291/292 mam tabelki:
    Widze, że jest niby wszystko dobrze poza flash_page_size: wg DS jest 128 words
    a w źródłach 256.
  • Pomocny post
    #14 16850278
    Freddie Chopin
    Specjalista - Mikrokontrolery
    kk.krz napisał:
    No i nie wiem co to jest flash_page_num i eeprom_page_num?

    Obstawiam, że "..._num" to ilość stron które są dostępne, a "..._size" to rozmiar jednej strony, a więc...

    kk.krz napisał:
    czyli wg tabeli 256kB Flash i 8kB EEPROM... więc już niezgodność z DS.

    ... a więc wszystko się zgadza, bo 512 B x 256 daje 128 kB, a 8 B x 512 daje 4 kB.

    kk.krz napisał:
    Widze, że jest niby wszystko dobrze poza flash_page_size: wg DS jest 128 words
    a w źródłach 256.

    W źródłach OpenOCD rozmiar jest pewnie w bajtach, a w datasheecie podają rozmiar w "słowach", pewnie więc jedno słowo ma 16 bitów (2 bajty).
  • #15 16850339
    kk.krz
    Poziom 4  
    Ok, chwyciłem...kompiluje...

    Po skompilowaniu działa jedynie wczytywanie z openOCD bezpośrednio tak:

    openocd -f /usr/local/share/openocd/scripts/interface/ftdi/jtag-lock-pick_tiny_2.cfg -f ~/atmega128.cfg -c "init; reset init; halt; poll;" -c "flash write_image rfm02nadajnik.hex"

    i dostaje wtedy:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod



    Połączenie z avr-gdb nadal wywala segfaulta, natomiast próba wczytania z telnetu zgodnie
    z podanym przez Ciebie poleceniem konczy się niepowodzeniem:

    Kod: Bash
    Zaloguj się, aby zobaczyć kod
  • #17 16850529
    kk.krz
    Poziom 4  
    Wgrywanie jednak nie jest poprawne. Robie sobie prosty program do mrugania diodą, kompiluje go w Eclipse, programuje tego hexa i niestety nie działa procek, czyli coś jest nadal nie tak. Kompilowałem tego hexa także z Atmel studio dla upewnienia się...niestety po wgraniu przez OpenOCD nie działa procek :/
    Chyba się poddam - Mam Atmel-ICE, więc AVRy chyba muszą zostać przy Windzie i Atmel Studio.
    A miło by było zobaczyć Eclipse debuggującego AVRa :)
  • #18 16850574
    Freddie Chopin
    Specjalista - Mikrokontrolery
    kk.krz napisał:
    Wgrywanie jednak nie jest poprawne. Robie sobie prosty program do mrugania diodą, kompiluje go w Eclipse, programuje tego hexa i niestety nie działa procek, czyli coś jest nadal nie tak. Kompilowałem tego hexa także z Atmel studio dla upewnienia się...niestety po wgraniu przez OpenOCD nie działa procek :/

    Przed komendą "flash write_image ..." należy wydać zwykle komendę "flash erase_..." - może tu jest problem?
  • #19 16850606
    kk.krz
    Poziom 4  
    Tak, miałeś rację. Ale zrobiłem troszkę inaczej, czyli -c "flash write_image erase hw_at32.hex"
    i zaprogramowało. Niestety program rusza dopiero po odłączeniu zasilania procka i włączeniu ponownie. Sam reset nie wystarcza.

    Nota bene udało mi się także zaprogramować Atmege32 przez Atmel-ICE via OpenOCD na Linuksie...szkoda że próby podłączenia się przez avr-gdb znów kończą się segfaultami...

    Dodano po 19 [godziny] 27 [minuty]:

    Posiłkując się tym:
    http://forum.atnel.pl/topic14735.html

    udało mi się zrobić debuggowanie Atmegi32 pod Eclipse za pomocą interfejsu ATMEL-ICE. Jestem w stanie sterować pracę procka, ustawiać breackpointy, ale...problem jest w tym, że Eclipse niewłaściwie komunikuje się z Avarice.

    Dostaję

    Failed to execute MI command:
    -data-disassemble -s 0 -e 104 -- 3
    Error message from debugger back end:
    Cannot access memory at address 0x8000

    w oknie Disassembly

    I nie mogę podglądnąć pamięci:

    PORTB Error: Multiple errors reported.\ Unable to create variable object\ Failed to execute MI command: -data-evaluate-expression PORTB Error message from debugger back end: No symbol "PORTB" in current context.\ Failed to execute MI command: -var-create - * PORTB Error message from debugger back end: -var-create: unable to create variable object\ Failed to execute MI command: -var-create - * PORTB Error message from debugger back end: -var-create: unable to create variable object

    w oknie Expressions...

    Wychodzi na to, że Avarice nie rozumie komend MI a ja nie jestem w stanie
    dokonać ustawień w okienku modułu GDB Hardware Debuging, bo w moim Eclipse
    nie ma takich możliwości. Tzn. nie mam możliwości przestawienia Legacy GDB i GDB DSF...Po prostu w Oxygen tego nie ma i już.

    Eclipse mam dokładnie w wersji 4.7.1a
  • #20 16852595
    Freddie Chopin
    Specjalista - Mikrokontrolery
    Dodam może tylko, że akurat PORTB to pewnie makro i to że nie można sobie w Expressions wpisać nazwy makra jest (niestety) normalne. Możesz bezpośrednio podglądać adresy, np. tak: (volatile uint8_t*)0x01234567
  • #21 16852736
    kk.krz
    Poziom 4  
    no tak...wiem...dałem plame...problem z tym, że w ogóle disassembling nie działa
REKLAMA