Eclipse + OpenOCD + GDB

Do sprz?gni?cia wszystkich elementów w jedn? ca?o?? brakuje jeszcze dwóch pluginów do Eclipse. Pluginy owe - jak i wszelkie uaktualnienia samego pakietu - mo?na pobra? poprzez menu Help > Software updates.

Pierwsza wtyczka - Eclipse C/C++ GDB Hardware Debugging - nale?y do palety dodatków "firmowych", wi?c jedyne co nale?y zrobi?, to w zak?adce Available Software z dost?pnego drzewa wybra? http://download.eclipse.org/tools/cdt/releases/ganymede > CDT Optional Features > Eclipse C/C++ GDB Hardware Debugging i klikn?? Install. Proces instalacji wtyczki mo?e troch? potrwa? - zale?nie od aktualnego obci??enia serwerów i ??cza.

Drugi z potrzebnych komponentów - Zylin Embedded CDT - wymaga kilku klikni?? wi?cej. Poniewa? wtyczka ta nie jest cz??ci? standardowo dost?pnej palety, nale?y doda? stron? macierzyst? wtyczki do dost?pnych ?róde? aktualizacji. Aby tego dokona?, w zak?adce Available Software nale?y wybra? opcj? Add Site... i wprowadzi? adres http://opensource.zylin.com/zylincdt . Po klikni?ciu OK z drzewa b?dzie mo?na wybra? http://opensource.zylin.com/zylincdt > Uncategorized > Zylin Embedded CDT. Po klikni?ci w Install wtyczka zostania pobrana i zainstalowana.

W tym momencie warto dla pewno?ci zresetowa? Eclipse, aby by? pewnym, ?e zainstalowane w?a?nie wtyczki zostan? poprawnie uruchomione.

Do celów debuggowania aplikacji w Eclipse przewidziany jest inny uk?ad okien. Predefiniowane uk?ady okien w Eclipse zwane s? Perspectives. Kod tworzony jest w C/C++ Perspective, natomiast debuggowanie mo?liwe jest w Debug Perspective. Otworzenie nowego uk?adu mo?liwe jest przez menu Window > Open Perspective > Other... . Uk?ady które ju? zosta?y otwarte mo?na zmienia? w prawym górnym rogu okna Eclipse oraz w menu Window > Open Perspective.

Do Debug Perspective warto doda? zak?adk? deassemblacji - menu Window > Show View > Disassembly. Zak?adk? t? mo?na umie?ci? wed?ug uznania w dowolnej z ramek Debug Perspective.

Pierwszym krokiem w sprz?gni?ciu Eclipse ze sprz?tem jest uruchomienie za jego po?rednictwem OpenOCD. Opcje umo?liwiaj?ce uruchamianie dowolnych zewn?trznych aplikacji poprzez Eclipse znale?? mo?na w menu Run > External Tools. Ikonka tej grupy dost?pna jest równie? standardowo na pasku narz?dziowym. W celu uruchomienia OpenOCD wybieramy wi?c Run > External Tools > External Tools Configurations... i ikonk? New launch configuration (po lewej na pasku narz?dzi nad pust? obecnie list?) (lub opcja New z menu kontekstowego listy) tworzymy nowy element. W zak?adce Main wprowadzi? nale?y ?cie?k? dost?pu do OpenOCD - dla wersji 0.1.0 b?dzie to C:\Program Files\OpenOCD\0.1.0\bin\openocd.exe - oraz argumenty z którymi wywo?any zostanie program, które zale?ne s? od konfiguracji sprz?towej. W moim przypadku (JTAG-lock-pick + makieta z LPC2103) argumenty maj? posta? -f interface/jtagkey.cfg -f target/lpc2103.cfg . Wprowadzon? konfiguracj? warto nazwa? w sposób jednoznaczny w polu Name na górze okna - niech b?dzie to na przyk?ad "OpenOCD + jtagkey + lpc2103". Tak przygotowan? konfiguracj? mo?na zatwierdzi? przyciskiem Apply, a nast?pnie uruchomi? przyciskiem Run. Raz uruchomiona konfiguracja b?dzie pó?niej dost?pna w sposób szybszy, a mianowicie bezpo?rednio poprzez menu Run > External Tools (lub pod ikon? na pasku narz?dzi).

Uruchomione OpenOCD pojawi si? w zak?adce Debug, a komunikaty OpenOCD pow?druj? do zak?adki Console zwi?zanej z tym elementem.

