Strona główna Artykuły ARM ARM toolchain - tutorial
ARM toolchain - tutorial
Ocena użytkowników: / 299
SłabyŚwietny 
Wpisany przez Freddie Chopin   
Niedziela, 17 Maj 2009 16:36
Spis treści
ARM toolchain - tutorial
ARM toolchain
Debugger
Edytor (IDE)
Eclipse + OpenOCD + GDB
Epilog
Wszystkie strony

Debugger

Kolejnym kroczkiem, całkowicie niezależnym od poprzedniego, może być instalacja debuggera OpenOCD.

W chwili pisania tych słów OpenOCD dostępny jest w wersji 0.1.0 i jest to pierwszy oficjalny "release". Na stronie projektu OpenOCD (oraz w sekcji Download tej strony) dostępny jest instalator najnowszej wersji OpenOCD dla systemu Windows (nawiasem mówiąc stworzony przeze mnie [; ). Dodatkowo na stronie projektu można znaleźć kod źródłowy do samodzielnej kompilacji oraz skompilowaną paczkę dla Linuxa.

Proces instalacji OpenOCD jest w miarę oczywisty - sugeruję pozostawienie wszystkich opcji instalacji domyślnych - całość po zainstalowaniu zajmuje mniej niż 5MB.

Po zakończeniu instalacji warto sprawdzić jej poprawność - w Wierszu polecenia, w dowolnym folderze można wykonać komendę openocd --version, co powinno zaowocować następującym komunikatem (detale zależne oczywiście od wersji):

C:\>openocd --version
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:// Adres poczty elektronicznej jest chroniony przed robotami spamującymi. W przeglądarce musi być włączona obsługa JavaScript, żeby go zobaczyć. /svnroot/repos/openocd/tags/openocd-0.1.0/src
/openocd.c $

Jeśli OpenOCD działa samo w sobie, to można przetestować jak spisuje się w komunikacji z rzeczywistym układem za pośrednictwem interfejsu JTAG. Ponieważ kwestia konfiguracji OpenOCD wykracza poza tematykę tego artykułu (w przyszłości planowany osobny tekst na ten temat), skupię się na efekcie finalnym. Mój zestaw testowy to makieta z mikrokontrolerem LPC2103 (rdzeń ARM7TDMI-S) oraz JTAG-lock-pick. Aby połączyć się z układem w Wierszu polecenia wydać należy komendę openocd -f interface/jtagkey.cfg -f target/lpc2103.cfg (pliki konfiguracyjne mogą wymagać minimalnej modyfikacji - głównie w kwestiach szybkości rdzenia, która ogranicza też dozwoloną szybkość JTAGa). Efektem powinno być uruchomienie OpenOCD i następujące komunikaty:

C:\>openocd -f interface/jtagkey.cfg -f target/lpc2103.cfg
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:// Adres poczty elektronicznej jest chroniony przed robotami spamującymi. W przeglądarce musi być włączona obsługa JavaScript, żeby go zobaczyć. /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

Istotnym faktem jest to, że OpenOCD wciąż jest uruchomiony - okno Wiersza polecenia jest "zablokowane" dopóki oprogramowanie nie zakończy działania - albo w sposób naturalny (rozkaz zakończenia lub błąd uniemożliwiający dalszą pracę), albo w sposób wymuszony (kombinacja klawiszy Ctrl+C). OpenOCD wykorzystywany będzie głównie jako oprogramowanie wykonujące rozkazy GDB, nic nie stoi jednak na przeszkodzie, aby sterować nim za pomocą telnetu. Oby połączyć się z OpenOCD przez telnet konieczne jest otworzenie kolejnego Wiersza polecenia, w który wstukać należy polecenie telnet localhost 4444, co zaowocuje połączeniem z oprogramowaniem nasłuchującym na naszym komputerze na porcie 4444 - po poprawnym połączeniu tajemnicze oprogramowanie przedstawi się jako... Open On-Chip Debugger. Prostego testu można dokonać wydając poniższe komendy:

1. reset a następnie halt, co powinno zaowocować następującą odpowiedzią:

> reset
JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787,
Part: 0xf1f0, Version: 0x4)
JTAG Tap/device matched

invalid mode value encountered
cpsr contains invalid mode value - communication failure
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x80000097 pc: 0x00000038

Oczywiście dla innego rdzenia lub innego układu odpowiedź będzie inna.

2. poll - komenda pozwalająca zbadać aktualny stan rdzenia, wartość rejestru statusowego (xPSR) oraz licznika programu (PC). Typowa odpowiedź na tą komendę (zakładając, że wcześniej rdzeń został zatrzymany) wyglądać może na przykład tak:

> poll
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x80000093 pc: 0x00000038

3. reg - w tej formie komenda spowoduje wyświetlenie zawartości wszystkich rejestrów "ogólnych" rdzenia. Dla ARM7TDMI-S odpowiedź wygląda w sposób następujący:

