Hallo und guten Abend,
ich "bastle" schon eine Weile an meiner eigenen (Textmode)IDE unter
Linux. Mittlerweile habe ich hierfür auch ARM - STM32 und 8Bit STM8
Controller hinzugefügt.
Beide kann ich mit einem Chinaclone STLINKV2 flashen.
Soweit FAST alles gut, aber eben nur FAST.
Ein Minimumboard STM32F103C8 Board geht sofort.
Ein Board auf dem ein Maple Leaf Mini Bootloader ist geht nicht sofort
(ich will logischerweise nicht mit Maple Leaf Libraries hantieren).
Hierfür muß ich den Bootloader entfernen.
Dieses gestaltet sich unter Linux (für mich) als unmöglich. Ich habe
keine Software gefunden, die das "Protection readout" beim Löschen
zurücksetzt. Dieses konnte ich leider nur unter Windows mit den
originalen ST Programmen bewerkstelligen. Nachdem dieses gelöscht ist,
funktioniert dieser Maple Clone auch.
Selbiges gilt für das Ultrabilligboard mit einem STM8S103F3 (1€ aus
China). Auch hier kann ich mit dem STLINKV2 erst dann auf das Board
zugreifen, wenn ich unter Windows zuvor das Readout protection Byte beim
Löschen zurückgesetzt habe.
Unter Linux verwende ich
- für die STM32 Controller das Programm: st-flash
- für den STM8 Controller das Programm: stm8flash
Kennt jemand Programme unter Linux, bei denen ich bei neuen
(unbehandelten) Chinaboards diese Protection Bytes löschen kann (ist
halt "nervig" neue Boards erst an einen Windowsrechner hängen zu
müssen).
Gruß,
Ralph
Hab ich... funzt nicht !
Auch ein Schreiben eines einzelnen Bytes (bspw. 0xaa beim STM8) an die
Adresse im Speicher, die das Protectionbyte enthällt funktioniert nicht
... Leider
Ralph S. schrieb:> Unter Linux verwende ich>> - für die STM32 Controller das Programm: st-flash> - für den STM8 Controller das Programm: stm8flash>> Kennt jemand Programme unter Linux, bei denen ich bei neuen> (unbehandelten) Chinaboards diese Protection Bytes löschen kann (ist> halt "nervig" neue Boards erst an einen Windowsrechner hängen zu> müssen).
Wenn du ein J-Link hast, dann kannst du einen STM32xx mit dem JLinkSTM32
Tool unlocken.
Ralph S. schrieb:> Auch ein Schreiben eines einzelnen Bytes (bspw. 0xaa beim STM8) an die> Adresse im Speicher, die das Protectionbyte enthällt funktioniert nicht
Kannst du das genauer ausführen? Hast du beachtet, daß du zwei Bytes
schreiben muß, um die Protection ein- bzw. auszuschalten?
Ich habe gerade das gleiche Problem gehabt und mich geärgert, daß
stm8flash beim Lesen eines geschützten STM8F103 ungerührt Bullshit liest
und beim Schreiben mit einer unspezifischen Fehlermeldung abbricht. Auch
ich mußte meinen ST-Link erstmal an das Notfall-Windows auf dem Laptop
stöpseln um mit STVP zu schauen, was da los ist.
Ich gehe aber davon aus, daß es funktionieren sollte, die Protection
durch Beschreiben der config area abzuschalten. Muß ich bei Gelegenheit
mal ausprobieren.
na Boar schrieb:> Das St-Link Utility funktioniert WIMRE auch unter wine.
... meines Wissens funktioniert ein serielles ST-LINK Gerät, ein USB
ST-LINK/V2 funktioniert unter WINE deshalb nicht, weil von WINE aus
keinen Zugriff auf USB hast...
Axel S. schrieb:> Kannst du das genauer ausführen? Hast du beachtet, daß du zwei Bytes> schreiben muß, um die Protection ein- bzw. auszuschalten?
Hab ich beachtet...
Das Problem ist, dass das Protectionbyte nur mit einem Löschvorgang
geschrieben werden kann, dem Löschvorgang kann ich aber unter den
CLI-Tools unter Linux eben nicht mitgeben, dass das POB geloescht wird.
Wie das die Windows-Tools von ST das machen weiß ich nicht.
Smile, im übrigen hab ich ja das eigentliche größere (und gleiche)
Problem mit STM32... der STM8 ist ja (zumindest für mich einfach nur mal
zum Ausprobieren gewesen).
By the way:
Ich such mich gerade dämlich nach dem Datenblatt eines STM8S103F. Es
schwirren zwar ewig viele herum, aaaaaber:
Da steht dann bspw, dass die Adresse von UART1_BRR1 (Baudratenregister
1) = 0x5232 ist, aber ich finde zu keinem der internen
Peripherieregister die Bitbelegung und die Bedeutung dazu.
Kennt da jemand eine Quelle ?
Max M. schrieb:> Meinst du das hier?
Vielen Dank, genau DAS ist das, was ich gesucht habe ! (Allerdings weiß
ich noch nicht so recht, WIE TIEF ich einsteigen mag, UART, SPI und I2C
halt ...
Danke noch mal .
Ralph S. schrieb:> ... meines Wissens funktioniert ein serielles ST-LINK Gerät, ein USB> ST-LINK/V2 funktioniert unter WINE deshalb nicht, weil von WINE aus> keinen Zugriff auf USB hast...>
Man kann Code schreiben, der die Zugriffe auf libusb umsetzt:
https://github.com/UweBonnes/wine Branch stlink
Axel S. schrieb:> Ich gehe aber davon aus, daß es funktionieren sollte, die Protection> durch Beschreiben der config area abzuschalten. Muß ich bei Gelegenheit> mal ausprobieren.
Und funktioniert. Es gibt aber einen Trick. Hier ist, wie sich ein
geschützter STM8S103F3 verhält (China-Board im Auslieferungszustand)
Writing Intel hex file 225 bytes at 0x8000... Tries exceeded
9
Makefile:29: recipe for target 'flash' failed
10
make: *** [flash] Error 255
Zum Unlocken müssen wir die Option-Area beschreiben. Allerdings reicht
es nicht, nur das erste Byte zu setzen. Es müssen alle Optionbytes
geschrieben werden; und zwar vor allem müssen die negierten Optionbytes
auch negiert sein. Ich schreibe hier einfach die Defaultwerte rein.
... da habe ich mir doch glatt noch ein STM8 bestellt ... nur um zu
sehen ob das so funktioniert ... und in meine "nie erscheinende
Distribution" als Script Eingang findet (da ich nun kein Chinaboard im
Auslieferungszustand habe).
Aaaaaber ich werde es so wie du das beschrieben hast an dem nicht
"gesperrten" Board-chen ausprobieren.
Hmmm, mit STM32 hast du nichts am Hut, wäre irgendwie klasse, wenn es
eine ähnliche Lösung für das STM32F103CBT6 Board mit Maple Leaf mini
Bootloader geben würde... (werde ich allerdings einmal nach deinem
Schema so mal für den STM32 versuchen, vielleicht klappts).
Ralph S. schrieb:> ... da habe ich mir doch glatt noch ein STM8 bestellt ... nur um zu> sehen ob das so funktioniert ... und in meine "nie erscheinende> Distribution" als Script Eingang findet (da ich nun kein Chinaboard im> Auslieferungszustand habe).
Mußt du nicht mal. Wenn du das Board sperrst, indem du 0xAA nach OPT0
schreibst, verhält es sich genauso wie im Auslieferungszustand.
Nochwas: wenn man 0x00 nach OPT0 schreibt, dann löscht der STM8 ganz wie
spezifiziert seinen Flash, Config und EEPROM. Man kann das alles dann
auch auslesen (kommt überall 0x00 raus). In das Flash schreiben kann man
aber erst wieder, wenn man saubere Werte in die Config Area geschrieben
hat. Das Manual sagt darüber nichts, sondern behauptet im Gegenteil, daß
invalide Option-Bytes (das negierte Byte paßt nicht zum Optionbyte) so
behandelt werden, als würden die Defaults drin stehen. Stimmt nur leider
nicht.
> Hmmm, mit STM32 hast du nichts am Hut, wäre irgendwie klasse, wenn es> eine ähnliche Lösung für das STM32F103CBT6 Board mit Maple Leaf mini> Bootloader geben würde...
Funktioniert für mich mit openocd. Testsubjekt ist ein
STM32F103C8T6 STM32 Billig Board am ST-Link V2 (China-Klon)
Info : This adapter doesn't support configurable speed
7
Info : STLINK v2 JTAG v27 API v2 SWIM v6 VID 0x0483 PID 0x3748
8
Info : using stlink api v2
9
Info : Target voltage: 3.243973
10
Info : stm32f1x.cpu: hardware has 6 breakpoints, 0 watchpoints
Das folgende mache ich jetzt interaktiv. Man kann die Kommandos aber
auch in ein .cfg File schreiben und das mit dem -f
Kommandozeilenschalter direkt von openocd ausführen lassen:
1
~ $telnet localhost 4444
2
Trying ::1...
3
Trying 127.0.0.1...
4
Connected to localhost.
5
Escape character is '^]'.
6
Open On-Chip Debugger
7
> init
8
> reset halt
9
target state: halted
10
target halted due to debug-request, current mode: Thread
11
xPSR: 0x01000000 pc: 0x080075d0 msp: 0x20005000
12
> stm32f1x unlock 0
13
device id = 0x20036410
14
flash size = 49713kbytes
15
Device Security Bit Set
16
target state: halted
17
target halted due to breakpoint, current mode: Thread
18
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20005000
19
stm32x unlocked.
20
INFO: a reset or power cycle is required for the new settings to take effect.
21
> reset halt
22
target state: halted
23
target halted due to debug-request, current mode: Thread
Axel S. schrieb:> Funktioniert für mich mit openocd. Testsubjekt ist ein> STM32F103C8T6 STM32 Billig Board am ST-Link V2 (China-Klon)
Mit diesem Billigboard habe ich auch keine Probleme und ohne jetzt mein
Script hier zur Verfügung zu haben glaube ich, dass ich es für dieses
Board zumindest so ähnlich auch gelöst habe (das ist das Board mit den -
für mich - außerordentlich häßlichen gelben Steckbrückenjumpern).
Mit dem Billigboard STM32F103CBT6 (man beachte das B) hat das aber
leider nicht funktioniert, irgendwie scheint sich bei diesem Board (es
ist ein Maple Leaf Mini - Clone) der aufgespielte USB-Bootloader zu
sperren.
Aaaaaalerdings weiß ich nicht, ob ich nach dem
-init
ein
-reset halt
gemacht hatte...
Ich werde das so noch einmal ausprobieren.
Vielen Dank für die Mühe
Gruß,
Ralph
Tim . schrieb:> Vielleicht baut das einfach mal jemand in STM8FLASH ein?
Hab ich kurz drüber nachgedacht. Und es dann verworfen. Das "unlock.bin"
File kann man sich mit "echo -e ..." trivial selber erzeugen. Und
insbesondere auch gleich passend zu den gewünschten Option-Bits. Denn
meistens wird man ja nicht beim Factory-Default bleiben wollen.
Was nett wäre, wäre ein GUI-Tool analog STVP, das die Option-Bits aus
einer menschenlesbaren GUI passend erzeugt und dann stm8flash passend
aufruft. Das kann man im Prinzip recht schnell in PerlTk oder TclTk
hinrotzen. Der Aufwand steckt dann darin, ihm die ganzen Flavours an
STM8 Controllern beizubringen. Aber da ich vermutlich nicht mehr als
zwei oder drei Mitglieder der Familie jemals einsetzen werde, ist es mir
den Aufwand ehrlich gesagt nicht wert ...
Ich war mal so frei:
https://github.com/cpldcpu/stm8flash
Jetzt gibt es eine Option "-u", die die option Bytes auf den factory
default State setzt und die Write Protection entfernt.
Ist am Ende halt doch einfacher, als sich eine Anleitung zu ergooglen.
Tim . schrieb:> https://github.com/cpldcpu/stm8flash>> Jetzt gibt es eine Option "-u", die die option Bytes auf den factory> default State setzt und die Write Protection entfernt.
Gut gemeint. Vfg bsg qnf Trtragrvy iba "thg trznpug". (rot13)
> Ist am Ende halt doch einfacher, als sich eine Anleitung zu ergooglen.
In diesem speziellen Fall wird es dadurch leider nicht einfacher,
sondern schwieriger. Denn du setzt stillschweigend voraus, daß jeder der
den Code verwendet, auch weiß daß er zusammen mit -u auch noch -b (und
die Anzahl der Optionbytes) angeben muß. Das geht weder aus der
Fehlermeldung hervor, noch aus dem README noch hast du es hier erwähnt.
Aber das ist noch nicht alles. Ich zähle mal die Probleme auf, die ich
auf Anhieb sehe:
1. du setzt voraus, daß das erste Optionbyte für ROP zuständig ist und
zum Unlocken auf 0x00 gesetzt werden muß. Das stimmt z.B. schon mal
nicht für den STM8L052C6 (und vermutlich für alle STM8L nicht). Da muß
man 0xAA schreiben um ROP zu deaktivieren.
2. du setzt voraus, daß alle weiteren Optionbytes paarweise auftreten
und daß das erste Byte immer 0x00 und das zweite 0xFF sein muß. Stimmt
ebenfalls nicht für die STM8Lxxx
Und das ist genau das, was ich weiter oben meinte mit
Axel S. schrieb:> Der Aufwand steckt dann darin, ihm die ganzen Flavours an> STM8 Controllern beizubringen.
Denn wenn man das richtig machen wöllte, dann müßte man die Default-
Optionbytes in das stm8_devices[] Array in stm8.c packen. Und zwar
idealerweise für alle STM8 µC die stm8flash kennt. Wenn du dir diese
Arbeit machen willst, dann wäre das eine runde Sache. Aber so wie es
jetzt ist, sehe ich es eher als Verschlimmerung denn als Verbesserung.
Axel S. schrieb:>Gut gemeint. Vfg bsg qnf Trtragrvy iba "thg trznpug". (rot13)
Du darfst gerne mithelfen ;)
> In diesem speziellen Fall wird es dadurch leider nicht einfacher,> sondern schwieriger. Denn du setzt stillschweigend voraus, daß jeder der> den Code verwendet, auch weiß daß er zusammen mit -u auch noch -b (und> die Anzahl der Optionbytes) angeben muß. Das geht weder aus der> Fehlermeldung hervor, noch aus dem README noch hast du es hier erwähnt.
Nö, muss man nicht. Es funktioniert auch, den kompletten OPT-Bereich mit
dem definierten Muster zu beschreiben.
Ich hatte zunächst eine Erweiterung der Device-Definition eingebaut,
welche die Anzahl der Bytes genau definiert. Ich habe das aber später
verworfen, da es auch so funktioniert.
Axel S. schrieb:> 1. du setzt voraus, daß das erste Optionbyte für ROP zuständig ist und> zum Unlocken auf 0x00 gesetzt werden muß. Das stimmt z.B. schon mal> nicht für den STM8L052C6 (und vermutlich für alle STM8L nicht). Da muß> man 0xAA schreiben um ROP zu deaktivieren.
Hm... das war mir nicht bewusst, und ist eine ziemlich schwache Nummer
von ST. Offensichtlich ist es notwendig, die Device-Definition zu
erweitern.
Gibt es weitere Ausnahmen?
Tim . schrieb:> Axel S. schrieb:>> 1. du setzt voraus, daß das erste Optionbyte für ROP zuständig ist und>> zum Unlocken auf 0x00 gesetzt werden muß. Das stimmt z.B. schon mal>> nicht für den STM8L052C6 (und vermutlich für alle STM8L nicht). Da muß>> man 0xAA schreiben um ROP zu deaktivieren.>> Hm... das war mir nicht bewusst, und ist eine ziemlich schwache Nummer> von ST. Offensichtlich ist es notwendig, die Device-Definition zu> erweitern.>> Gibt es weitere Ausnahmen?
Davon würde ich ausgehen. Wie gesagt: ich verwende nur eine Handvoll
STM8 Derivate. Zu denen habe ich die Datenblätter hier liegen, in die
ich schnell mal geschaut habe. Angesichts des eher überschaubaren
Nutzens habe ich mich dagegen entschieden, die gefühlt 100 weiteren
Varianten des STM8 auch noch zu studieren.
Thread beobachten
Seitenaufteilung abschalten