STM32 Eclipse Installation

Wechseln zu: Navigation, Suche

Dieser Artikel beschreibt, wie man Eclipse unter Windows installiert und für den Prozessor STM32 einrichtet, so dass ein Debuggen möglich ist.

Installation von Eclipse unter Windows

Die Zusammenhänge:

  • Eclipse - der Editor, ist eigentlich nichts weiteres als ein Editor, mit sehr viel Intelligenz
  • Toolchain (make, Compiler, Linker, GDB, Bibliotheken, etc.). Hier gibt es verschiedene Möglichkeiten, für eine vollständige Auflistung siehe ARM GCC.
    • GCC-ARM-Embedded. Um diese Toolchain mit Eclipse zu nutzen benötigt man zusätzlich make und rm z.B. durch Installation der gnuwin packages oder aus den Yagarto-Tools. GDB und newlib enthalten.
    • CodeSourcery - beinhaltet alle benötigten Tools, wie make, GCC, GDB, Newlib usw.
    • Die YAGARTO GNU ARM toolchain (wird nicht mehr weiterentwickelt) - der Compiler und Debugger für Cortex-M3. Zusätzlich werden die Yagarto-Tools (make und sonstige Programme) benötigt.
  • CDT - Plugin, das Eclipse erweitert, sodaß C/C++ Programme editiert, kompiliert und gelinkt werden können. CDT steht für "C/C++ Development Tooling". Man kann Eclipse auch mit schon integrierten CDT auf der Eclipse Homepage bekommen.
  • GDB Hardware Debugging - ein weiteres Eclipse-Plugin, welches notwendig ist, um mittels GDB und weiteren Tools Programme zu debuggen.
  • GDB - der GNU Debugger, mit ihm ist es möglich, entsprechend kompilierte Programme auf C-Sourcelevel (und auch Assembler) zu debuggen. Er kann allerdings nicht direkt mit einem JTAG-Interface sprechen. Er "verbindet" sich dafür mit einem GDB-Server, der dann das JTAG-I/F anspricht.
  • GDB-Server - stellt eine Verbindung mit GDB und dem JTAG-Interface her. Er führt die Kommandos des GDBs aus. Der Server muss vor dem debuggen gestartet werden, da GDB einen laufenden GDB-Server erwartet. Die Verbindung zwischen dem GDB und dem GDB-Server wird über eine TCP/IP Verbindung hergestellt.
    • OpenOCD - ein freier GDB-Server
    • Texane STlink - ebenfalls frei
  • JTAG-Interface, z.B. Olimex ARM-USB-OCD, ST-Link oder diverse andere. Meist über USB an den PC angeschlossen, über ein JTAG-Kabel wird der Adapter mit der Prozessor-Platine verbunden. Der GDB-Server nimmt Kommandos vom GDB entgegen und führt diese über das JTAG-I/F des Prozessors aus.
  • STM32-Prozessor, ja den braucht es auch noch, sonst gibt es nichts zu debuggen.

Es sieht zwar auf den ersten Blick etwas komplex aus, aber es ist dennoch logisch aufgebaut.

Downloads

Die benötigten Dateien für Eclipse:

Eclipse Demo-Projekt:

Blink-LED, komplettes Eclipse-Workspace von MmVisual

  • Eclipse Workspace
  • Mit OpenOCD und Dateien für den Olimex ARM-USB-OCD
  • FW-Lib 3.4.0 von ST
  • Start-Up Code als C-Datei, keine einzige Assembler-Datei
  • Für STM32F103RB (128K Flash) wegen Initialisierung Stack-Pointer
  • Nutzt make Tool, muss aber zu gmake umbenannt werden, ist weiter unten beschrieben

Installation

Installation von Eclipse

Damit Eclipse gestartet werden kann, ist es nötig, dass zunächst Java installiert wird. Dabei muss einfach den Anweisungen des Installers gefolgt werden. Nachdem diese Installation abgeschlossen wurde, kann mit der Eclipse "Installation" fortgefahren werden.

