Blue Pill in der Arduino-IDE
Die Blue Pill Platine soll nun einmal mit der Arduino-IDE programmiert
werden. Zur Vorbereitung muss man in Date/Voreinstellungen diese
zusätzliche Boardverwalter-URL eingeben:
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Damit erweitert man die unterstützen Systeme um solche mit
ST-Controllern. Unter Werkzeuge/Board/Boardverwalter wählt man dann die
STM Cores von STMicroelectronics und klickt auf Installieren. Die
Installation dauert einige Zeit, weil hier die komplette Toolchain zur
Übersetzung von STM32-Programmen installiert wird.
Als nächstes wählt man unter Werkzeuge/Board aus der Gruppe STMF1
Boards die Generic STM32F103C series aus. Unter dem Board erscheint
dann eine Auswahl für einen Typ mit 64k Flash (das ist der richtige)
oder mit 128k Flash.
Ganz entscheidend ist noch die Upload method. Da werden zwar viele
Möglichkeiten geboten, aber zur Hardware passt erstmal nur STLink. Erst
später hat man dann auch den Bootloader und kann ohne den ST-Link
direkt über die USB-Buchse die Programme laden.
Nun muss man ein erstes Beispiel laden. Unter
Beispiele/A_STM32_Examples/Digital/Blink findet man das passende
Blinker-Programm.
Das erste Kompilieren dauert verdächtig lange, weil hier
gleichzeitig auch der Arduino-Bootloader vorbereitet wird. Wenn ST-Link
und BluePill angeschlossen waren, sieht man den Erfolg, die grüne LED
blinkt. Ich kann es immer erst gar nicht glauben und mache eine
willkürliche Änderung im Programm. Wenn ich die erste Wartezeit um eine
Null auf 100 ms verkürze zeigt der neue Test ein verändertes Blinken.
Die LED ist immer lange an und kurz aus. Es blinkt also anders als man
erwarten würde. Der Grund ist, dass die LED nicht gegen GND sondern
gegen VCC angeschlossen ist.
Jetzt sollte also der Bootloader vorhanden sein. Ich trenne das System
vom ST-Link-Flachbandkabel und stecke den USB-Stecker ein. Windows
lässt sein USB-Dingeldong erklingen und zeigt keine Fehlermeldung. Das
ist schon mal gut. Außerdem blinkt die LED jetzt weiter, das System hat
also Versorgungsspannung. Und der Windows Geräte-Manager zeigt ein
neues Gerät an, ein Serielles USB-Gerät, in diesem Fall an COM9. Das
muss er sein. Das Blinkprogramm enthielt also tatsächlich den
Bootloader. Oder doch nicht?
Das
will getestet werden! Als Upload-Methode stelle ich jetzt Serial ein.
und ich darf natürlich nicht vergessen, die COM9 einzustellen. Das
Board läuft jetzt unter COM9 (Maple Mini), aber das soll mich nicht
stören. Nach einer weiteren kleinen Änderung im Programm (zweimal 100
ms) wird es neu übersetzt und hochgeladen.
Das Ergebnis: NICHTS! Mit Serial geht es nicht, mit den anderen
Downlaod-Methoden auch nicht. Nur mit dem ST-Link kann ich weiterhin
wie gewohnt arbeiten.
Der STM32duino-bootloader
Ein zweiter Versuch mit einem andern Bootloader war erfolgreicher. Der
STM32duino-bootloader von Roger Clark funktioniert wie gewünscht.
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/binaries/generic_boot20_pc13.bin
Aswinth Raj hat die Sache hier beschrieben: https://circuitdigest.com/microcontroller-projects/programming-stm32f103c8-board-using-usb-port
. Er verwendet eine andere Upload-Methode. Ich konnte dagegen das
Bin-File direkt mit dem ST-Link laden.
Die richtige Upload-Methode ist
dann der STM32duino bootloader.
Die Upload-Erfolgsmeldung bestätigt es. Und das geladene Blinkprogramm
funktioniert wie gewünscht. Programmänderungen kann man nun schnell und
bequem ausprobieren.
Einen Haken hat die Sache aber doch. Der Zugang über ST-Link
wurde abgeschaltet. Ich kann also nicht mehr zwischen den
Upload-methoden hin- und herwechseln. Leander hat mich schon darauf
vorbereitet, dass sowas passieren kann. Da gibt es in Bit in den
Options, das den Debug-Zugang freigibt. Wenn das abgeschaltet wurde,
ist erstmal der Weg zum ST-Link abgeschnitten. Na gut, eine von meinen
drei Blue Pills ist dann eben nur noch für Arduino zuständig.
Es gibt aber auch einen Ausweg aus der Falle, den ich zum Glück auch
schon von Leander erfahren habe: Man muss den gelben BOOT0-Kumoer auf 1
setzen. Dann bekommt auch ST-Link wieder den Zugang. Ich kann den
ganzen Chip löschen und danach den Jumper wieder zurück auf 0 stechen.
Back to Normal, ab jetzt führt wieder der ST-Link das Regiment.