Mein Blog    Projekte    Archiv    Impressum

Mein Eclipse

21. 10. 2020

An dieser Stelle möchte ich einfach mal meine persönliche Toolchain Konfiguration (nicht nur den Eclipse Anteil) dokumentieren.

Basisversion

Eclipse kann auf der Eclipse Packages Seite in verschiedenen Grundausstattungen heruntergeladen werden. Ich wähle hier immer die C/C++ Version, da Mikrocontroller - von Ausnahmen abgesehen - in C oder C++ und nicht in Java programmiert werden.

SW4STM32 (früher)

Für STM32 Mikrocontroller eignet sich wunderbar das OpenSTM32 Plugin von ac6 welches auf openstm32.org verbreitet wird.

Leider hat man dort ein etwas merkwürdiges Verständnis des Begriffes “open”. Um an die Installlationsanweisungen zu kommen muss man sich zuerst registrieren und anmelden.

Das ist aber kein großes Problem, denn eigentlich braucht man nur die URL der Eclipse Download Site.

http://ac6-tools.com/Eclipse-updates/org.openstm32.system-workbench.update-site-v2

Über diese Download Site werden dann automatisch einige mehr oder weniger (meiner Erfahrung nach eher weniger) frische Binaries heruntergeladen, die es erlauben geeignete (im CubeMX als SW4STM32 Projekt exportierte) Projekte zu kompilieren und über einen ST-Link debugger zu debuggen.

Mit dem Umstieg auf einen neueren Laptop funktionierte dann aber das flashen und debuggen nicht mehr. Nach langer Fehlersuche und Recherche lernte ich dass es daran lag, das mein neuer Laptop nur USB3 Ports besitzt, aber die OpenSTM32 Umgebung eine OpenOCD (Debugger Software) Version liefert die nur an USB2 Ports funktioniert. Das ganze ließ sich sogar insofern überprüfen, als dass das Debugging wieder funktionierte, als ich den Debugger testweise über einen USB2-Hub an den Laptop angeschlossen habe.

Damit war mir die ganze OpenSTM32 Umgebung dann aber endgültig zu nervig, sodass ich mich etwas tiefer eingearbeitet habe, in mögliche Toolchains zum programmieren von STM32 Mikrocontrollern.

STM32 (aktuell)

Statt der fertigen SW4STM32 Umgebung verwende ich jetzt eine selbst zusammen gestellte Toolchain.

Bibliotheken

Momentan verwende ich noch die proprietären von ST bereitgestellten Bibliotheken welche eine sehr gute Hardwareabstraktion bieten und mit dem STM32CubeMX über einen wunderbaren Codegenerator verfügen.

In Zukunft werde ich aber auch mal noch die LibOpenCM3 anschauen um in der Lage zu sein die Controller mit freier Software zu bespielen. (Abgesehen davon ist die Software auch hilfreich wenn es darum geht, für eine bestimmte aufgabe den besten Chip zu finden, allerdings natürlich nur innerhalb des ST Portfolios.)

Compiler und Binutils

Die SW4STM32 Suite wurde mit vorkompilierten Compiler und Binutils (ld, objdump, etc.) fragwürdigen Alters ausgeliefert. Über den Paketmanager meiner Linux Distribution lassen sich aber auch frische Versionen davon über die Pakete

  • gcc-arm-none-eabi
  • binutils-arm-none-eabi
  • gdb-multiarch

installieren und automatisch auf aktuellem Stand halten. Dazu kommt dann noch ganz klassisch make um den Buildprozess zu automatisieren.

Debugger-Hardware

Dann muss die Software irgendwie auf den Chip kommen. Ich kenne dazu drei Methoden. Zunächst verfügen die STM32 Chips über Bootloader, so dass wenn die Boot pins richtig verbunden werden der Controller über die serielle Schnittstelle programmiert werden kann. Mehr dazu hier bei ST. Auch für Linux Systeme gibt es dafür geeignete Software.

