STM32 Anleitungen

Hinweise zur System Workbench

Als Ergänzung zu meiner STM32 Anleitung gebe ich hier Tipps zum Umgang mit der System Worbench. Das ist eine Entwicklungsumgebung für STM32 Mikrocontroller.

Die System Workbench (kurz: SW4STM32) wurde von der französischen Beratungsfirma AC6 für die Durchführung von Schulungen gebaut. Nach einer schnellen Registrierung darf jeder die IDE kostenlos downloaden und ohne Einschränkungen benutzen. Die Firma verschont uns von unerwünschter Werbung.

Download: System Workbench for STM32

Gehe direkt nach der Installation der System Workbench ins Menü "Help/Check for Updates...", um Fehlerkorrekturen zu erhalten!

Unterschiede zu anderen IDE

Die drei Entwicklungsumgebungen System Workbench, Atollic TrueStudio und STM32 Cube IDE sind sehr ähnlich, weil sie alle auf Eclipse und dem gcc Compiler basieren. Ich habe hier aufgeschrieben, welche Unterschiede mir aufgefallen sind:
 System WorkbenchTrueStudio/CubeIDE
Projekt Assistentunterstützt Cube HAL, die alte SPL und Projekte ohne diese "Firmware".erzwingt Cube HAL.
Die IDE kann andere Projekte nur öffnen und bearbeiten.
Zustandstabile Arbeitsumgebung, wird ordentlich gepflegt wirdfunktioniert, wird aber ständig umgestaltet
DebuggerOpenOCDgdb
Trace Meldungen (ITM Messages)werden in eine Datei geschriebenwerden in der IDE als Text angezeigt
Tracing Funktionenneinja

Es gibt da noch ein GNU MCU Eclipse Plugin, das habe ich aber nicht ausprobiert.

Hinweise für Linux

Bei Linux werden die Pakete libc6:i386 und lib32ncurses5 benötigt, damit es sowohl 64bit als auch 32bit Programme ausführen kann. Außerdem kann es notwendig sein die Verwendung der alten GTK-2.0 Library anstelle von GTK-3.0 zu forcieren, damit Dialogfenster korrekt dargestellt werden. Man erreicht das durch folgenden Eintrag in der Datei ~/.profile:
export SWT_GTK3=0
Nach der Installation funktioniert der Eintrag im Startmenü möglicherweise nicht. Zum Start muss das Programm "eclipse" im Installationsverzeichnis ausgeführt werden.

Falls das Betriebssystem den Zugriff auf den ST-Link Adapter blockiert, muss man das mitgelieferte Script "install_stlink_udev.sh" ausführen.

Projekt erzeugen

Ich empfehle für den Anfang ohne Cube HAL (nur mit den CMSIS Headern) zu arbeiten. Dazu brauchst du einen der folgenden Downloads: So legst du ein CMSIS Projekt für einen STM32F3 an (bei den anderen Serien geht es ebenso):

Programm übertragen

Um das Programm mit einem ST-Link Adapter in den Mikrocontroller zu übertragen klickt man in der IDE mit der rechten Maustaste auf den Projektnamen, dann auf Target/Program Chip...

Bei Verbindungsproblemen kann es hilfreich sein, den Bootloader mittels Boot0=High und Reset zu aktivieren, da dieser die SWD Schnittstelle nicht deaktiviert.

Debuggen

Um den Debugger zu starten, klickt man auf den grünen Käfer. Dabei werden Änderungen am Programm automatisch auf den Mikrocontroller übertragen. Das Programm pausiert immer am Anfang der main() Funktion. Ich habe im folgenden Bildschirmfoto die Schaltflächen markiert, mit denen man es fortsetzt:

In dem blau schraffierten Bereich kann man Unterbrechungspunkte setzen, an denen die Ausführung pausieren soll. Wenn du mit der Maus auf eine Variable zeigst, wird ihr Inhalt angezeigt. Alternativ dazu kannst du das "Expressions" Fenster (View) benutzen.

In dem I/O Register View kann man sich beim Debuggen den Inhalt der I/O Register anschauen. Man muss das Fenster öffnen, bevor man den Debugger startet, sonst funktioniert es nicht.

Bei Verbindungsproblemen kann es hilfreich sein, den Bootloader mittels Boot0=High und Reset zu aktivieren, da dieser die SWD Schnittstelle nicht deaktiviert.

Unter Umständen erscheint im Console Fenster die folgende Meldung von OpenOCD:

Info: vid/pid are not identical <erwartete ID> <ID deines ST-Link>
Diese harmlose Information bedeutet, dass dein ST-Link Adapter nicht die erwartete Firmware-Version hat. Er funktioniert aber trotzdem. Wer die Meldung dennoch los werden will, sucht auf seiner Festplatte nach der Datei stlink.cfg. Im selben Verzeichnis befinden sich mehrere Versionen dieser Datei. Ersetze dort die erwartete ID durch die ID deines ST-Link Adapters.

Verbindungsoptionen

Die System Workbench unterstützt drei Optionen zum Verbindungsaufbau:

ModusBeschreibungEinschränkung
Hardware ResetDie Verbindung wird kurz nach dem Reset-Impuls geöffnet.Funktioniert nur mit verbundener NRST Leitung, aber das Programm darf nicht direkt beim Start die SWD Schnittstelle deaktivieren oder in den Schlafmodus gehen.
Connect Under ResetDie Verbindung wird während des Reset-Impulses geöffnet.Funktioniert immer. Wenn die NRST Leitung nicht mit dem Programmieradapter verbunden ist, muss man den Reset Knopf manuell gedrückt halten und in dem Moment loslassen, wo "in procedure reset" erscheint. Es ist schwierig, den richtigen Zeitpunkt zu treffen.
Software System ResetDie SWD Schnittstelle wird ohne Hardware-Reset geöffnet und dann ein Reset-Kommando abgesetzt.Funktioniert nicht, wenn das Programm die SWD Schnittstelle deaktiviert oder in einen Schlafmodus gegangen ist.

Die System Workbench benutzt beim Debuggen standardmäßig die Option "Hardware Reset". Diese Einstellung wird auch vom "Target/Program Chip..." Dialog benutzt.

Klicke mit der rechten Maustaste auf den kleinen Pfeil neben dem Käfer, dann auf "Debug Configurations...". Gehe in dem folgenden Dialog in den Debugger Tab und klicke dort auf den Knopf "Show generator options..." um die folgende Ansicht zu erhalten:

Trace Meldungen ausgeben

Alle ARM Controller ab Cortex M3 aufwärts können Trace Meldungen (ITM, Instrumentation Trace Messages) auf der SWO Leitung ausgeben. Die System Workbench kann diese Meldungen nicht direkt anzeigen aber in eine Datei schreiben.

Klicke mit der rechten Maustaste auf das den kleinen Pfeil neben dem Käfer, dann auf "Debug Configurations...". Gehe in dem folgenden Dialog in den Debugger Tab und stelle auf ein User defined configuration script um:

Nun öffne dieses "Configuration Script" im Texteditor und hänge ganz unten zwei Zeilen an:

tpiu config internal debug.txt uart off 8000000
itm port 0 on
Die Zahl 8000000 muss der CPU Taktfrequenz entsprechen.

Bei der nächsten debug Sitzung werden die Trace Meldungen dann in die Datei debug.txt (im Projekt-Verzeichnis) geschrieben. Zur fortlaufenden Anzeige benutze ich unter Windows den Befehl tail -f debug.txt in einem CygWin Fenster:

Die Datei enthält zwischen den Buchstaben nicht darstellbare Steuerzeichen. Falls tail diese unerwünscht anzeigt, kann man sie so heraus filtern: tail -f debug.txt | tr -dc '[:print:]\n'

Außerhalb einer Debugger-Sitzung kann man das ST-Link Utility zur Anzeige benutzen, und zwar über dem Menüpunkt ST-LINK/Printf via SWO Viewer. Stelle die richtige Taktfrequenz ein und klicke dann auf Start.

Man kann die Schnittstelle auch so konfigurieren, dass sie die Meldungen im gleichen Format ausgibt, wie ein normaler serieller Port:

monitor tpiu config external uart off 8000000 2000000
itm port 0 on
Die Zahl 8000000 muss der CPU Taktfrequenz entsprechen, die Zahl 2000000 ist die serielle Baudrate - maximal 1/4 des CPU Taktes. Nun kann man die Ausgabe mit einem gewöhnlichen USB-UART Adapter empfangen.

Falsche Taktfrequenz

Ich bin auf einen mutmaßlichen Bug gestoßen: Der Debugger ändert beim Verbindungsaufbau den Systemtakt auf 64 MHz, was er meiner Meinung nach nicht tun sollte. Meine Programme laufen danach teilweise viel zu schnell.

Mir ist es beim STM32F3 aufgefallen, offensichtlich sind jedoch auch die Serien F0, F4, F7 und H7 betroffen.

Die verantwortliche Datei für den STM32F3 ist SystemWorkbench/plugins/fr.ac6.mcu.debug_2.5.0.201904120827/resources/openocd/st_scripts/target/stm32f3x.cfg:

         
$_TARGETNAME configure -event reset-init {
global _CLOCK_FREQ

    # Configure PLL to boost clock to HSI x 8 (64 MHz)
    mww 0x40021004 0x00380400   ;# RCC_CFGR = PLLMUL[3:1] | PPRE1[2]
    mmw 0x40021000 0x01000000 0 ;# RCC_CR |= PLLON
    mww 0x40022000 0x00000012   ;# FLASH_ACR = PRFTBE | LATENCY[1]
    sleep 10                    ;# Wait for PLL to lock
    mmw 0x40021004 0x00000002 0 ;# RCC_CFGR |= SW[1]

    adapter_khz $_CLOCK_FREQ
}
Wenn man die markierten Zeilen auskommentiert, tritt das Problem nicht mehr auf. Man kann das aber auch durch Software auf dem Mikrocontroller lösen, indem man die PLL dort wieder deaktiviert und danach ggf. anders konfiguriert. Meine Programmierbeispiele zur Taktkonfiguration berücksichtigen das.