Den STM32dunio-Bootloader flashen, um den STM32 direkt per USB zu programmieren
Wäre es nicht schön, wenn man den STM32 so einfach programmieren könnte wie einen Arduino Nano? Ohne Serial Adapter und ST Link? Und wenn man ein Serial Interface über den USB-Anschluss hätte bei beim Arduino?Das ist möglich - mit dem STM32dunio-Bootloader. Der emuliert eine serielle Schnittstellen am USB-Port der STM32 " Blue Pill", über die auch Programme hochgeladen werden können. Dafür wird man allerdings ca. 21 KB Programmspeicher einbüßen - soviel Platz braucht der Bootloader.
Den Komfort, dass man auf den STM32 so einfach zugreifen kann wie auf einen Arduino Nano ist es aber wert.
Das richtige Bootloader-Image finden

Zuerst gilt es, das passende Bootloader-Image downzuloaden. Sich ein wenig in das Projekt "STM32duino-bootloader" einzulesen und die Readme.md zu lesen und sich zu orientieren, um was es genau geht, kann dabei sicher nicht schaden.
Wer sich nicht mit dem Sourcecode um dessen Kompilierung herrumschlagen will, der greift am besten gleich auf die binaries, die fertig kompilierte Bootloader-Firmware zu.
Hier ist die Frage, welche Version die richtige ist. Hierzu muss man einen näheren Blick auf das blaue Board werfen (daher auch " Blue Pill" oder "Blue Board"). Wichtig ist hier, was neben der internen LED (unter dem 32768 Hz-Quartz) steht. Bei mir ist es PC13 und damit ist folgende Version die richtige für mein Board: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/binaries/generic_boot20_pc13.bin
Das entsprechende Bin-File laden wir runter und speichern es lokal, z. B. in d:\STM32\bootloader, wie ich es getan habe.
Flashen des STMduino-Bootloaders mit einem Serial Adapter
Haben wir nur einen Serial Adapter für unseren STM32, so müssen wir uns den STMFlashLoader von https://www.st.com/en/development-tools/flasher-stm32.html downloaden, installieren und ausführen.Dann wie folgt vorgehen:
- Auf dem STM32-Board den Boot0-Jumper nach rechts setzen
- im Flash Loader der richtigen seriellen Port auswählen
- Flashen
- VOR einem Reset den Boot0-Jumper wieder nach links setzen oder abziehen





Flashen des STMduino-Bootloaders mit einem ST-Link Adapter

Haben wir hingegen einen ST Link oder einen Clone aus Fernost, wie rechts abgebildet (Vorsicht! Manchmal ist die eingelaserte Beschriftung falsch), dann geht das Flashen noch ein bisschen einfacher:
- Die Boot-Jumper bleiben während des gesamten Flash-Prozesses links.
- STM32 ST-Link Utitlity downloaden und installieren.
- Auf den "Binary File"-Tab neben "Device Memory" klicken und das generic_boot20_pc13.bin auswählen.
- STM32 mit dem ST Link verbinden (wie das geht steht hier)
- ST Link in USB Port einstecken einstecken
- Im Utility Target / Connect auswählen. Der Bereich "Device Memory" sollte sich jetzt füllen
- Im Utility Target / Program & Verifyy auswählen. Im nächsten Fenster "Start" anklicken. Der Flashing-Prozess wird durchgeführt.
- Wenn "Verification...OK" erscheint, ist alles glatt gelaufen. Dann Target / Disconnect auswählen und das Programm schließen.
- STM32 vom ST-Link abstecken



Vorteil des ST-Link-Flashens gegenüber der Serial-Adapter-Methode ist natürlich, dass man erstmal keine Header anlöten muss und den STM32 in ein - im Idealfall! - vorbereitetes Breadboard mit bereits angeschlossenem Serial-Adapter stecken muss.
Man steckt einfach den 4-poligen Stecker vom ST Link an den sowieso schon festgelöteten ST-Link-Header an und die Sache funktioniert. Ob man dann die Platine später auf einem Breadboard verwenden will (Header anlöten) oder für ein Projekt die Kabel für die Peripherie direkt ans Board löten will, kann man dann immer noch entscheiden.
STM ohne weiteres Zubehör am Windows-USB-Port
Wird der STM32 jetzt an einen USB-Port am Windows-PC angesteckt, erscheint nicht mehr "unbekanntes Gerät" sondern:
Es fehlen aber noch die Maple-Treiber, diese sind zu finden unter https://github.com/rogerclarkmelbourne/Arduino_STM32. Hier auf "Clone or Download" klicken und das Zip downloaden und entpacken.
In der entpackten Verzeichnisstruktur ist wininstall_drivers.bat zu suchen und als Administrator über rechtsklick auszuführen.
+---Arduino_STM32-master
¦ .gitignore
¦ .gitmodules
¦ LICENSE
¦ README.md
¦
+---drivers
¦ ¦ boards.txt
¦ ¦
¦ +---win
¦ ¦ wininstall_drivers.bat
¦ ¦ install_STM_COM_drivers.bat
¦ ¦ wdi-simple.exe
¦ ¦
¦ +---maple-dfu
¦ ¦ ¦ installer_x64.exe
¦ ¦ ¦ installer_x86.exe
¦ ¦ ¦ usb_device.inf
¦ ¦ ¦
¦ ¦ +---amd64
¦ ¦ ¦ install-filter.exe
¦ ¦ ¦ libusb0.dll
¦ ¦ ¦ libusb0.sys
¦ ¦ ¦ libusb0_x86.dll
¦ ¦ ¦ libusbK.dll
¦ ¦ ¦ libusbK.sys
¦ ¦ ¦ libusbK_x86.dll
¦ ¦ ¦ WdfCoInstaller01011.dll
¦ ¦ ¦ winusbcoinstaller2.dll
¦ ¦ ¦
¦ ¦ +---license
¦ ¦ ¦ +---libusb0
¦ ¦ ¦ installer_license.txt
¦ ¦ ¦
¦ ¦ +---x86
¦ ¦ install-filter.exe
¦ ¦ libusb0.dll
¦ ¦ libusb0.sys
¦ ¦ libusb0_x86.dll
¦ ¦ libusbK.dll
¦ ¦ libusbK.sys
¦ ¦ WdfCoInstaller01011.dll
¦ ¦ winusbcoinstaller2.dll
¦ ¦
Der STM32 muss zuerst vom USB Port abgezogen werden. Bei evtl. Nachfragen der Windows-Sicherheit "trotzdem installieren" anklicken.
Das Ganze sollte fehlerfrei durchlaufen und in etwa so aussehen:
Installing Maple DFU driver...
Extracting driver files...
Success
Installing driver(s)...
Success
Installing Maple Serial driver...
Extracting driver files...
Success
Installing driver(s)...
Success
Drücken Sie eine beliebige Taste . . .
Nun sind die Windows-Treiber installieren.
Programme hochladen so einfach wie mit dem Arduino
Nun geht es ans Hochladen eines Beispielprogrammes. Ich habe hier den Blink-Sketch um eine Ausgabe über die serielle Schnittstelle erweitert, um gleich alles in einem Schwung zu testen.In der Arduino-IDE muss man als Upload-Methode nun STM32duino-Bootloader auswählen. Dies funktioniert nur mit der Boardreihe Generic STM32F103C series, sonst ist hier keine Auswahl möglich. Außerdem als Port Port ... (Maple Mini) auswählen:
Dann sollte dann etwa so aussehen:

Nach dem Hochladen sollte das Programm automatisch starten, bei der Blink-Demo also die LED blinken. Auch Serial-Ausgaben sollten auf dem Serial-Monitor erscheinen.

Der Sketch verwendet 14484 Bytes (11%) des Programmspeicherplatzes. Das Maximum sind 131072 Bytes.
Globale Variablen verwenden 3088 Bytes (15%) des dynamischen Speichers, 17392 Bytes für lokale Variablen verbleiben. Das Maximum sind 20480 Bytes.
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=289
Starting download: [##################################################] finished!
error resetting after download: usb_reset: could not reset device, win error: Das System kann die angegebene Datei nicht finden.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Ich hatte allerdings das Phanömen, dass, wenn ich zu einem anderen STM32 gewechselt habe, diesen zweimal ein- und ausstecken musste, bevor der Upload klappte. Wenn es also nicht gleich beim ersten Mal klappt: nochmal probieren.Die Vorteile des STMduino32-Bootloaders liegen auf der Hand:
- der STM32 lässt sich jetzt so einfach wie ein Arduino Nano flashen
- kein Serial Adapter oder ST Link nach dem Bootloader-Flash mehr nötig
- der STM32 kann direkt aus der Arduino IDE am USB Kabel programmiert werden
- kein ständiges Umstecken des Boot0-Jumpers beim Programmieren mehr
- Serial-Ausgaben sind möglich (fehlten beim ST Link ja)
- der Bootloader verbraucht etwa 21 KB Programmspeicherplatz. Da aber eh 64 bzw. 128 KB vorhanden sind, sollte das verkraftbar sein.
- Es muss das Board "Generic STM32F103C series" gewählt werden. Damit fallen die HAL und LL-Libraries und darauf aufbauende Libs von STM weg, die nur auf der Boardreihe "Generic STM32F1 series" laufen. Hier ist der Bootloader nämlich nicht auswählbar.
Die Sache mit STM und wie sie Download und Upload interpretieren
Was ist ein Download? Und was ist ein Upload? Das kommt immer auf den Standpunkt der Betrachtung an.Nehmen wir ein ganz einfaches Beispiel aus der deutschen Sprache. Wenn Person A auf Person B zugeht, dann...
- sagt Person A: "ich gehe zu Person B hin"
- sagt Person B: "Person A kommt zu mir her"
Das Ausdrucksproblem ist schon steinalt. Schon in den 1980ern habe ich mich mit den Sysops und Usern von anderen Mailboxsystemen darüber diskutiert.
Wenn ein Benutzer Daten zur Mailbox überträgt, dann meinten:
- Sysops, also Mailboxbetreiber, dass sei ein Download, denn die Daten würden ja vom User zur Mailbox heruntergeladen (Bezugspunkt Mailbox)
- User, also Benutzer, dass sei ein Upload, denn die Daten würden ja zur Mailbox hinaufgeladen (Bezugspunkt User)
- ist eine Übertragung vom User zu einer Maschine ein Upload
- ist eine Übertragung von einer Maschine zum User ein Download
Die Arduino-IDE hat also ganz Recht, wenn sie davon spricht, Programme auf einen Mikrocontroller hochzuladen.
Das ST diese Terminolgie nun wieder gegen allgemeinen Gebrauch umdreht, indem sie davon spricht "eine Firmware auf einen STM downzuloaden" ist natürlich zuerst verwirrend. Wenn man das aber weiß, das hier ST sein eigenes Süppchen kocht, kann man damit klarkommen. Also nicht wundern, wenn ST von "Download" einer Datei spricht und dann nach einem File für den Upload fragt, statt den Firmware-Speicher downzuloaden und auf der Festplatte zu speichern.