Finalny krok na drodze do ujarzmienia debuggowania w Eclipse to wprowadzenie parametrów dla GDB. Opcje powi?zane z debuggerem dost?pne s? w menu Run > Debug Configurations... . Dost?p do tej grupy opcji mo?liwy jest te? poprzez przycisk Debug, który standardowo znajduje si? na pasku narz?dzi.

W oknie Debug Configurations w?ród dost?pnych na li?cie elementów powinna si? znale?? opcja GDB Hardware Debugging - po jej dwukrotnym klikni?ciu stworzona zostanie nowa konfiguracja powi?zana z tym typem debuggowania.

Konfiguracje powi?zane s? z projektami, wi?c pierwsz? czynno?ci? musi by? przypisanie jednego z otwartych projektów do tej konfiguracji - mo?na to zrobi? bezpo?rednio - wpisuj?c nazw? projektu do pola Project - lub wybieraj?c projekt z listy aktualnie otwartych przyciskiem Browse... . Po wybraniu projektu konieczne jest wybranie pliku wykonywalnego, który b?dzie debuggowany. Ponownie - wzgl?dn? ?cie?k? do pliku mo?na poda? bezpo?rednio w polu C/C++ Aplication, lub wybra? jeden z dost?pnych dla danego projektu plików poprzez przycisk Search Project... .

W nast?pnej zak?adce - Debugger - znajduj? si? ustawienia samego GDB. W zak?adce tej nale?y przede wszystkim wprowadzi? ?cie?k? do samego pliku wykonywalnego GDB - w przypadku standardowej instalacji pakietu CodeSourcery b?dzie to C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin\arm-none-eabi-gdb.exe . Drugim parametrem który nale?y zmieni? w tej zak?adce jest numer portu za pomoc? którego GDB b?dzie komunikowa? si? ze sprz?tem - w przypadku OpenOCD standardowo jest to port o numerze 3333.

Ostatni? porcj? zmian nale?y wprowadzi? w zak?adce Startup, która odpowiada za - zgodnie z nazw? zreszt? - zachowanie GDB po pod??czeniu do sprz?tu. Pierwsz? ramk? która powinna budzi? szczególne zainteresowanie jest ramka Initialization Commands. Opcje Reset and Delay oraz Halt najlepiej zostawi? w spokoju - nie dzia?aj? one prawid?owo z toolchainami dla ARMów. W du?ym oknie tekstowym mo?emy wprowadza? ró?ne komendy które zostan? wykonane po uruchomieniu GDB. Najciekawsz? opcj? jest mo?liwo?? wydawania komend bezpo?rednio dla OpenOCD - uzyska? to mo?na poprzez poprzedzenie komendy s?ówkiem monitor (lub w skrócie mon). Zestaw komend jaki nale?y wyda? jest ?ci?le zale?ny od u?ywanego uk?adu docelowego oraz od efektu jaki chce si? osi?gn??. Zasadniczo po uruchomieniu GDB resetuje si? uk?ad docelowy (a wi?c monitor reset) i zatrzymuje rdze? (poprzez - na przyk?ad - monitor halt lub monitor soft_reset_halt w przypadku np. LPC2000). Je?li w kodzie zasz?y jakie? zmiany konieczne jest za?adowanie do pami?ci uk?adu nowego obrazu. Kusi aby u?y? do tego celu opcji z ramki Load Image and Symbols, niemniej jednak i te opcje niezbyt dobrze wspó?pracuj? z ARMami. Do za?adowania obrazu mo?na wi?c wykorzysta? bezpo?rednio komend? GDB - load - któr? wpisa? nale?y do pola w ramce Initialization Commands. Przedostatnia ramka - Runtime Options - pozwala na ustawienie "jednorazowego" breakpointa w dowolnym miejscu i odpalenie programu po tych wszystkich operacjach. Warto wi?c podej?? do sprawy standardowo - zatrzyma? program na pocz?tku funkcji main, gdy? zwykle nie ma potrzeby debuggowania assemblerowych startupów. W tym celu wystarczy zaznaczy? opcj? Set breakpoint at i w pole tekstowe wpisa? main oraz zaznaczy? opcj? Resume.

W tym momencie warto mo?e napisa? par? s?ów na temat Initialization Commands. Poniewa? toolchain dla ARMów nie obs?uguje opcji resetowania przez GDB, warto stworzy? sobie dwa "zestawy" konfiguracji debuggowania - jedna konfiguracja umo?liwia? b?dzie za?adowanie do procesora nowego obrazu programu, a druga wykorzystywa? b?dzie obraz znajduj?cy si? ju? w pami?ci uk?adu. Ró?ni? b?d? si? tylko obecno?ci? komendy load.