Besser als der reine Flasher ist ein Debugger, mit dem sich das Programm während der Laufzeit anhalten lässt und der Speicher und CPU Register inspiziert werden können. Zunächst bietet sich dafür der ST-Link Debugger an, welcher bei allem STM Nucleo Boards schon mit dabei ist. Separat kann er im Original (dickes weißes Plastikgehäuse mit blauer Schrift) für ca. 20€ gekauft werden oder als China Clon (kleine, bunte USB-Sticks) für 2-3€. Zum Debuggen wird unter Linux die OpenOCD Software eingesetzt.

Ich verwende inzwischen die Black Magic Probe (BMP). Fertige Hardware ist mit ca. 65€ zwar etwas teurer als der ST-Link, dafür lassen sich aber nicht nur Chips von ST sondern auch Atmel, Nordic, NXP, TI, freescale, Silicon Labs, Xilinx und Broadcom damit debuggen. Außerdem handelt es sich um Open Source Software / Open Hardware, sodass nicht zwingend die offizielle Hardware nötig ist. Ich verwende stattdessen ein Bluepill Board für 2-3€ auf dem die BMP Software läuft.

Gegenüber dem Computer sieht die BMP aus, wie eine serielle Schnittstelle, über die ein gdb Server angeschlossen ist. Entsprechend einfach lässt sich die BMP dann auch als Debugger in Entwicklungsumgebungen einbinden.

Konfiguration von Eclipse

Ausgehend von der Basisintstallation von Eclipse mit CDT (der C++ Umgebung) sind ein paar Handgriffe nötig, um die oben genannten Komponenten gemeinsam zu verwenden. Für ein Projekt ergibt sich jeweils der folgende Ablauf:

1. Projekt anlegen

In CubeMX wird der Mikrocontroller ausgewählt und je nach bedarf Konfiguriert. Anschließend wird die Konfiguration als Makefile Project in den Eclipse Workspace exportiert.

Bei der Konfiguration in CubeMX sind folgende Dinge zu beachten:

  • Serial Wire Debug aktivieren, sonst kann nur mit dem Boot 0 Jumper und in der Sekunde nach Power On geflashed und debuggt werden. Wird SWD aktiviert ist dies jederzeit möglich.
  • Beim Exportieren/Code generieren “Makefile” als “Toolchain/IDE” auswählen.
  • Als Pfad für den Export den Eclipse Workspace wählen.
  • Es gibt ein CubeMX Eclipse Plugin. Dieses funktioniert unter Linux jedoch nicht. Die Standalone Applikation funktioniert.
  • Die Standalone Applikation funktioniert mit kleinen Einschränkungen:

2. Projekt in Eclipse importieren

In Eclipse über “File”->”New”->”Makefile Project with Existing Code” den Import Dialog öffnen. Dor über den “Browse” Knopf den Pfad zu dem von CubeMX generierten Ordner eintragen. Der Projektname wird automatisch erkannt. Als Toolchain “Cross GCC” auswählen und auf “Finish” klicken.

Das Projekt lässt sich bereits (auch wenn noch kein eigener Code geschrieben wurde) über einen Rechtsklick und “Build Project” bzw. über den “Hammer”-Knopf kompilieren.

3. Syntax Highlighter anpassen

Direkt nach dem Import werden große Teile des von CubeMX generierten Codes durch den Syntax Highlighter als fehlerhaft markiert. Das liegt daran das Teile des Codes über Präprozessor Makros aktiviert werden die erst über -D Parameter während des Build Prozesses aktiviert werden.

In den Projekteigenschaften findet man unter “C/C++ General” und dem Unterpunkt “Preprocessor Include Paths, Macros etc.” den Tab “Providers”. Bei den Verschiedenen Quellen für Präprozessorsymbole sollte hier auch der “CDT GCC Build Output Parser” ausgewählt werden. Dabei handelt es sich um ein Tool welches die Ausgaben des Buildprozesses nach Präprozessorsymbolen durchsucht. Klickt man diesen Provider an erscheinen unter der Liste einige Optionen zur Konfiguration, darunter auch ein Feld “Compiler command pattern”. Hier wird konfiguriert woran der Build Output Parser einen Compileraufruf erkennt. Wenn man ganz zu Anfang der Zeile

(arm-none-eabi-gcc)|