Eclipse befindet sich (sofern im Download ausgewählt) in einem ZIP-Archiv. In diesem Archiv sind alle benötigten Dateien vorhanden, um Eclipse direkt starten zu können. Dieses ZIP-Archiv sollte dann zu C:\eclipse\ entpackt werden. In diesem Beispiel wird davon ausgegangen, dass eclipse zu den o.g. Pfad entpackt wird.

Sobald Eclipse vollständig entpackt wurde, kann eclipse gestartet werden. Während Eclipse startet, muss ein sog. Workspace ausgewählt werden. In diesem Workspace werden später alle Projekte und Sourcecodes abgelegt. Die Nachfolgende Grafik zeigt dieses Dialog-Fenster. Choose workspace.png Nachdem Eclipse erfolgreich gestartet werden kann, ist die Installation natürlich nicht abgeschlossen, da noch ein Compiler usw. für dem ARM-Mikrocontroller fehlt.

Für die Toolchain, sprich Compiler, newlib usw. hat man nun die Qual der Wahl, entweder man nimmt Yagarto-Tools oder Codesourcery. Der Unterschied zwischen den beiden toolchains ist nicht direkt erkennbar und soll an dieser Stelle nicht weiter behandelt werden. Ich verweise an dieser Stelle an den folgenden Foreneintrag: [Unterschied WinARM und Codesourcery]

Ich persönlich habe mich für Codesourcery entschieden, da Truestuido von Atollic ebenfalls den none-eabi Compiler verwendet und dadurch die Linkerscripts direkt von Truestudio übernommen werden können.

Installation der Code-Sourcery Umgebung

Wer sich nun für die Code-Sourcery Umgebung entschieden hat, steht nun schon vor einem kleinerem Problem - Welche Version von Code-Sourcery soll man wählen? Zur Auswahl stehen folgende Versionen:

 * uCLinux
 * EABI
 * GNU/Linux
 * SymbianOS

Hier ist die Wahl auf EABI beschränkt. Für weitere Hinweise siehe: [Codesourcery Getting-Started]

Die Installation von Code-Sourcery ist komplett Menü geführt und entsprechend intuitiv durchzuführen. Dabei werden nachfolgend die wichtigsten Komponenten kurz erläutert:

CodeSourcery Common Startup Code Sequence Diese vordefinierten Startup-Codes werden für den Start des Mikrocontrollers benutzt. Dabei wird der Stackpointer, die Interrupt-Handler usw. initialisiert. Die Benutzung dieser Startupcodes wird hier nicht näher Betrachtet, da STM vorgefertigte Startup-Codes kostenlos anbietet.

 * CodeSourcery Debug Sprite for ARM

Die Debug-Sprite Umgebung ermöglicht das Debuggen eines Mikrocontrollers über JTAG. Debug-Sprite kann dabei über XML-Dateien konfiguriert werden. Jedoch kann Debug-Sprite nicht für das Debuggen von STM32-Mikrocontrollern verwendet werden. GNU Binary Utilities (Binutils) Die Binutils beinhaltet den GNU-Assembler sowie den für das Übersetzen eines C-Software-Modules benötigen Linker.

 * GNU C Compiler (GCC)

Der GNU-C Compiler übersetzt den C-Code zu den sog. Object-Codes.

 * GNU C++ Compiler (G++)

Der G++ Compiler übersetzt ein C++-Software-Modul zu Object-Codes, um damit die Verwendung von C++ auf einem Mikrocontroller zu ermöglichen.

 * GNU C++ Runtime Library (Libstdc++)

Diese Library stellt C++ spezifische Funktionen zu Verfügung.

 * GNU Debugger (GDB)

Der Debugger ist der GDB-Client, der für das Debuggen eines Software-Moduls genutzt wird.

 * Newlib C Library

Die Newlib stellt die std-Lib für einen Mikrocontroller zu Verfügung. Dabei ist zu beachten, das die Newlib syscalls und stubs nutzt, um so eine Betriebssystemunabhängige Benutzung zu ermöglichen. Dies ermöglicht die Benutzung der Newlib auf einem Bare-Metal-System und auf einem uC-Linux basiertem Software-Modul.

