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ż?
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...
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
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.
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.
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
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?
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...
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ż.
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