ARM Register View für Eclipse - EmbSysRegView

BACHELORARBEIT
ARM Register View für Eclipse
ausgeführt von Ing. Robert Haslinger
Begutachter: Dipl. Ing. Michael Kramer
Wien, 29.1.2009
Ausgeführt an der FH Technikum Wien
Studiengang ICSS
Eidesstattliche Erklärung
„Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbständig angefertigt
habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche
kenntlich gemacht. Die Arbeit wurde bisher weder in gleicher noch in ähnlicher Form einer
anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht.“
____________________
Ort, Datum
_________________________
Unterschrift
Kurzfassung
Eclipse inklusive dem CDT Plug-In für die C/C++ Entwicklung kann in Verbindung mit
einer GNU Toolchain für die Entwicklung von Embedded Systems, wie zum Beispiel einem
Board mit CortexM3 Core von ARM, verwendet werden. Diese Arbeit bietet einen Einblick
wie diese Teile zusammenarbeiten um eine Open Source Entwicklungsumgebung unter
Windows zu erzeugen.
In der Embedded Device Entwicklung verbringen Entwickler sehr viel Zeit damit Bits in
Registern zu setzen um die Hardware zu konfigurieren. Noch mehr Zeit wird aufgewandt
falsch gesetzte Bits durch debuggen zu finden. In dieser Arbeit wird eine Register View
implementiert, die die Register in strukturierter Weise auflistet, und es erlaubt Bit Felder
innerhalb eines Registers anzuzeigen und die darin enthaltenen Werte mit einer Interpretation
zu versehen.
Schlagwörter: ARM, Cortex-M3, Eclipse, CDT, Register View, Debug
Abstract
With Eclipse including CDT, a Plug-In for C/C++ development, and a GNU Toolchain it is
possible to develop software for embedded systems. This thesis provides a view into how
these parts work together to build an open source development environment for windows.
Developers in the embedded spend lot of time manipulating bits in registers. Much more time
is used finding wrongly set bits through debugging. This thesis implements a register view,
which displays registers in a structured way, and allows listing of bit fields within registers.
Each of the bit fields is capable of displaying an interpretation of the value.
Keywords: ARM, Cortex-M3, Eclipse, CDT, Register View, Debug
Inhaltsverzeichnis
1
2
Entwickeln mit freier Software für den Cortex-M3 ........................................................... 1
1.1
Eine OpenSource Entwicklungsumgebung ................................................................. 1
1.2
Die Anwender .............................................................................................................. 1
1.3
Die Aufgabe ................................................................................................................. 2
Eclipse als IDE für Embeded Devices ................................................................................ 3
2.1
Einrichten einer Entwicklungsumgebung .................................................................... 3
2.1.1
Java ....................................................................................................................... 3
2.1.2
Eclipse .................................................................................................................. 3
2.1.3
CDT Plug-In ......................................................................................................... 4
2.1.4
GNUARM Plug-In ............................................................................................... 5
2.1.5
GNU Compiler Toolchain .................................................................................... 7
2.1.6
Stellaris Virtual COM Port Driver ....................................................................... 8
2.1.7
OpenOCD ............................................................................................................. 8
2.1.8
Erstellen eines Beispielprogramms ...................................................................... 8
2.2
Speicheraufbau der CortexM3 ................................................................................... 13
2.2.1
2.3
Lösungsansatz ............................................................................................................ 14
2.3.1
Memory View erweitern / Neue View erstellen ................................................. 14
2.3.2
Wann ändert sich der Speicherinhalt .................................................................. 16
2.3.3
Zugriff auf den Speicher während des Debuggens ............................................. 16
2.3.4
Aufbereitung der Daten für die View ................................................................. 16
2.4
Umsetzung des Prototypen ........................................................................................ 16
2.4.1
Implementierung der View ................................................................................. 16
2.4.2
Aufbau des DataModel für LM3S8962 .............................................................. 17
2.4.3
DebugEvent Benachrichtigung ........................................................................... 18
2.4.4
Auslesen des Speichers ....................................................................................... 19
2.4.5
Interpretation der Werte...................................................................................... 20
2.5
3
Memory Mapped Ports ....................................................................................... 14
Ergebnis ..................................................................................................................... 21
2.5.1
Gcc CortexM3 fähig, Code Sourcery gdb nötig ................................................. 21
2.5.2
ARM RegisterView Prototyp ............................................................................. 21
Open Source immer attraktiver......................................................................................... 22
3.1
Ausblick ..................................................................................................................... 22
Literaturverzeichnis .................................................................................................................. 23
Abbildungsverzeichnis ............................................................................................................. 24
Anhang A: OpenOCD Konfigurationsfiles .............................................................................. 25
2
1 Entwickeln mit freier Software für den Cortex-M3
Die Idee zu dieser Arbeit entstand aus dem Bedarf heraus die in der FH eingesetzte Hardware
und die dazugehörige Software Toolchain zu erneuern.
Ein C167 wird bis heute in der Lehrveranstaltung benutzt. Er ist ein 16bit Prozessor und
wurde von Siemens als Nachfolger des C166 entwickelt. Das er nicht mehr produziert wird ist
Grund dafür sich auf die Suche für einen zeitgemäßen Nachfolger zu machen.
Mit dem Wechsel des Mikrocontrollers geht auch der Wechsel der Entwicklertoolchain und
der Entwicklungsumgebung einher. Hier liegt das Augenmerk auf einer möglichst freien und
Quelloffenen Variante.
Einer der möglichen Nachfolgekandidaten ist ein Cortex-M3 von ARM. Für diese Architektur
gibt es eine GNU Entwicklertoolchain. In weiterer Folge dieser Arbeit wird der LM3S8962
von Luminary Micro verwendet.
1.1 Eine OpenSource Entwicklungsumgebung
Als Entwicklungsumgebung ist Eclipse mit CDT, der Erweiterung zur C IDE angedacht.
Eclipse mit CDT ist hervorragend geeignet um C/C++ Projekte zu entwickeln. Es bietet einen
Editor mit Autovervollständigung, Compilerintegration und einen integrierten Debugger.
Bei der Embedded Entwicklung können all diese Fähigkeiten genutzt werden. Ein weiteres
Feature von CDT ist die Unterstützung von Debugging von entfernten Geräten, auch Remote
Debugging genannt. Hierbei wird über einen GDB Proxy und JTAG eine Verbindung zum
Embeded Device hergestellt.
Da die Embedded Entwicklung sehr Hardware-nahe ist und die integrierte Peripherie über
Register konfiguriert werden, ist es bei der Fehlersuche oft sehr mühsam nur über die
Memory View von Adresse zu Adresse zu springen um den Inhalt der Peripherie Register zu
überprüfen. In kommerziellen IDEs ist eine Ansicht, die für den jeweils ausgewählten Chip
die zur Verfügung stehenden Peripherie Register auflistet und deren aktuellen Werte während
des Debuggens anzeigt vorhanden.
1.2 Die Anwender
Die Verfügbarkeit einer Peripherie Register Ansicht würde helfen eine Schwachstelle in CDT
für den Embedded Bereich auszumerzen, und der quelloffenste Lösung eine Chance zu geben.
Atmels AVR32 Studio basiert ebenfalls auf Eclipse besitzt so eine Ansicht, und ist frei
verfügbar, allerdings nicht quelloffen. Die ersten Benutzer dürften somit die Durchführer, sein
es nun Lektoren oder Studenten, dieser Evaluierung sein.
Sollte die Evaluierung zum Ergebnis haben, daß der Cortex-M3 samt GNU Toolchain und
Eclipse die neue Plattform für die Lehrveranstaltung wird, werden wohl noch so manche
Studenten Anwender dieser Ansicht sein.
Auf alle Fälle wird es ein Beitrag an die Embedded entwickelnde Open Source Gemeinde
sein, deren Alltag damit hoffentlich ein wenig bequemer wird.
1
1.3 Die Aufgabe
Es besteht also der Bedarf nach einer Strukturierten Anzeige der Peripherie Register während
des Debuggens in Eclipse.
Das Datenblatt des LM3S8962, zu finden unter [Lum08], definiert mehr als 1000 Register.
Diese in einer Liste anzuzeigen würde den Zugriff auf die Register zwar erleichtern aber
aufgrund des Umfangs keine Übersicht bieten. Um die Ansicht vernünftig nutzen zu können,
müssen die Register zu den Ports und die Ports zu PortGruppen gruppiert werden.
Ein einzelnes Register wiederum, wird unterteilt in einzelne Felder. Das GPIODATA Register
ist 32Bit lang und besitzt ein einziges Feld mit dem Namen DATA das aus den Bits 7-0
besteht.
GPIODATA
DATA
Abbildung 1: Das GPIODATA Register, nach [Lum08]
Das GPTMTAMR Register, das zur Konfiguration der General-Purpose Timers dient, hat 3
Felder deren Wert jeder für sich wichtig ist um zu verstehen wie der Timer konfiguriert ist.
GPTMTAMR
TAAMS
TACMR
TAMR
Abbildung 2: Das GPTMTAMR Register, nach [Lum08]
Daraus ergibt sich folgender Aufbau der Ansicht, in weiterer Folge View genannt:
PortGruppe, dient nur zur Gruppierung
von Ports gleicher Art
GPIOs
PortA
…
Einer von mehreren möglichen Ports in
einer Gruppe (enthält Basisadresse)
Register für PortF
PortF
GPIODATA
DATA (bits 7-0)
Feld mit 8 Bit innerhalb von GPIODATA
GPIODIR
GPIOIS
…
PortG
Abbildung 3: Aufbau der Register View
Bei den BitFeldern soll es zusätzlich möglich sein, eine Interpretation der Werte auszugeben.
Das lässt sich gut veranschaulichen, wenn dem GPIODATA Register ein weiteres Feld
2
hinzugefügt wird. Dieses Feld, besteht nur aus Bit0, und ist für das ein- beziehungsweise
ausschalten des Leds auf dem Evaluation Board verantwortlich. Aussehen soll das angezeigte
Feld bei ausgeschaltetem Led wie in Abbildung 4.
DATA (bits 7-0)
LED0 (bit 0)
0
Led ausgeschaltet
Abbildung 4: Interpretation des Wertes 0
Beziehungsweise bei eingeschaltetem Led wie in Abbildung 5.
LED0 (bit 0)
1
Led eingeschaltet
Abbildung 5: Interpretation des Wertes 1
Diese Interpretierung ist vor allem bei kurzen Bitfeldern mit einer aufzählbaren Menge an
definierten Werten sinnvoll, um sich einen Blick ins Datenblatt nach jedem Debug Step zu
ersparen.
Die Anzeige der Werte soll mit dem Start einer Debug Session beginnen, beziehungsweise
mit der ersten Unterbrechung und beim Beenden des zu debuggenden Programms wieder
aufhören. Bei jedem Debug Step sollen sich die sichtbaren Werte automatisch aktualisieren.
2 Eclipse als IDE für Embeded Devices
2.1 Einrichten einer Entwicklungsumgebung
Die Anleitung zum Download und Installation der Tools die benötigt werden um zum einen
Eclipse um eine Ansicht zu erweitern, als auch ein C Programm direkt auf dem LM3S8962
laufen zu lassen und zu debuggen wird hier anhand von Windows beschrieben.
Getestet wurde es mit der 32Bit wie auch der 64Bit Variante von Windows Vista.
2.1.1 Java
Java ist die grundlegende Voraussetzung um Eclipse überhaupt starten zu können. Eclipse ist
in der Sprache Java geschrieben und benötigt die Java Runtime um zu laufen.
Da das Ziel die Erweiterung von Eclipse um eine View ist, und dazu Java
Entwicklungswerkzeuge wie der Compiler und der Debugger notwendig sind, wird statt der
Java Runtime das Java Development Kit benötigt. Für diese Arbeit wurde das „Java SE
Development Kit 6u11“ verwendet. Informationen zu Java finden sie zum Beispiel in
[Chr09].
2.1.2 Eclipse
Eclipse begann als IDE für Java und ist mittlerweile zu einem offenen Framework zur
Entwicklung von Software nahezu aller Art herangewachsen. Es besteht seit Version 3.0 aus
3
einem Kern der die Plug-In lädt um Funktionalität zur Verfügung zu stellen. Im Falle der Java
IDE das Plug-In „JDE“. Weiterführende Infos zu Eclipse finden sich zum Beispiel in [Ber08].
Nach der Installation von Java kann Eclipse installiert werden. Da die neue Ansicht, in
Eclipse „View“ genannt, eine neue Funktionalität darstellt, muss dafür ein neues Plug-In
geschrieben werden. Es gibt ein Paket von Eclipse das speziell für dieses Aufgabengebiet
zusammengestellt wurde und alle nötigen Tools, sowie den Sourcecode der Eclipse Plug-In
beinhaltet. Es nennt sich „Eclipse for RCP/Plug-in Developers“.
Für das View Plug-In wird hierzu die Version Ganymed-SR1 (3.4.1) verwendet die auf der
Eclipse Homepage downgeloadet werden kann. Ausgeliefert wird Eclipse in Form eines Zip
Files das an einen beliebigen Ort zu entpacken ist.
Gestartet werden kann Eclipse über eclipse.exe im Eclipse Ordner.
2.1.3 CDT Plug-In
Für Entwicklung von Embedded Systemen wird zu einem großen Teil C oder C++ verwendet.
Die Funktionalität einer C/C++ IDE kann mit dem CDT Plug-In nachgerüstet werden.
Da CDT in der Version „Eclipse for RCP/Plug-in Developers“ nicht enthalten ist, muss sie
über die Update Funktionalität von Eclipse nachinstalliert werden. Im Menü
„Help““Software Updates…“ den Reiter „Available Software“ auswählen, „C and C++
Development“ auswählen und installieren.
Abbildung 6: C/C++ Entwicklungsumgebung nachinstallieren
Um ein Device wie den LM3S8962 Remote zu debuggen wird ein weiteres Plug-In benötigt,
das zwar ebenfalls ein Teil von CDT ist aber nicht direkt über die Ganymed Update Site
bezogen werden kann.
Um es installieren zu können, muss folgende Update Site zusätzlich ausgewählt sein:
„http://download.eclipse.org/tools/cdt/releases/ganymede“. Danach lässt sich das Plug-In
„GDB Hardware Debugging“ wie schon zuvor CDT nachinstallieren.
4
Abbildung 7: GDB Hardware Debugging nachinstallieren
2.1.4 GNUARM Plug-In
Damit Eclipse mit der GNU-Arm GCC Toolchain zusammenarbeitet benötigt man noch ein
weiteres Plug-In, das GNUARM Plug-In. Dieses Plug-In besteht nur aus einer XML Datei
und liefert CDT die nötigen Informationen wie und mit welcher Toolchain ein C Programm
für die ARM Architektur übersetzt wird. Leider hat es noch keine Definition für die
CortexM3 CPU.
Das bedeutet, dass das Plug-In bevor es für den CortexM3 verwendbar ist, noch erweitert
werden muss. Dazu benötigt man den Source Code des Plug-In. Der ist im Subversion
Repository des SourceForge Projekts [Hol08] abgelegt, und kann mittels dem Subclipse PlugIn für Eclipse oder dem GUI Subversion Client TortoiseSVN ausgecheckt werden. Alternativ
dazu besteht die Möglichkeit über das WebSVN von SourceForge ein .tar File mit dem PlugIn downzuloaden.
Ist das Plug-In in einem Ordner entpackt kann es über den Menüpunkt „File“  „Import“ in
den Workspace geladen werden. Im Import Dialog „Plug-in Developmen“  „Plug-ins and
Fragments“ wählen und dann „The target platform“ abwählen und den Pfad zum Plug-In
Source Verzeichnis angeben.
Abbildung 8: GNUARM Plug-In importieren
5
Anschließend das org.eclipse.cdt.gnuarm Plug-In auswählen und mit Add und Finish
importieren.
Da dieses Plug-In eine Abhängigkeit zu einem anderen Plug-In besitzt muss auch dieses
importiert werden, diesmal aber direkt aus Eclipse heraus. Der Import Vorgang muss also
noch einmal durchgeführt werden, und diesmal muss „The target platform“ ausgewählt
bleiben und mit Next bestätigt werden.
Abbildung 9: Plug-In Abhängigkeit importieren
Auf der nächsten Seite nun das Plug-In „org.eclipse.cdt.managedbuilder.core“ auswählen, mit
„Add“ zum Importieren vormerken und mit „Finish“ bestätigen.
Nun muss noch die plugin.xml des Plug-In erweitert werden. Dazu muss die plugin.xml
geöffnet und im XML Edit Reiter um den in Abbildung 10 markierten Text erweitert werden.
Abbildung 10: plugin.xml um cortex-m3 erweitern
Um zu testen ob das Plug-In funktioniert, kann man es wie in Abbildung 11 beschrieben als
Eclipse Applikation starten. Ein zweites Eclipse Fenster sollte aufgehen, das das GNUARM
Plug-In geladen hat.
Abbildung 11: Eclipse Applikation starten
6
2.1.5 GNU Compiler Toolchain
Um ein C Programm für den CortexM3 zu erstellen, benötigt man einen Compiler, Linker und
noch einige andere Tools. Da die Arbeitsplattform Windows x86 ist benötigen wir eine
Sammlung von Tools die unter Windows ausführbar ist, und Code generiert der auf einem
ARM CortexM3 lauffähig ist. Diese Art von Codegenerierung nennt sich CrossKompilierung. So eine Sammlung an Tools, in weiterer Folge Toolchain genannt, selbst zu
erstellen ist zwar möglich aber von der Komplexität her eine eigene Arbeit da es sich dabei
hauptsächlich für Unix geschriebene Tools handelt, die nicht immer ohne Probleme unter
Windows zum Laufen zu bringen sind. Selbst eine Toolchain zu kompilieren ist meist nur
dann nötig wenn man spezielle Patches benötigt, die in den vielen verfügbaren vorgefertigten
Toolchains nicht inkludiert sind.
Die Toolchain mit den aktuellsten Tool Versionen ist die von Zylin [Zyl08]. Sie ist in einer
Cross-kompilierten Form für Windows verfügbar und beinhaltet folgende Tools in den
aufgeführten Versionen.