Ich persönlich habe als Installationsverzeichnis C:\WinARM benutzt, damit die entsprechenden Pfade zu bestimmten binaris keine großartigen Sonderzeichen aufweisen.

Installation der Yagarto Umgebung

Die Installation sollte so ausgeführt werden, dass alles nach "C:\WinARM\" installiert wird, dazu müssen in den Setup-Paketen während des Setups immer die Pfade "C:\Programme\" angepasst werden. Damit kann man die gesamte Entwicklung und Konfiguration einfach sichern als ZIP Datei und sogar bei einem zweiten Rechner wieder einspielen.

Zu erst werden die Downloads von Yagarto geladen und installiert. Dort ist auch sehr gut beschrieben wie das Einrichten geht. Allerdings fehlt auf der Yagarto-Seite der Hinweis auf den Download-Link des eigentlichen Eclipse Programms, daher ist er oben im Artikel aufgeführt.

Wenn man diese Yagarto-Anleitung abgeschlossen hat kommt die Einrichtung von OpenOCD. Eine Debugger-Einrichtung ist bei Yagarto auch beschrieben, allerdings nicht für den STM32 Prozessor.

Nach der Installation von Yagarto-Tools muss eine Datei geändert werden: C:\WinARM\yagarto-tools\bin\make.exe muss nach gmake.exe umbenannt werden. Grund: Wenn man Delphi installiert hat, dann würde Eclipse das make Tool von Delphi finden und man kann das Eclipse Projekt nicht kompilieren. Das Demo-Projekt nutzt auch das "gmake.exe". Alternativ kann auch make.exe kopiert zu gmake.exe werden, wenn man kein Delphi installiert hat.

Start mit dem Demo-Projekt

Für alle Projekte habe ich das Verzeichnis C:\WinARM\Projekt\ vorgesehen, damit ist immer alles zusammen. Nun entpackt man das Demo-Projekt nach C:\WinARM\Projekt\ somit müsste dort ein neues Unterverzeichnis "Proj_Demo" vorhanden sein samt allen unterordnern.

Nun Eclipse Öffnen. Menü "File" >> "Switch Workspace" >> "Other...". In der Eingabezeile "Workspace:" wird nun das Verzeichnis "C:\WinARM\Projekt\Proj_Demo" eingegeben. Mit OK wird sich Eclipse beenden und neu starten.

Links im Baum sieht man das Projekt "BlinkLED":

  • inc: die eigenen Includes
  • lib: die FW-Lib von ST
  • out: die kompilierten Dateien und listings
  • prj: OpenOCD und LD Linker-Datei
  • src: die eigenen Quellcodes
  • makefile

Das Projekt wurde geschrieben für den STM32F103RC (256K Flash/48K RAM), läuft aber auch mit einem STM32F103xB da der Stack-Pointer auf 20K initialisiert wird. Details stehen in der Datei "src/stm32f10x_vector.c", Zeile 29,30:

#define STACK_TOP (0x20005000 - 4)
//#define STACK_TOP (0x2000C000 - 4)

Damit wird der Stack-Pointer für den RAM im Chip initialisiert.

Zum kompilieren rechten Mausklick auf das Projekt (normalerweise links im Navigator oder Projekt-Explorer) und dann im aufgehenden Kontextmenu auf "Build" klicken. Mit Strg+B wird nicht nur das Projekt neu kompiliert sondern ALLE Projekte im aktuellen Workspace gerade offen sind. Wenn man dort nur ein Projekt hat geht auch CTRL-B.

Die Funktionen des Demo-Projekts

  • Blink-LED auf Prot A.0, Port C.7, PortD.3,4,7,13 (STM3210C-EVAL Board)
  • Initialisieren aller Variablen
  • Initialisieren Clock auf HSI, 8MHz
  • Initialisieren IO-Pins der LED's
  • Initialisieren Timer für Systick
  • Main-Schleife in der die Timer-Variablen gesetzt und die LED's ausgegeben werden
  • Debug-Helper, siehe "src\DebugHelper.c"
  • Systick-Interrupt
  • komplett in C programmiert, kein Assembler
  • ST FW-Lib V3.4.0 wird für alle Funktionen genutzt