einfügt, wird das für ARM Mikrocontroller notwendige Pattern ergänzt. Anschließend muss man einmal das Projekt neu bauen, und dann sollte das Syntax Highlighting korrekt funktionieren.

4. Debugger konfigurieren

Als letztes muss noch der Debugger konfiguriert werden, um die Projekte auch auf den Mikrocontroller übertragen und bequem (d.h. mit Breakpoints im Code Editor, Beobachtung von Variablenwerten etc.) debuggen zu können.

Hierzu macht man einen Rechtsklick auf das Projekt, wählt “Debug As” und dann “Debug Configurations…” um zu den Debugger Einstellungen zu kommen. Dort wählt man “GDB Hardware Debugging”. Im Tab “Main” sollte bereits alles automatisch richtig eingestellt sein. Im Tab “Debugger” muss man das “GDB Command” in “gdb-multiarch” ändern und “Use remote target” deaktivieren. Im Tab “Startup” muss man in das Feld “Initialization Commands”

set mem inaccessible-by-default off
target extended-remote /dev/ttyACM0
monitor swdp_scan
attach 1

und bei “Run Commands”

start

eintragen. Mit “Apply” und “Close” speichert man die Konfiguration schließlich ab.

Bei der Suche nach dieser funktionierenden Konfiguration war diese Seite eine große Hilfe.

STM32CubeMX

Um sinnvolle Programme für einen STM32 Controller zu schreiben ist einiges an Konfiguration nötig. Man kann sich natürlich alle Registeradressen aus den Datenblättern holen und die Flags von Hand setzen, es geht aber deutlich komfortabler. Mit der CubeMX Software (kostenlos, aber nicht Open Source) bietet ST ein großartiges Tool um die Pinbelegeungen, Interrupts, Clocks, etc. grafisch zu konfigurieren. Die Konfiguration kann dann als OpenSTM32 kompatibles Eclipse Projekt exportiert werden.

Das ganze ist entweder als eigenständiges Programm oder auch als Eclipse Erweiterung verfügbar. Diese allerdings nicht als Software Site sondern als Zip-Datei (beim konfigurieren der Software Sites in Eclipse auf “Archive” drücken). Diese kann direkt bei ST heruntergeladen werden. Unter Linux funktioniert dieses Eclipse Plugin leider nicht und stürzt immer wieder ab. Die Standalone Variante funktioniert jedoch gut.

Wenn man OpenJDK14 verwendet (z.B. auf aktuellen Ubuntu Systemen der Standard) wird beim erstellen von SW4STM32 Projekten kein Linkerfile (.ld) generiert. Bei Makefile Projekten tritt dies zwar nicht auf, womöglich gibt es aber noch weitere, nicht offensichtliche Bugs. Mit OpenJDK8 oder OpenJDK11 tritt der Fehler nicht auf. Der Fehler ist bei ST bekannt.

ST-Link Adapter / Black Magic Probe unter Linux

Damit ein ST-Link Adapter bzw. eine Black Magic Probe unter Linux ohne weiteres (und vor allem ohne Root-Rechte) mit der IDE funktioniert, muss noch eine udev Regel angelegt werden. Dazu unter

/etc/udev/rules.d/

die folgende Regel hinzufügen:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374a", \
    MODE:="0666", \
    SYMLINK+="stlinkv2-1_%n"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
    MODE:="0666", \
    SYMLINK+="stlinkv2-1_%n"

Anschließend kann mit

udevadm control --reload-rules && udevadm trigger

die Regel ohne Neustart aktiviert werden.

ST-Link ohne Eclipse / Gui

Da ich die Black Magic Probe verwende ist das eigentlich nicht von Bedeutung, aber so habe ich ursprünglich die BMP Software auf eines der Bluepill Boards installiert.

Zunächst das Flashingtool installieren:

apt install stlink-tools

Flash schreiben:

st-flash --flash=64k write programm.bin 0x8000000

Flash auslesen:

st-flash --flash=64k read out.bin 0x8000000 0x10000

EGit

Zur Versionsverwaltung von Quellcode verwende ich Git. Dafür gibt es ein Eclipse Plugin namens “EGit”. Die Software Site dazu lautet:

https://download.eclipse.org/egit/updates