gcc 4.3.2
gdb 6.8
binutils 2.18
newlib 1.16.0
Wie in [GCC09] ersichtlich unterstützt der aktuelle gcc-4.3.2 bereits die CortexM3 CPU und
kann somit für den LM3S8962 verwendet werden.
Nachdem das File „arm-elf.7z“ runtergeladen wurde, muss der Inhalt des „install“ Ordners im
.7z File nach z.B. „C:\RegisterView\mingw“ kopiert werden. Im Unterordner „bin“ befinden
sich die ausführbaren Programme der Toolchain. Diese Programme, zum Beispiel gcc.exe
werden vom gnuarm Plug-In per default ohne Pfadangabe aufgerufen. Dies sollte aus
Gründen der Portierbarkeit des Workspaces auch so belassen werden. Deshalb muss
„C:\RegisterView\mingw\bin“ der Umgebungsvariable PATH hinzugefügt werden.
Um beim Build Prozess die Source Code Files in der richtigen Reihenfolge zu übersetzen
benötigt man noch das Make Tool. Auch hier wird eine unter Windows lauffähige Version
benötigt. Zu finden ist es auf der Webseite von MinGW unter dem Filenamen „mingw32make-3.80.0-3.exe“. Wichtig bei der Installation ist dass es ebenfalls unter
„C:\RegisterView\mingw“ installiert wird damit das .exe File vom System über die PATH
Variable gefunden werden kann. Das installierte .exe File im Ordner
„C:\RegisterView\mingw\bin“ muss nun noch von „mingw32-make.exe“ nach „make.exe“
umbenannt werden.
Weiters wird in den automatisch generierten Makefiles zum Löschen von Dateien der Unix
Befehl „rm“ verwendet, den es unter Windows nicht gibt. Auch hier gibt es eine Version für
Windows, zu finden unter [Syr04], die in einer Sammlung von für Windows kompilierte Unix
Tools enthalten ist. Es wird nur rm.exe benötigt, das sich im Verzeichnis “\usr\local\wbin“
innerhalb des Zip Files findet und nach „C:\RegisterView\mingw\bin“ kopiert werden muss.
Der GNU Debugger in der Version 6.8 von Zylin ist leider nicht in der Lage mit dem
CortexM3 zu kommunizieren. Deshalb muss zum debuggen der gdb aus der CodeSourcery
7
Toolchain [Cod08] verwendet werden. Dazu muss aus dem Archiv arm-2008q3-66-arm-noneeabi-i686-mingw32.tar.bz von der Homepage von CodeSourcery das File arm-none-eabigdb.exe nach „C:\RegisterView\mingw\bin“ kopiert werden.
2.1.6 Stellaris Virtual COM Port Driver
Das LM3S8962 Board wird über ein USB Kabel mit Strom versorgt, und gleichzeitig mit dem
PC verbunden. Über die USB Verbindung wird mittels eines Chips von FTDI eine usb-toserial Umwandlung vorgenommen. Am PC wird ein Driver benötigt. Dieser Driver erzeugt
einen Serial Port über den der UART0 des Boards angesprochen werden kann.
Zu bekommen ist der Driver entweder von der mit dem Evaluierungs-Board mitgelieferten
CD oder von der Webseite von Luminary Micro. Ab Version 2.04.06 ist der Luminary FTDI
Driver auch unter Vista 64bit lauffähig.
2.1.7 OpenOCD
OpenOCD bildet die Schnittstelle zwischen dem gdb und dem Evaluierungs-Board. Über das
ft2232 Interface von OpenOCD wird über die USB Verbindung, wie in Abbildung 12 gezeigt,
Kontakt zum LM3S8962 aufgenommen.
PC
Eclipse
GDB
OpenOCD
USB
LM3S8962
Abbildung 12: OpenOCD Debug
Eine OpenOCD Version die mit dem CortexM3 funktioniert gibt es für Windows kompiliert
von Martin Thomas in der Version 20080409 auf seiner Webseite [Mar08]. Enthalten ist
OpenOCD in der SVN Version 555 und die benötigten Konfigurations-Files. OpenOCD kann
zum Flashen eines Programms auf das Board, sowie auch als DebugServer, verwendet
werden. Beide Tätigkeiten benötigen eine speziell angepasste Konfiguration und zum Flashen
zusätzlich noch ein Script, die beide im Anhang A zu finden sind.
Der Inhalt des Zipfiles und die eben erwähnten Konfigurationsdateien müssen in den Ordner
„C:\RegisterView\openocd-20080409“ kopiert werden.
2.1.8 Erstellen eines Beispielprogramms
Zum Testen der View eignet sich das klassische Embedded Äquivalent zu Hello World. Das
„Blinky“, es macht nichts anderes als ein Led periodisch ein und wieder auszuschalten. Beim
LM3S8962 bedeutet das, dass bit0 im Register GPIODATA des Port F der GPIO Ports auf 1
beziehungsweise 0 gesetzt wird. Hierfür muss zuerst ein C Projekt, wie in Abbildung 13
beschrieben, angelegt werden.
8
Abbildung 13: Neues C Projekt anlegen
Anschließend muss ein Ordner „src“ im Projekt angelegt werden.
Als Nächstes müssen vom EK-LM3S8962 Firmware Development Kit [Mic08] (SW-EKLM3S8962-3740.exe) aus dem Ordner "boards\ek-lm3s8962\blinky" die Files blinky.c,
blinky.ld und startup_gcc.c in das „src“ Verzeichnis kopiert werden. Außerdem ist noch das
File lm3s8962.h aus dem Verzeichnis „inc\“ notwendig, das ebenfalls ins src Verzeichnis
kopiert werden muss.
Im File Blinky.c muss nun noch die Include Anweisung auf #include "lm3s8962.h" angepasst
werden. Damit das Projekt kompiliert werden kann, sind einige Änderungen an Build
Optionen des Projekts zu tätigen. Dabei ist zu beachten, dass für die Konfiguration „Release“
als auch für „Debug“ jeweils getrennt jedes Setting eingestellt werden muss.
Zuerst muss auf der Seite der Tool Chain als Current builder „CDT-Internal Builder“
ausgewählt werden. (Siehe Abbildung 14)
9
Abbildung 14: Tool Chain – Current builder einstellen
Anschließend müssen in den C/C++ Build  Settings die Einstellungen zu Assember,
Compiler, Linker und ObjCopyFlash angepasst werden. Für den Assembler muss als Target
der cortex-m3 eingestellt werden.
Abbildung 15: Assembler Target Einstellungen
Beim Compiler Target muss ebenfalls cortex-m3, sowie auch „Generate 16-bit thumb code“
gewählt werden.
Abbildung 16: Compiler Target Einstellungen
Mit –mfpu=vfp wird dem Compiler gesagt welches Floating Point Format er verwenden soll.
Ohne diese Option würde er FPA als Format verwenden und es würde beim Linken zu
Fehlern kommen, da die vorkompilierten Librarys mit vfp kompiliert sind. Näheres dazu ist
unter [Zyl08] zu finden.
Abbildung 17: Compiler Miscellaneous Einstellungen
Für den Linker muss das Linker Script aus dem Firmware Development Kit angegeben
werden, das speziell für den LM3S8962 ausgelegt ist.
10
Abbildung 18: Linker General Einstellungen
Damit der Linker die Objekt Files des Blinky Programms mit denen der Newlib
Standardbibliothek verbinden kann, muss der Ordner „C:\RegisterView\mingw\lib\gcc\armelf\4.3.2“ im Library Suchpfad angegeben werden.
Abbildung 19: Linker Libraries Suchpfad
Zuguterletzt muss der Commandline Parameter von ObjCopyFlash bereinigt werden. Das
Feld „${INPUTS}“ am Ende der Zeile muss entfernt werden da sonst das Input File zweimal
angegeben wird und sich ObjCopyFlash mit einer Fehlermeldung darüber beschwert.
Abbildung 20: ObjCopyFlash Commandline Pattern
Nun ist es soweit, nach einem Klick auf „Build All“ wird Blinky kompiliert und die Console
sieht, wie in Abbildung 21 gezeigt, aus.
11
Abbildung 21: Console Build Ausgabe
Nach dem Übersetzen des Beispielprogramms muss es nun noch auf das Board geflasht
werden und danach kann es im Eclipse debugged werden.
Damit die Flash und Remote-Debug Funktionalität im Eclipse bequem zur Verfügung steht
bietet es sich an die beiden Aufrufe als „Externes Tool“ zu definieren. Dazu muss zuerst wie
in Abbildung 11 die Eclipse Applikation gestartet werden da dort auch das LM3S8962
Beispielprogramm laufen wird. In Abbildung 22 und Abbildung 23 wird gezeigt wie ein
neues externes Programm hinzugefügt wird und die beiden OpenOCD Aufrufe angelegt
werden.
Abbildung 22: Externe Tools einbinden
Abbildung 23: OpenOCD Flash / Debug
12
Zum Flashen reicht es das Board angesteckt zu haben und über Run  External Tools 
„OpenOCD Flash“ auszuwählen.
Um zu debuggen muss stattdessen der „OpenOCD Debug Server“ gestartet werden, und dann
über Run  „Debug Configurations…“ einmalig ein neuer Debug Eintrag angelegt werden,
siehe Abbildung 24, der dann im späteren Gebrauch verwendet werden kann.
Abbildung 24: Debug Konfiguration
Nun genügt es einen Breakpoint zu setzen, und auf Run  Debug History  Blinky zu
klicken um zu debuggen.
2.2 Speicheraufbau der CortexM3
Der Cortex-M3 besitzt eine festgelegte Speicheraufteilung. Dadurch ist es möglich auf z.B.
den Interrupt Controller oder Debug Komponenten über einen einfachen Speicher-Lesebefehl
zuzugreifen. Siehe auch [Yiu07].
Der 4GB adressierbare Bereich sieht wie folgt aus:
13
0xFFFFFFFF
System Ebene
Private Peripherie, inklusive
eingebautem Interrupt
Controller (NVIC), MPU
Kontroll-Register, und DebugKomponenten
Externe Geräte
Hauptsächlich für externe
Peripherie genutzt
Externer RAM
Hauptsächlich für externen
Speicher genutzt
0xE0000000
0xDFFFFFFF
0xA0000000
0x9FFFFFFF
0x60000000
0x5FFFFFFF
Peripherie
Hauptsächlich als Peripherie
genutzt
SRAM
Hauptsächlich als statischer
RAM genutzt
Code
Hauptsächlich als statischer
RAM genutzt
0x40000000
0x3FFFFFFF
0x20000000
0x1FFFFFFF
0x00000000
Abbildung 25: Speicheraufteilung CortexM3, nach [Yiu07]
2.2.1 Memory Mapped Ports
Hier interessiert hauptsächlich der Bereich der Peripherie von 0x40000000-0x5FFFFFFF.
Dort befinden sich die Register der Peripherie die in der View dargestellt werden sollen. Auch
hier genügt ein einfacher Zugriff auf den Speicher um den Wert eines Registers auszulesen.
Da die MemoryView in Eclipse diese Funktionalität bereits zur Verfügung stellt ist der erste
Ansatz der, in der MemoryView die Stelle zu suchen die den Speicher während des
Debuggens aus der DebugSession bzw. dem Gerät liest.
//
// Turn on the LED.
//
GPIO_PORTF_DATA_R |= 0x01;
2.3 Lösungsansatz
Um zum Inhalt eines Registers zu kommen reicht es also den Speicherinhalt an einer
bestimmten Adresse auszulesen. Die im Eclipse bereits enthaltene MemoryView macht genau
das. Es ist also sinnvoll sich die Memory View näher anzusehen
2.3.1 Memory View erweitern / Neue View erstellen
Die Memory View ist zweigeteilt. Links befindet sich eine Liste der zu beobachtenden
Speicheradressen und rechts passend zur ausgewählten Speicheradresse, der Inhalt des
Speichers, dargestellt über MemoryViewRenderer.
14
Abbildung 26: Memory View
Über die Renderer kann der Speicher wahlweise als Hex, ASCII oder zum Beispiel Integer
dargestellt werden. In Abbildung 26 sieht man die Adresse 0x400253FC die dem
GPIODATA Register des PortsF entspricht. Im Speicher befindet sich an Bit0 ein 1er, das
heißt, LED1 am LM3S8962 leuchtet.
Erweiterbar ist die Memory View vor allem über die Renderer, die den Inhalt des Speichers
interpretiert darstellen. Dazu gibt es ein einen Artikel mit einem kleinen Beispiel von
Samantha Chan, der auf Eclipse.org veröffentlicht wurde, siehe [Sam07]. In diesem Beispiel
wird gezeigt wie sich der Speicherinhalt als Baum darstellen lässt, siehe Abbildung 27. Es ist
dabei ersichtlich, dass damit nur der Speicher an der angegebenen Speicheradresse fortlaufend
ausgegeben werden kann.
Abbildung 27: Tree ViewRenderer nach [Sam07]
Es besteht die Möglichkeit alle Register in die Memory View einzutragen. Das wäre
allerdings viel zu unübersichtlich da es keine Gruppierungen in der linken Liste gibt.
Außerdem ist die Memory View dann kaum noch für den normalen Gebrauch verwendbar.
Daher ist es sinnvoll eine eigene View zu entwickeln die den Vorgaben von Abbildung 3
entspricht und dadurch eine strukturierte Aufbereitung der Daten bietet.
15
2.3.2 Wann ändert sich der Speicherinhalt
Informationen über den Speicherinhalt sind dann verfügbar, wenn eine laufende Debug
Session vorhanden ist und diese angehalten wurde. Dies kann entweder durch manuelle
Unterbrechung, wie auch durch Breakpoints und Watchpoints geschehen. Ein Zeile für Zeile
durchsteppen durch ein Programm bedeutet, aus dem angehaltenen Modus das Programm
weiterlaufen zu lassen bis die nächste Zeile im Source Code abgearbeitet wurde und dann
erneut die Ausführung zu unterbrechen. Es ist also notwendig mitzubekommen, wenn die
Ausführung unterbrochen wurde, um zu überprüfen ob sich an den Registerspeicheradressen
etwas geändert hat.
Das Debug Plug-In stellt eine Möglichkeit zur Verfügung um bei Statusänderungen einer
Debug Session benachrichtigt zu werden. Interessant ist hier primär das SUSPEND Event. Es
benachrichtigt wenn ein Programm im Debug Modus angehalten wurde.
2.3.3 Zugriff auf den Speicher während des Debuggens
Jedes Mal wenn ein SUSPEND Event auftritt muss jedes Register in der View überprüft
werden ob sich sein Inhalt verändert hat. Dieser Speicherzugriff ist in dem Objekt das das
Register implementiert enthalten, so dass es sich auf Zuruf selbst darum kümmert seinen
Inhalt aktuell zu halten.
2.3.4 Aufbereitung der Daten für die View
Da die meisten Register aus Bit Feldern bestehen und es daher wichtig ist auf einen Blick zu
erkennen welche Bits gesetzt sind, wird der Inhalt binär dargestellt.
Sollten noch keine Daten für ein Register verfügbar sein, das kann passieren, wenn zum
Beispiel keine Debug Session existiert oder sie noch nie unterbrochen wurde, wird nichts im
Feld Value angezeigt. Ebenfalls leer bleibt in diesem Fall jegliches Feld, das für ein Register
definiert ist.
2.4 Umsetzung des Prototypen
Eclipse besteht aus einem Kern und vielen Plug-Ins die die Funktionalitäten liefern. Um mit
der Register View Eclipse zu erweitern, benötigt man also ein neues Plug-In.
Der Name des Plug-Ins lautet „org.eclipse.cdt.armregview“. Um eine neue View zu erzeugen
muss man ViewPart extenden.
public class ArmRegView extends ViewPart
2.4.1 Implementierung der View
Die strukturierte Ansicht wird über eine JFace Komponente, dem TreeViewer realisiert. Dem
TreeViewer können mittels TreeViewerColumn Spalten wie in einer Tabelle angefügt
werden. Mit Hilfe der Baum Ansicht in der 1. Spalte und zwei weiteren Spalten ist es möglich
die in Abbildung 3 beschriebene Strukturierung zu erzeugen.
viewer = new TreeViewer(parent, SWT.H_SCROLL | SWT.V_SCROLL);
viewer.getTree().setLinesVisible(true);
16
viewer.getTree().setHeaderVisible(true);
// Register
column = new TreeViewerColumn(viewer, SWT.NONE);
column.getColumn().setWidth(200);
column.getColumn().setMoveable(true);
column.getColumn().setText("Register");
2.4.2 Aufbau des DataModel für LM3S8962
Der TreeViewer ist nur dafür zuständig wie die Daten aussehen. Um zu den Daten zu
kommen benötigt er einen IStructuredContentProvider. Dem TreeViewer muss ein Objekt
einer Klasse übergeben werden die das Interface IStructuredContentProvider implementiert.
Diese Klasse, auch DataModel genannt beliefert den TreeViewer mit den Daten. Die Daten
für die RegisterView werden durch folgende Klassen repräsentiert.
TreeElement
TreeField
TreeParent
TreeGroup
TreeRegisterGroup
TreeRegister
Abbildung 28: Data Model Klassen
Anhand von Abbildung 29, die Abbildung 3 ergänzt, wird verständlich wie die Klassen
zusammenarbeiten um die Ansicht zu erzeugen.
17
GPIOs
TreeGroup
TreeRegisterGroup
PortA
…
…
TreeRegisterGroup
PortF
GPIODATA
TreeRegister
TreeField
TreeRegister
GPIODIR
TreeRegister
GPIOIS
…
…
TreeRegisterGroup
PortG
Abbildung 29: Klassen-Baum Struktur
Mehrere GPIOs werden mithilfe eines TreeGroup Objekts Gruppiert. Es leitet von TreeParent
ab und verwaltet somit eine Liste an Kind Objekten. Kinder eines TreeGroup Objekts müssen
TreeRegisterGroup Objekte sein. TreeRegisterGroup Objekte gruppieren Register die zu einer
Peripherie Einheit gehören. Da sich TreeRegisterGroup ebenfalls von TreeParent ableitet,
verwaltet es eine Liste an Kind Objekten, die aus TreeRegister Objekten bestehen müssen.
Zur Verfeinerung besteht die Möglichkeit beliebig viele TreeField Objekte an ein
TreeRegister Objekt anzuhängen, da TreeRegister ebenfalls von TreeParent abgeleitet ist.
Diese TreeField’s bilden die Endknoten dieser Baumstruktur. Sie leiten von TreeElement ab
und haben somit keine Kinder. Vater eines TreeField’s ist immer ein TreeRegister, da es seine
Aufgabe ist ein TreeRegister feiner unterteilt aufzuschlüsseln.
2.4.3 DebugEvent Benachrichtigung
Um wie in 2.3.2 beschrieben vom Debug Plug-In über den SUSPEND Event benachrichtigt
zu werden, muss im Debug Plug-In ein EventListener registriert werden. Beim Registrieren
muss eine Klasse angegeben werden die IDebugEventSetListener implementiert. Deshalb
muss die Klassendeklaration aus 2.4 erweitert werden.
public class ArmRegView extends ViewPart implements
IDebugEventSetListener
Durch das Interface IDebugEventSetListener muss die Methode handleDebugEvents
implementiert werden. Der Aufruf um den EventListener zu registrieren und ihm als Callback
die eigene Klasse mitzugeben sieht folgendermaßen aus:
DebugPlugin.getDefault().addDebugEventListener(this);
Zu beachten ist, dass der Aufruf in dieser Form nur innerhalb der Klasse die
IDebugEventSetListener implementiert funktioniert.
18
2.4.4 Auslesen des Speichers
Tritt eine Statusänderung einer Debug Session auf wird wie in 2.4.3 beschrieben die Methode
handleDebugEvents aufgerufen. Diesem EventHandler wird ein Array von DebugEvent
Objekten mitgeliefert, die Informationen darüber enthalten was sich am laufenden Debug
Kontext geändert hat. Enthält es ein SUSPEND Event, wird der komplette Baum nach
TreeRegister Elementen durchsucht und deren updateValue() Methode aufgerufen. Damit
werden sie veranlasst ihre Werte des Registers zu erneuern.
Da das TreeRegister nur den Offset zur TreeRegisterGroup kennt muss zuerst mit dessen
Basis Adresse die Adresse des Registers im Speicher berechnet werden.
registerAdress=((TreeRegisterGroup)parent).getBaseAdress()+off
setAdress;
Anschließend wird über eine Utility Klasse der MemoryView von der aktiven Debug Session
ein Objekt erzeugt das den gewünschten Speicherblock repräsentiert.
IAdaptable context = DebugUITools.getDebugContext();
IMemoryBlockRetrieval retrieval =
MemoryViewUtil.getMemoryBlockRetrieval(context);
CMemoryBlockRetrievalExtension cdtRetrieval =
(CMemoryBlockRetrievalExtension) retrieval;
IMemoryBlock mem = (CMemoryBlockExtension)
cdtRetrieval.getMemoryBlock(registerAdress, 4);
Mithilfe der getBytesFromAddress Methode wird der Inhalt des Registers in Form eines
MemoryByte Arrays ausgelesen und in einen einzelnen long Wert umgerechnet und als value
Variable der Klasse gespeichert.
MemoryByte[] membyte = ((CMemoryBlockExtension)mem)
.getBytesFromAddress(BigInteger.valueOf(registerAdress), 4);
value = (long)(membyte[3].getValue());
value = ((long)value << 8) + (long)(membyte[2].getValue());
value = ((long)value << 8) + (long)(membyte[1].getValue());
value = ((long)value << 8) + (long)(membyte[0].getValue());
Nachdem alle TreeRegister Felder aktualisiert wurden, wird der TreeViewer angewiesen die
Darstellung mit aktuellen Daten aus dem DataModel zu aktualisieren. Dieser Aufruf muss
über asyncExec erfolgen da er nur im GUI Thread funktioniert.
19
Display.getDefault().asyncExec(new Runnable()
{
public void run() {
viewer.refresh();
}
});
2.4.5 Interpretation der Werte
Oft sind nur wenige Bits eines Registers relevant. Ein TreeField ermöglicht es Bit Felder
innerhalb eines Registers zu definieren. Die relevanten Bits können somit als eigener Eintrag
in der Ansicht dargestellt werden, wodurch es möglich ist auf einen Blick die wichtige
Information herauszulesen. Es ist möglich überlappende Definitionen zu erstellen, um zum
Beispiel ein 8 Bit breites DATA Feld von Bit 0 bis Bit 7 zu definieren, und zusätzlich das Bit
0 erneut als LED1 aufzulisten. Dies ermöglicht eine Ansicht der 8 Relevanten Bits, die im
Falle eines GPIO Ports die 8 Pins dieses Ports wiederspiegeln, sowie auch die Auflistung von
Bit 0 mit seiner bekannten Funktion als LED1.
Für jedes Bit Feld besteht die Möglichkeit eine Interpretation zu definieren. Eine
Interpretation ist vor allem bei kurzen Feldern wie zum Beispiel beim LED1 sinnvoll, bei
denen alle Bit Kombinationen bekannt und definiert sind. Felder wie das 8 Bit lange DATA
Feld mit seinen 256 möglichen Zuständen zu Beschreiben ist nicht sinnvoll.
Realisiert wird diese Interpretation mithilfe einer HashMap, die für jedes Bit Feld definiert
werden kann. Der Schlüssel der Einträge besteht aus einem String der Dezimalen
Repräsentation der Bits. Für das TAMR Feld (Bit 0-1) des GPTMTAMR Registers gibt es 4
mögliche Zustände (00,01,10,11). Somit sind die Schlüssel um den jeweiligen Zustand zu
beschreiben (“0“,“1“,“2“,“3“). Zugehörig zum passenden Schlüssel kann ein String zur
Beschreibung des Zustandes in der HashMap abgelegt werden. Für das TAMR Feld sieht das
wie folgt aus:
HashMap<String, String> interpretationsGPT0TAMR =
new HashMap<String, String>();
interpretationsGPT0TAMR.put("0", "Reserved");
interpretationsGPT0TAMR.put("1", "One-Shot Timer mode");
interpretationsGPT0TAMR.put("2", "Periodic Timer mode");
interpretationsGPT0TAMR.put("3", "Capture mode");
TreeField GPT0TAMR = new
TreeField("TAMR","",(byte)30,(byte)2,interpretationsGPT0TAMR);
Soll es für ein TreeField keine Interpretation geben, so wie zum Beispiel bei dem DATA Feld,
muss eine leere HashMap beim Konstruktor angegeben werden.
20
In der Spalte Description wird für die Objekte TreeGroup, TreeRegisterGroup und
TreeRegister die definierte Beschreibung durch den Aufruf getDescription() ausgegeben. Für
ein TreeField wird stattdessen eine Interpretation des Feldwertes durch die Methode
getInterpretation() angezeigt. Findet getInterpretation() für den angeforderten Wert keinen
Eintrag in der HashMap liefert es einen leeren String zurück. Es ist also nicht notwendig alle
möglichen Zustände eines Feldes zu beschreiben, oder die fehlenden mit „undefiniert“
aufzufüllen.
Somit ist es möglich die im Datenblatt angegebenen Informationen zur Interpretation der
Werte in der Ansicht zu nutzen. Für den Entwickler bringt das eine enorme Entlastung, da er
nicht bei jeder Änderung der Daten im Register beziehungsweis im Feld einen Blick in die
Dokumentation des Boards werfen muss.
Felder deren Bedeutung durch ein anderen Feldes entsteht, müssen das im Beschreibungstext
dem User erklären. Eine automatische Auswahl der Bedeutung bedingt durch ein anderes Feld
ist nicht möglich.
2.5 Ergebnis
2.5.1 Gcc CortexM3 fähig, Code Sourcery gdb nötig
Bei der Toolchain ist es derzeit leider nicht möglich mit Tools aus den offiziellen Sourcen von
GDB zu arbeiten. Einziger Ausweg ist der GDB von Code Sourcery. Es wird wohl noch
einige Zeit dauern bis die Änderungen in den offiziellen GDB einfließen.
Im Gegensatz dazu gelingt es mit dem offiziellen GCC einwandfreien Code für den CortexM3
zu generieren.
2.5.2 ARM RegisterView Prototyp
In Abbildung 30 ist der Prototyp zu sehen der im Laufe dieser Arbeit entwickelt wurde. Er
setzt die beschriebene Art der Registeranzeige um und erfüllt die in ihn gesetzten
Erwartungen.
Abbildung 30: Prototyp
21
3 Open Source immer attraktiver
Mit einer komplette Open Source Entwicklungsumgebung für den Embedded Bereich mit
Hilfe einer GNU Toolchain und Eclipse mit CDT als Entwicklungsumgebung ist mittlerweile
sehr gut zu arbeiten. Eclipse und CDT haben einen langen Weg hinter sich und bieten immer
mehr Features und Stabilität. Fehlende Features wie das, das diese Arbeit mit einer Peripherie
Register Ansicht schließt, werden immer weniger und dadurch für mehr Entwickler und
Projekte interessant.
3.1 Ausblick
Der Prototyp zeigt wie Register in einer übersichtlichen Form in einer View in Eclipse
angezeigt werden können. Bei der Implementierung wurde ein statisches, fix codiertes
DataModel verwendet, das einen kleinen Ausschnitt der Register des LM3S8962 zu
Demonstrationszwecken anzeigt. Um die View praktisch nutzen zu können muss das
DataModel aus einer Datenquelle, zum Beispiel einem XML File, generiert werden. Weiter
sollte über einen Konfigurationsdialog eine Möglichkeit geschaffen werden zwischen
unterschiedlichen Boards umzuschalten, und die unterschiedlichen Register anderer Boards
aufzulisten.
22
Literaturverzeichnis
[Lum08] Micro, Luminary. LM3S8962 Microcontroller DATA SHEET. Austin : Luminary
Micro, 16. Nov. 2008.
[Chr09] Christian, Ullenboom. Java ist auch eine Insel. 8. Auflage. s.l. : Galileo Computing,
2009. 978-3-8362-1371-4.
[Ber08] Daum, Berthold. Java-Entwicklung mit Eclipse 3.3. 5. Auflage. s.l. : Dpunkt, 2008.
978-3898645041.
[Hol08] Holzke, Wilfried. Eclipse CDT Manged Build Extension for GNU ARM Toolchain.
[Online] 15. 10 2008. [Zitat vom: 27. 1 2009.] http://sourceforge.net/projects/gnuarmeclipse/.
[Zyl08] Zylin. GCC & GDB binaries. [Online] 2008. [Zitat vom: 27. 1 2009.]
http://www.zylin.com/gccbinary.html.
[GCC09] GCC. ARM Options - Using the GNU Compiler Collection. [Online] 2008. [Zitat
vom: 27. 1 2009.] http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/ARM-Options.html#ARMOptions.
[Syr04] Syring, Karl M. GNU utilities for Win32. [Online] 30. 4 2004. [Zitat vom: 27. 1
2009.] http://unxutils.sourceforge.net/.
[Cod08] CodeSourcery. Sourcery G++ Lite Edition for ARM. [Online] 2008. [Zitat vom: 27.
1 2009.] http://www.codesourcery.com/gnu_toolchains/arm/download.html.
[Mar08] Thomas, Martin. Using OpenOCD and ARMv7 Cortex-M3. [Online] 9. 4 2008.
[Zitat vom: 27. 1 2009.] http://www.siwawi.arubi.unikl.de/avr_projects/arm_projects/openocd_cortex/index.html.
[Mic08] Micro, Luminary. Firmware Development Packages. [Online] 2008. [Zitat vom: 27.
1 2009.] http://www.luminarymicro.com/products/software_updates.html.
[Yiu07] Yiu, Joseph. The Definitive Guide to the Arm Cortex-M3. s.l. : Butterworth
Heinemann, 2007. 978-0750685344.
[Sam07] Chan, Samantha. Inside the Memory View: A Guide for Debug Providers. [Online]
7. 9 2007. [Zitat vom: 27. 1 2009.] http://www.eclipse.org/articles/article.php?file=ArticleMemoryView/index.html.
23
Abbildungsverzeichnis
Abbildung 1: Das GPIODATA Register, nach [Lum08] ........................................................... 2
Abbildung 2: Das GPTMTAMR Register, nach [Lum08] ......................................................... 2
Abbildung 3: Aufbau der Register View .................................................................................... 2
Abbildung 4: Interpretation des Wertes 0 .................................................................................. 3
Abbildung 5: Interpretation des Wertes 1 .................................................................................. 3
Abbildung 6: C/C++ Entwicklungsumgebung nachinstallieren ................................................. 4
Abbildung 7: GDB Hardware Debugging nachinstallieren ........................................................ 5
Abbildung 8: GNUARM Plug-In importieren ........................................................................... 5
Abbildung 9: Plug-In Abhängigkeit importieren ....................................................................... 6
Abbildung 10: plugin.xml um cortex-m3 erweitern ................................................................... 6
Abbildung 11: Eclipse Applikation starten ................................................................................ 6
Abbildung 12: OpenOCD Debug ............................................................................................... 8
Abbildung 13: Neues C Projekt anlegen .................................................................................... 9
Abbildung 14: Tool Chain – Current builder einstellen ........................................................... 10
Abbildung 15: Assembler Target Einstellungen ...................................................................... 10
Abbildung 16: Compiler Target Einstellungen ........................................................................ 10
Abbildung 17: Compiler Miscellaneous Einstellungen ............................................................ 10
Abbildung 18: Linker General Einstellungen ........................................................................... 11
Abbildung 19: Linker Libraries Suchpfad ................................................................................ 11
Abbildung 20: ObjCopyFlash Commandline Pattern ............................................................... 11
Abbildung 21: Console Build Ausgabe .................................................................................... 12
Abbildung 22: Externe Tools einbinden................................................................................... 12
Abbildung 23: OpenOCD Flash / Debug ................................................................................. 12
Abbildung 24: Debug Konfiguration ........................................................................................ 13
Abbildung 25: Speicheraufteilung CortexM3, nach [Yiu07] ................................................... 14
Abbildung 26: Memory View .................................................................................................. 15
Abbildung 27: Tree ViewRenderer nach [Sam07] ................................................................... 15
Abbildung 28: Data Model Klassen ......................................................................................... 17
Abbildung 29: Klassen-Baum Struktur .................................................................................... 18
Abbildung 30: Prototyp ............................................................................................................ 21
24
Anhang A: OpenOCD Konfigurationsfiles
debug.cfg
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface ft2232
ft2232_device_desc "Stellaris Evaluation Board A"
ft2232_layout evb_lm3s811
ft2232_vid_pid 0x0403 0xbcd9
jtag_speed 10
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#LM3S811 Evaluation Board has only srst
#reset_config trst_and_srst
reset_config srst_only
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture
Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#target configuration
target cortex_m3 little run_and_halt 0
#flash configuration
flash bank stellaris 0 0 0 0 0
# working area
working_area 0 0x20000000 0x2000 nobackup
25
flash.cfg
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface ft2232
ft2232_device_desc "Stellaris Evaluation Board A"
ft2232_layout evb_lm3s811
ft2232_vid_pid 0x0403 0xbcd9
jtag_speed 10
jtag_nsrst_delay 100
jtag_ntrst_delay 100
#LM3S811 Evaluation Board has only srst
reset_config srst_only
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture
Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
#target configuration
daemon_startup reset
#target
target cortex_m3 little run_and_init 0
#flash configuration
flash bank stellaris 0 0 0 0 0
flash auto_erase on
# working area
working_area 0 0x20000000 0x2000 nobackup
# script running on reset
target_script 0 reset C:\RegisterView\openocd20080409\flash.script
26
flash.script
halt
sleep 200
flash
flash
flash
flash
probe 0
erase_check 0
protect_check 0
info 0
flash write_image ./Blinky.elf 0 elf
sleep 200
reset run
shutdown
27
28