STM32 Programmierung

Wären ARM Mikrocontroller schon vor Jahren so populär und billig wie heute gewesen, dann wäre ich wohl direkt vom 68HC11 auf ARM umgestiegen und hätte den AVR übersprungen.
Obwohl ich - vom 68000er her kommend - auch den 68HC11 schon einen ziemlichen Krampf fand...

Einrichten einer Programmierungumgebung / Toolchain

Unter Artix Linux installiert man sich einfach die vier Pakete

als dem "extra" Repo von Arch Linux und hat dann eine Toolchain, die stets auf dem neuesten Stand ist. Zum flashen und debuggen braucht man noch entweder stlink oder openocd

st-link als Arch Linux Paket
openocd aus dem AUR

Und zu guter Letzt braucht man noch die CMSIS Header für den jeweiligen Controller. Diese findet man auf der Webseite von ST, zum Beispiel für die STM32F0 Familie heisst die Datei STM32CubeF0 (da ist auch die HAL library enthalten, wer die benutzen möchte...)

Inzwischen hat STM die Dateien auch auf GitHub, z.B. für die STM32G0 Familie unter https://github.com/STMicroelectronics/STM32CubeG0/. Dort dann das Unterverzeichnis Drivers/CMSIS wählen.

Für Artix Linux habe ich mir hier PKGBUILDs für Pakete der CMSIS Header gebaut.

Flashen/Debuggen mit st-util

Damit auch nicht-root user Zugriff auf den stlink erhalten, legt man eine udev Regel an:

/etc/udev/rules.d/99-stlink-v2.rules

# stm32 discovery boards with onboard stlink v2
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", \
	GROUP:="devel", MODE:="0660", SYMLINK+="stlinkv2_%n"

$ st-util 2014-04-24T09:17:02 INFO src/stlink-usb.c: -- exit_dfu_mode 2014-04-24T09:17:02 INFO src/stlink-common.c: Loading device parameters.... 2014-04-24T09:17:02 INFO src/stlink-common.c: Device connected is: F0 device, id 0x20006440 2014-04-24T09:17:02 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes Chip ID is 00000440, Core ID is 0bb11477. Target voltage is 2899 mV. Listening at *:4242...

$ arm-none-eabi-gdb main.elf (gdb) target extended-remote :4242 (gdb) load

Flashen und Debuggen mit openocd

$ openocd -f board/stm32f0discovery.cfg ...some output...

$ arm-none-eabi-gdb main.elf (gdb) target extended-remote :3333 (gdb) monitor reset halt (gdb) load (gdb) continue

Flashen und Debuggen mit Black Magic

Ich habe meinen beiden STLink-v2 Clones mit der Blackmagic Firmware geflasht. Damit kann man mit dem gdb diese direkt ansteuern und der Zwischenschritt über st-util oder openocd entfällt :-)

$ arm-none-eabi-gdb main.elf (gdb) target extended-remote /dev/ttyBmpGdb (oder kurz tar ext /dev/ttyBmpGdb) (gdb) monitor auto_scan (oder kurz mon a) (gdb) att 1 (gdb) load (gdb) compare-sections (gdb) start

Leider müssen die STLinks nach jedem Einstecken mittels stlink-tool auf den Blackmagic "umgeschaltet" werden. Gemäss Anleitung scheint das halt so zu sein (ist also erwartet). Am besten man macht das mit einer udev-regel.

Mehr Infos hier blackmagic

Belegung des SWD connectors auf dem ST-Link

Pin	Signal	Bemerkung
1	Vdd Target	Target Board könnte damit ST-Link speisen - nicht benötigt
2	SW_CLK	SWD CLK, muss bei F030 an PA14
3	GND
4	SW_DATA	SDW DATA, muss bei F030 an PA13
5	nRST	RESET für Target MCU
6	SWO	Serial Wire Output vom Target, unterstützen aber nicht alle

Verschiedene STM32 Derivate

STM32F030F4P - auf meinem Breakoutboard mit der minimal erforderlichen Beschaltung
STM32F051 - auf dem STM32F0 Discovery board
STM32F407 - auf dem STM32F4 Discovery board
STM32L053R8T6 - auf dem Nucleo-64 Board (diese MCU kann USB...)
STM32G071

Mein experimenteller STM32 Family Selector Guide (ziemlich under Construction ;-)

Code Schnipsel in C für alle STM32

Software SPI