Erster Start mit dem Demo-Projekt

Mit Eclipse mit der grünen Play-Taste mit dem roten Koffer "Run OpenOCD BlinkLED" "OpenOCD BlinkLED starten. Damit wird der GDB Server OpenOCD mit dem JTAG-Key ARM-USB-OCD gestartet. Wenn man einen anderen JTAG Adapter hat, so kann der mit dem kleinen schwarzen Pfeil im Menü "External Tools Configuration..." eingestellt werden. OpenOCD wird mit Start-Parametern gestartet, z.B. "-f .\prj\arm-usb-ocd.cfg" für das Olimex JTAG Interface. Wenn man nun ein anderes JTAG Interface hat, so muss hier der Dateiname geändert und in das Projekt nach "prj\" muss die CFG-Datei einkopiert werden.

Mit Eclipse mit der grünen Käfertaste (Debug BlinkLED), der kleine Pfeil nach unten, "BlinkLED OpenOCD Reset Load Run" ausführen. Damit wird der GDB Debugger gestartet, das Projekt geladen und gestartet. Der Debugger beendet sich dann automatisch und die CPU läuft.

Weitere Plug-Ins für Eclipse

Damit das Arbeiten mit Eclipse einfacher wird, gibt es zahlreiche Plug-Ins. Diese können mittels Eclipse heruntergeladen werden und werden dann automatisch installiert.

Die in meinen Augen wichtigsten Plug-Ins sind folgende:

 * ARM-Plug-In
 * Register View
 * GDB-Plug-In

Das ARM-PlugIn stellt einen Wizzard bereit, in dem projektspezifische Einstellungen über den Compiler, Linkerscript usw. mit Hilfe einer GUI getroffen werden können.

Register View ermöglicht das Einsehen der General-Purpose Registern im Mikrocontroller. Dies kann beim Debuggen Hilfreich sein, da man anhand des Stack-Registers evtl. Stack-Overflows erkennen kann.

GDB-PlugIn mittels dem GDB-PlugIn ist es über Eclipse möglich, sich auf einen GDB-Server zu Connecten. Dabei kann dann aus Eclipse heraus direkt der Code-Debuggt werden.

Einrichten eines eigenen Projektes

Einrichtung GDB-Server

Ein GDB-Server wird immer unter "External Tools Configuration..." eingerichtet.

MenuExternalTool.png

Mit Hilfe dieser Funktion kann ein beliebiges Programm gestartet werden.

OpenOCD mit ARM-USB-OCD von Olimex

Der Aufruf, mit Parameter HW-Interface und Prozessor:

MenuExternalToolOOCD1.png

Der Eintrag im Eclipse-Menü:

MenuExternalToolOOCD2.png

Die restlichen Reiter sind ohne Änderung.

JLink mit Segger GDB-Server einrichten

Im Demo-Projekt ist eine Konfiguration für den Segger GDB-Server enthalten. Dabei wird der GDB-Server so gestartet dass SWD als Kommunikation genutzt wird.

Der Aufruf, mit Parameter für SWD (Single Wire Debug):

MenuExternalToolJLink.png

Der Pfad zum "JLinkGDBServer.exe" muss so angepasst werden je nach dem wohin er installiert wurde.

Einrichtung ST-Link (SWD Programmer vom Eval Board)

Einrichtung unter Windows

Einrichtung unter Linux

!!! Achtung !!! Das ST-Link projekt für Linux ist mit den neueren 3.0.X Kernel nicht mehr lauffähig und lässt den gesamten Rechner einfrieren !!! Sollte sich dort etwas ändern, so werde ich dies hier bekannt geben.

Vielfach wurde genannt, daß es schade sei, daß das Discoveryboard oder das STLink nur unter Windows benutzen zu können. Mittlerweile hat sich dieses geändert, ohne das, dass STLink mit einer neuen Firmware beschrieben werden muss. Es gibt eine kleine Gruppe, die einen STLink GDB-Server für Linux realisiert haben. Mittlerweile befindet sich dieses Projekt noch in der Beta-Phase, jedoch konnten die ersten Tests überzeugen.