> reg
(0) r0 (/32): 0x00000000 (dirty: 1, valid: 1)
(1) r1 (/32): 0x40001a18 (dirty: 1, valid: 1)
(2) r2 (/32): 0x40001a18 (dirty: 0, valid: 1)
(3) r3 (/32): 0x40001a14 (dirty: 0, valid: 1)
(4) r4 (/32): 0xffffffff (dirty: 0, valid: 1)
(5) r5 (/32): 0xffffffff (dirty: 0, valid: 1)
(6) r6 (/32): 0xffffffff (dirty: 0, valid: 1)
(7) r7 (/32): 0xffffffff (dirty: 0, valid: 1)
(8) r8 (/32): 0xffffffff (dirty: 0, valid: 1)
(9) r9 (/32): 0xffffffff (dirty: 0, valid: 1)
(10) r10 (/32): 0xffffffff (dirty: 0, valid: 1)
(11) r11 (/32): 0xffffffff (dirty: 0, valid: 1)
(12) r12 (/32): 0xffffffff (dirty: 0, valid: 1)
(13) r13_usr (/32): 0x40001af8 (dirty: 0, valid: 1)
(14) lr_usr (/32): 0xa07d0000 (dirty: 0, valid: 1)
(15) pc (/32): 0x400000d8 (dirty: 1, valid: 1)
(16) r8_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(17) r9_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(18) r10_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(19) r11_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(20) r12_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(21) r13_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(22) lr_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(23) r13_irq (/32): 0x00000000 (dirty: 0, valid: 0)
(24) lr_irq (/32): 0x00000000 (dirty: 0, valid: 0)
(25) r13_svc (/32): 0xffffffff (dirty: 0, valid: 0)
(26) lr_svc (/32): 0xffffffff (dirty: 0, valid: 0)
(27) r13_abt (/32): 0x00000000 (dirty: 0, valid: 0)
(28) lr_abt (/32): 0x00000000 (dirty: 0, valid: 0)
(29) r13_und (/32): 0x00000000 (dirty: 0, valid: 0)
(30) lr_und (/32): 0x00000000 (dirty: 0, valid: 0)
(31) cpsr (/32): 0x60000010 (dirty: 0, valid: 1)
(32) spsr_fiq (/32): 0x00000000 (dirty: 0, valid: 0)
(33) spsr_irq (/32): 0x00000000 (dirty: 0, valid: 0)
(34) spsr_svc (/32): 0x80000097 (dirty: 0, valid: 0)
(35) spsr_abt (/32): 0x00000000 (dirty: 0, valid: 0)
(36) spsr_und (/32): 0x00000000 (dirty: 0, valid: 0)
(37) debug_ctrl (/6): 0x05 (dirty: 0, valid: 1)
(38) debug_status (/5): 0x09 (dirty: 0, valid: 0)
(39) comms_ctrl (/32): 0x40000000 (dirty: 0, valid: 0)
(40) comms_data (/32): 0x00000000 (dirty: 0, valid: 0)
(41) watch 0 addr value (/32): 0x00000000 (dirty: 0, valid: 0)
(42) watch 0 addr mask (/32): 0xffffffff (dirty: 0, valid: 1)
(43) watch 0 data value (/32): 0xdeeedeee (dirty: 0, valid: 1)
(44) watch 0 data mask (/32): 0x00000000 (dirty: 0, valid: 1)
(45) watch 0 control value (/32): 0x00000100 (dirty: 0, valid: 1)
(46) watch 0 control mask (/32): 0x000000f7 (dirty: 0, valid: 1)
(47) watch 1 addr value (/32): 0x00000000 (dirty: 0, valid: 0)
(48) watch 1 addr mask (/32): 0x00000000 (dirty: 0, valid: 0)
(49) watch 1 data value (/32): 0x00000000 (dirty: 0, valid: 0)
(50) watch 1 data mask (/32): 0x00000000 (dirty: 0, valid: 0)
(51) watch 1 control value (/32): 0x00000000 (dirty: 0, valid: 0)
(52) watch 1 control mask (/32): 0x00000000 (dirty: 0, valid: 0)

4. step (kilkukrotnie), aby sprawdzić możliwość kontrolowania rdzenia. Próba użycia tej komendy wymaga oczywiście obecności jakiegoś programu w pamięci układu. Przy kolejnych wywołaniach tej komendy zauważyć można zmiany rejestru PC. Przykładowo może to wyglądać tak:

> step
target state: halted
target halted in ARM state due to single-step, current mode: User
cpsr: 0x60000010 pc: 0x400000dc

> step
target state: halted
target halted in ARM state due to single-step, current mode: User
cpsr: 0x60000010 pc: 0x400000e0

> step
target state: halted
target halted in ARM state due to single-step, current mode: User
cpsr: 0x60000010 pc: 0x400000e4

> step
target state: halted
target halted in ARM state due to single-step, current mode: User
cpsr: 0x60000010 pc: 0x400000e8

5. ... w manualu do OpenOCD można znaleźć dokładny opis wielu komend, którymi możemy kontrolować rdzeń lub odczytywać / zapisywać pamięć - celem tego artykułu nie jest jednak wymienienie ich wszystkich (; .



Zmieniony: Piątek, 12 Czerwiec 2009 11:31