Przyk?adowe komendy inicjalizuj?ce dla LPC2103 i ?aduj?ce program do pami?ci RAM:

monitor reset
monitor soft_reset_halt
monitor mww 0xE01FC040 0x0002
load

Zauwa?y? mo?na dodatkow? komend? mww 0xE01FC040 0x0002, która powoduje zapis (Memory Write Word) warto?ci 0x0002 pod adres 0xE01FC040, który - w ARM7 - odpowiada rejestrowi MEMMAP - warto?? ta w tym rejestrze oznacza zmapowanie pocz?tku pami?ci RAM w obszar wektorów przerwa?, co odpowiada sytuacji gdy ca?y za?adowany program znajduje si? w pami?ci RAM.

W tym momencie gotow? konfiguracj? warto jako? ?adnie nazwa? (na przyk?ad LPC2103 + load) przy pomocy pola na górze okna i zatwierdzi? ca?o?? przyciskiem Apply. Je?li w tle wci?? uruchomione jest OpenOCD mo?na od razu nacisn?? przycisk Debug i przej?? do debuggowania programu! Po pierwszym uruchomieniu danej konfiguracji b?dzie ona dost?pna w wygodniejszy sposób, a mianowicie bezpo?rednio w menu Run > Debug History lub pod przyciskiem Debug na pasku narz?dzi.

Je?li wszystko si? uda?o, po krótkiej chwili w zak?adce Debug poni?ej uruchomionego OpenOCD powinien pojawi? si? proces o ustalonej przez nas nazwie odpowiedzialny za GDB Hardware Debugging, a w nim zatrzymany pojedynczy w?tek Thread [0]. Sukces!

Warto w tym momencie wspomnie? o kwestii konsol dla uruchomionych aplikacji. Wprawne oko podczas uruchamiania GDB zauwa?y kilkana?cie linijek przewijaj?cych si? przez zak?adk? Console i znikaj?cych po pe?nym uruchomieniu. Otó? ka?da z uruchomionych w tle aplikacji ma swój w?asny zestaw zak?adek i danych, a wi?c i konsol. Je?li w zak?adce Debug klikniemy na proces OpenOCD (dok?adniej - na element C:\Program Files\OpenOCD\0.1.0\bin\openocd.exe) to w zak?adce Console pojawi si? aktualna zawarto?? konsoli przyporz?dkowanej dla tego w?a?nie procesu. Konsola ta zaraz po odpaleniu GDB powinna zawiera? mniej wi?cej taki tekst:

Open On-Chip Debugger 0.1.0 (2009-01-21-21:15) Release

BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS

$URL: https:// This e-mail address is being protected from spambots. You need JavaScript enabled to view it /svnroot/repos/openocd/tags/openocd-0.1.0/src
/openocd.c $
1000 kHz
Info : JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787,
Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
Warn : no telnet port specified, using default port 4444
Warn : no gdb port specified, using default port 3333
Warn : no tcl port specified, using default port 6666
Info : accepting 'gdb' connection from 0
Error: timed out while waiting for target halted
Warn : acknowledgment received, but no packet pending
Warn : target not halted
Info : JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787,
Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0x00000000
Warn : memory write caused data abort (address: 0xe01fc040, size: 0x4, count: 0x1)
Runtime error, file "command.c", line 456:

Natomiast je?li w zak?adce Debug wybrany zostanie element odpowiadaj?cy procesowi GDB (czyli C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin\arm-none-eabi-gdb.exe) naszym oczom uka?e si? konsola samego GDB, której zawarto?? powinna wygl?da? mniej wi?cej tak:

target remote localhost:3333
0x00000000 in ?? ()
monitor soft_reset_halt
load
Loading section .text, size 0x1adc lma 0x40000000
Start address 0x40000000, load size 6876
Transfer rate: 13 KB/sec, 6876 bytes/write.
tbreak main
Temporary breakpoint 1 at 0x400001a0: file src/main.c, line 258.
continue

Temporary breakpoint 1, main () at src/main.c:258
258 volatile unsigned int x,max=100000;

Warto zauwa?y?, ?e w zak?adce Disassembly wida? aktualn? instrukcj? C a pod ni? odpowiadaj?cy jej zestaw instrukcji assemblerowych. W zak?adce Variables zauwa?y? mo?na wszystkie zmienne lokalne danej funkcji. Aby doda? zmienne globalne wystarczy klikn?? w obszar tej zak?adki prawym przyciskiem myszy i skorzysta? z opcji Add Global Variables... . W zak?adce Registers po rozwini?ciu elementu Main mo?na natomiast podziwia? rejestry rdzenia.