Weil ich gerne mit so wenigen Kabeln wie möglich hantiere, habe ich
bisweilen auch gegen Bootloader bei MCU's nichts.
Bei den STM32 sind serielle Bootloader integriert, für die AVR's gibts
Unmengen nur für den STM8S103F3P6 (der ultrabillige Chip den es auch auf
einem minimalistischen Board fast ohne alles dafür für 65 Cent gibt)
gibt es keinen Bootloader (und er ist auch einer der wenigen Vertreter
der STM8 Familie die keinen Bootloader integriert hat).
Also habe ich einen selbst geschrieben (und mich dadurch etwas tiefer
mit der Maschinensprache und dem Chip selbst auseinandersetzen müssen).
Der Assemblercode ist sicher verbesserungsfähig, aber er tut (nur leider
nicht so schnell wie ich es gerne hätte, was jedoch zum großen Teil der
Programmierzeit geschuldet ist, wenn der STM8 sich selbst flasht).
Der Bootloader ist mit "naken_asm" geschrieben, von dem ich zuvor noch
nie etwas gehört habe. Sehr minimalistisch (u.a. keinen Linker), aber
für das was ich vorhatte ziemlich richtig.
http://www.mikekohn.net/micro/naken_asm.php
Das Hostprogramm, das den STM8 mit dem Hexfile füttert ist mit
FreePascal geschrieben (hey, ich hatte dafür schon die Auswertung des
Intel-Hex Files in der Schublade und wollte das nicht neu machen).
Außerdem funktioniert es. FreePascal findet man hier:
http://www.freepascal.org/download.var
Das im Zip-Paket enthaltene stm8_bootflash ist für Linux 32-Bit
geschrieben, wer es für ein 64 Bit System benötigt muß es sich selbst
übersetzen.
Leider gilt auch für meinen STM8 - Bootloader das "Henne-Ei Problem",
man braucht einen Programmer um einen Programmer oder einen Bootloader
zu flashen.
Der STM8 Bootloader konnte unkompliziert mit STM8FLASH und einem
China-Clone ST-Link v2 geflasht werden. STM8FLASH gibts hier:
https://github.com/vdudouyt/stm8flash
Auf einem der Bilder sieht man, wie ein einzelner STM8 Chip mit dem
ST-Link v2 verbunden werden muß. Der Bootloader wird mittels:
stm8flash -c stlinkv2 -p stm8s103f3 -w bootloader.ihx
in den Chip geflasht.
Fortan steht der Bootloader zur Verfügung und kann mittels serieller
Schnittstelle geflasht werden.
Wird die DTR-Leitung einer seriellen Schnittstelle über einen
Kondensator mit dem Resetanschluss des STM8 verbunden, so gelangt der
STM8 automatisch in den Programmiermodus.
Werden nur RxD und TxD verbunden, so muß kurz nach dem
Flashprogrammaufruf am STM8 ein Reset durchgeführt werden.
Prinzipiell ist der Bootloader sehr "Arduino-Style", da der Bootloader
eine gewisse Zeit nach einem Reset wartet und testet, ob ein Zeichen
(hier "u") eingegangen ist oder nicht.
Ist ein Zeichen eingegangen wird der Flashmodus aktiv, wenn nicht, wird
das im STM8 enthaltene Userprogramm ausgeführt.
Gebrauch des Flashprogramms:
stm8_bootflash Schnittstelle Hex-File [optional: notxbar]
Beispiel:
stm8_bootflash /dev/ttyUSB0 blinky.ihx
Wird der Bootloader von einer IDE aufgerufen, so kann es sinnig sein,
diesen ohne den Konsolenfortschrittbalken zu starten (bessere Ausgabe in
einer IDE):
stm8_bootflash /dev/ttyUSB blinky.ihx notxbar
Viel Spaß damit (wers brauchen kann),
Ralph
PS: der Schaltplan zeigt, wie man den STM8 an einen (ultrabilligen
China-Chip) anbinden kann. Vllt. mache ich mal ein EVAL-Board im Stile
eines Arduino Nano daraus.
... was ich vergessen hatte:
Natürlich belegt der Bootloader User-Speichercode im Flash (jedoch recht
wenig).
Für ein Programm stehen von den insgesamt 8192 Bytes die der STM8
bietet, einem Anwenderprogramm 7744 Bytes zur Verfügung.
Die Differenz zu den 8192 Bytes (448 Bytes) benötigt der Bootloader
selbst.
Programm die mit SDCC für STM8 geschrieben sind funktionieren tadellos
und "natürlich" wird Code ab der Speicheradresse $8000 korrekt abgelegt.
Der Reset-Vektor an $8000 wird auf das Ende des Flash Speichers
"verbogen".
A day later .... schon das erste "Update"
Ich hab mich schwer über die Flashdauer des Bootloaders geärgert und mir
das "genauer" angesehen gehabt:
Leider hatte die erste Version KEINEN Block Save im Flashspeicher
vorgenommen gehabt.
Nachdem die Anweisung zum blockweisen schreiben korrekt war stellte ich
fest:
Ein blockweises Schreiben im Flashspeicher geht nur dann, wenn das
Kopieren in den Flashspeicher von einer Programmroutine aus erfolgt, die
zwingenderweise im RAM liegt !
wurgs dachte ich, hilft aber nichts. Also hab ich eine kleine
Speicherkopierfunktion geschrieben und kopiere den Teil, der das
Blockspeichern vornimmt ins RAM und starte dort die Kopierfunktion.
Hat super geklappt, der Bootloader "rast" jetzt im Vergleich zu vorher.
Ein Upload von 6596 Bytes erfolgt in 3,2 Sekunden.
Die maximale Speichergröße des Userprogramms beträgt nach wie vor 7744
Bytes (der Bootloader belegt somit 448 Bytes !!!)
... wie die Zeit doch vergeht: Ich dachte nicht, dass ich den Bootloader
schon vor 2 Jahren geschrieben hatte.
Jetzt gibts das nächste "Update" und leider wurde beim Upload-Tool ein
weiterer Optionsparameter notwendig und von daher müssen dann bestehende
Makefiles angepasst werden.
Seit längerer Zeit habe ich ich auch ein
STM8S105K4
Board herumliegen, das ich jedoch nie verwendet oder in Benutzung
hatte... bis auf jetzt eben.
Also wollte ich den Bootloader auch für den 105er haben. Wie das so ist,
dauert etwas, von dem man dachte dass es kurz ist dann doch länger. Ich
hab für die Modifikationen 2 Abende gebraucht, aber jetzt klappts.
Der Bootloader funktioniert mit den auf Ebay erhältlichen billigsten
Experimentierboards (allerdings haben sich die Preise für die Boards
seit 2 Jahren verdoppelt und die für die Chips verdreifacht... aber
immer noch billig).
https://www.ebay.de/itm/ARM-STM8S103F3P6-STM8-Minimum-System-Development-Board-Module-For-Arduino/132486311875?hash=item1ed8ccafc3:g:YyQAAOSwjRtbNEld:rk:2:pf:0https://www.ebay.de/itm/STM8S-STM8S105K4T6-Development-Board-Module-MCU-Learning-Core-Board-Small-System/263351137116?hash=item3d50f3735c:g:vqAAAOSwySlaHmbR:rk:2:pf:0
Somit sind nun zwei getrennte Bootloader verfügbar (eben einer für
STM8F003 / STM8F103 und einer für STM8F105).
Leider stellt man fest, dass die 103er sogenannte Low density Bausteine
sind und ihren inneren Flash in Pages zu je 64 Bytes zusammenfasst, die
105er Bausteine sind Medium density Bausteine und die werden mit 128
Bytes per Page zusammen gefasst. Das machte erforderlich, dass dem
Upload-Tool gesagt werden muss, für welchen Baustein etwas hochgeladen
werden soll.
Ein Aufruf des Tools erfolgt nun so:
1
Syntax:
2
stm8_bootflashv2 device port filename [notxbar]
3
4
device : MCU - device
5
port : port were the adapter is connected
6
filename : file to be uploaded
7
notxbar : optional, no bar graph is shown
8
(use it by call from an IDE)
9
10
Example : stm8_bootflashv2 stm8s103f3 /dev/ttyUSB0 helloworld.ihx
--------------------------------------------------
Das Makefile im ZIP-Ordner wertet die Optionen:
all, host, f103, f105, host, flash103, flash105, clean
Zum Übersetzen wird für das Uploadprogramm ein installierter FreePascal
Compiler, für die Bootloader ein installierter Naken-Assembler
vorrausgesetzt.
http://www.mikekohn.net/micro/naken_asm.php
Die Optionen im einzelnen sind:
all:
erstellt die beiden Bootloader-Hexdateien
host:
erstellt das Uploadprogramm (ein installierter FreePascal Compiler wird
vorrausgesetzt)
f103:
erstellt nur den Bootloader für STM8S103F
f105:
erstellt nur den Bootloader für STM8S105K4
flash103:
flasht den Bootloader in den STM8S103, ein angeschlossener ST-Link wird
vorrausgesetzt
flash105:
dto. für STM8S105
clean:
räumt auf
Für diejenigen die sich den Pascal Compiler extra installieren wollen
ist das Binarie des Uploadtools in den Ordnern bin32 und bin64 enthalten
(zu verwenden je nachdem ob ein 32 oder 64 Bit Linux verwendet wird).
Die Ordner bin und ihx enthalten nach einem Makeaufruf die aktuell
compilierten Dateien.
------------------------------------------------------------
Die Bootloader sind verwendbar mit Programmen, die mittels SDCC
übersetzt wurden.
Prinzipiell ist gültig, dass die ersten 4 Bytes eines Programms einen
Sprungbefehl zu einem Hauptprogramm enthalten oder den von SDCC
erstellten Code enthält:
Der Bootloader kopiert die ersten 4 Bytes eines Userprogramms an das
Flashende des Controllers und ersetzt die ersten 4 Bytes durch einen
Sprungbefehl auf den Bootloadercode. Nach einem Reset wird in den
Bootloader gesprungen und erfolgt innerhalb einer bestimmten Zeit keine
Uploadanforderung wird das im Flash gespeicherte Userprogramm gestartet.
Nein, du mußt nichts verbiegen. Wie der Auszug oben zeigt wird der Code
an genau der Stelle abgelegt für den der Compiler es erzeugt hat.
Lediglich die ersten 4 Bytes sind an einer anderen Stelle (Reset).
Das heißt du kannst einen mit SDCC erstellten Code mittels ST-Link
Programmer oder mit dem Bootloader hochlafen. Er wird laufen.
Zu beachten ist hier, dass beim Hochladen mittels ST-Link Programmer der
Sprung auf den Bootloader überschrieben wird und somit der Bootloader
nach eunem Flashen mit ST-Link nicht mehr funktioniert (und müsste dann
neu aufgespielt werden).