Blue Pill in der Arduino-IDE         


Elektronik-Labor  Projekte   


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.




Elektronik-Labor  Projekte