Dazu muss der Sourcecode von der Seite [Projekt-Seite] mittels git gecloned werden. (GIT Link: https://github.com/whitequark/stlink.git) Damit ein Compilieren des Sourcecodes funktioniert, muss mittels apt-get oä. folgendes Paket installiert werden:

libsgutils2-dev

Nachdem dieses Paket installiert wurde, muss im Sourcecode noch einige Änderungen durchgeführt werden, da dort "unsauber" gecasted wurde. Dieses Bezieht sich auf die Datei: "stlink-hw.c" und dort in den Zeilen: 1420, 1491, 1514. Dort muss ein explizieter Cast zu (unsigned int) durchgeführt werden, so dass in der Zeile 1420 statt:

fprintf(stderr, "run_flash_loader(0x%x) == -1\n", addr + off);

nun

fprintf(stderr, "run_flash_loader(0x%x) == -1\n", addr + (unsigned int)off);
steht. Diese Änderung ist bei den beiden verbleibenden Zeilen durchzuführen.

Nachdem dies abgeschlossen wurde müssen die Sourcecodes mittels dem Befehl:

 make -C build 

compiliert werden. Der Start dieses GDB-Servers wird durch die Kommandozeile initiiert:

./build/st-util <<PORT>> /dev/sg<<SG-NUMBER>> 

Mittels des Attributes <<PORT>> wird die Port-Nummer des GDB-Servers angegeben. Die ST-Link "Geräte Datei" wird (zumindest bei mir) nicht immer an dem gleichen Pfaden angegeben.

Nach dem Start sollte folgende Meldung (beim Discoverboard) erscheinen:

*** stlink_open [/dev/sg4] ***
Chip ID is 10016420.
Device connected: Medium-density value line device
Device parameters: SRAM: 0x2000 bytes, Flash: up to 0x20000 bytes in pages of 0x400 bytes
Flash size is 128 KiB.
Listening at *:1234...

Nun ist der GDB-Server aktiv und kann mittels Eclipse genutzt werden. Für die Einrichtung von Eclipse siehe: Einrichtung unter Windows.

Tipps, Tricks und Stolpersteine

  • Die Dateiendung einer C/H Datei muss kleingeschrieben sein, denn sonst meint der GCC Compiler dass es C++ Dateien sind.
  • Wird VBox benutzt und einen Filter für den ST-Link bzw. des USB-Devices des Discovery-Boards eingerichtet, so kommt es zu schwerwiegenden Konflikten bei dem nächsten Start von VBox. Das Problem ist die Seriennummer vom ST-Link, welche nicht sichtbare Zeichen enthält. Ein Workaround zu diesem Problem: In dem eingerichtetem Filter muss die Seriennummer entfernt werden.

MicroXplorer - MCU graphical configuration tool

Der MicroXplorer von ST ist ein Eclipse Plugin (auch als standalone Version verfügbar) mit dem man sich die Peripheriefunktionen zusammen klicken kann die man beim STM32 Prozessor benötigt. Das Tool zeigt auch Kombinationen die nicht gehen. Somit kann man die Peripherie leichter planen.

Jedoch sollte man bei diesem Tool aufpassen: Wenn man z.B. zu erst CAN1 heraussucht und später FS_USB, so ist FS_USB nicht möglich. Wenn man das anders herum macht, so wird CAN1 auf alternative Pins gelegt und die Zuordnung klappt. Somit sollte man erst die Peripherie auswählen, die mit größerer Geschwindigkeit arbeitet, denn die hat meistens keine alternative Ports verfügbar und dann die mit langsameren Geschwindigkeiten, bzw. die von denen mehrere verfügbar sind. Beispiel: zu erst Ethernet oder SDIO, dann USB, dann CAN, dann UART.
Dennoch hilft es die Peripherie einfacher planen zu können.

Weblinks, Foren, Communities