Controller

      JTAG debugging mit Eclipse


Home ARM-Projekt Startupcode Bootloader myprintf() JTAG debugging Funksteck- dosen


  ARM-HW debuggen mit Eclipse und OpenOCD

Voraussetzung: Eclipse + CDT(C environment) + Yagarto(GCC compiler) müssen schon funktionieren.

 Zusammen mir dem RS232-Downloadtool (siehe STM32 RS232 Bootloader) läuft das z.B. schon sehr stabil. Wem das Printf-Debugging nicht mehr reicht, dem hilft diese Seite weiter.

  Installation des FTDI-Treibers

Der zum JTAG adapter (z.B. Turtelizer 2) mitgelieferte Treiber ist meist schnell installiert. Damit openocd ihn auch findet, muß der installierte JTAG-Treiber allerdings auf einenLIBUSB-Treiber umgebogen werden. Dazu läd man sich das OpenOCD Paket von Freddie Chopin herunter. Im Windows-Gerätemanager unter "USB-Controller" ersetzt man den entsprechenden Treiber. So muß es aussehen:


  Test der Verbindung zwischen OpenOCD und FTDI-HW

Dazu rufen wir in der DOS-Box im openocd\bin Verzeichnis folgendes auf:
       openocd -f interface/turtelizer2.cfg -f target/stm32f1x.cfg

Damit sollte er schon die Ziel-HW (hier ein STM32-Prozessor mit Turtelizer-JTAG-Adapter) finden.

  Einrichtung von Eclipse

Zunächst muß an im "External Tools"-Menü einen neuen Eintrag machen
 

Jetzt rufen Sie dieses Tool aus der Eclipse-Oberfläche auf. OpenOCD stellt nun einen Server zur Verfügung, der bei Windows über den  localhost:port 3333 zu erreichen ist. Dieser Server bleibt während der ganzen Sitzung gestartet. Die Firewall darf diesen Port 3333 natürlich nicht blocken!




Nun muß der Yagarto GCC debugger eingerichtet werden.
ggf. muß der Eclipse-gdb-Support vorher separat aus Eclipse heraus von den Repositiries installiert werden.
  1. Gehe zu Help > Install New Software.
  2. Füge CDT repository http://download.eclipse.org/tools/cdt/releases/juno zu der Liste der  Repositories hinzu.
  3. Installiere  Eclipse C/C++ GDB Hardware Debugging.
 

Für das Debuggen braucht man kaum Settings. Das sieht dann so aus:


 Typische Probleme mit Eclipse

  • Der Debugger stoppt am Breakpoint, Eclipse findet jedoch nicht die richtige Stelle im C code. Das geschieht z.B. dann, wenn der Linker ungenutzten Code eliminiert hat. Die Zeilen danach findet Eclipse nicht.
Abhilfe: Verschiebe vorauss. ungenutzten Code ans Ende eines jeden C files.

  • Manchmal springt der Debugger scheinbar wild in einer Funktion umher. Das könnte an einer zu hohen Optimierung beim Compilieren liegen.
Abhilfe: Ändern Sie im make-File die Optimierung auf -O0 oder -O1. Das führt zwar zu doppelt so großem Code als bei -O2 oder-Os , macht das Debuggen aber angenehmer.

  • FW-Upload: Der debugger kann das *.elf File (vor dem debuggen) nicht in die Ziel-HW laden. Hier kursieren verschiedene Tipps, zusätzliche Befehle in die Debugger Run Configurations einzutragen. Die Befehle für OpcenOCD werden per monitor Befehl an den Debugger gesendet. Hier gibt es etwas Spielraum, da nicht jede HW alle Befehle unterstützt.
    Für STM 32 sollte man z.B die Interrupts während des FW-Upgrades verbieten.

 Fazit

  Die Einrichtung von Eclipse ist schon etwas hakelig und nicht wirklich straight-forward. Man darf z.B. keine Verzeichnisnamen im Projekt verändern, sonst läuft das Eclipse Workspace-Konstukt gegen die Wand.
Wenn es aber erstmal läuft, dann kann man beliebig Breakpoints setzen, durchsteppen und Variablen überwachen (Watches setzen).

 Links

Eclipse einrichten