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
(ist halt "nervig" neue Boards erst an einen Windowsrechner
>hängen zu müssen).
Das St-Link Utility funktioniert WIMRE auch unter wine.
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 ?
Ralph S. schrieb: > aber ich finde zu keinem der internen > Peripherieregister die Bitbelegung und die Bedeutung dazu Meinst du das hier?
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)
1 | $stm8flash -c stlinkv2 -p stm8s103f3 -s opt -r opt.bin |
2 | Determine OPT area |
3 | Reading 64 bytes at 0x4800... OK |
4 | Bytes received: 64 |
5 | |
6 | $hd opt.bin |
7 | 00000000 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 |qqqqqqqqqqqqqqqq| |
8 | * |
9 | 00000040 |
10 | |
11 | $stm8flash -c stlinkv2 -p stm8s103f3 -s flash -r flash.bin |
12 | Determine FLASH area |
13 | Reading 8192 bytes at 0x8000... OK |
14 | Bytes received: 8192 |
15 | |
16 | $hd flash.bin |
17 | 00000000 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 |qqqqqqqqqqqqqqqq| |
18 | * |
19 | 00002000 |
Man beachte, daß alle Speicherbereiche scheinbar problemlos ausgelesen werden, es steht aber nur Müll (0x71) drin. Programmieren schlägt fehl:
1 | $make |
2 | sdcc -mstm8 --max-allocs-per-node 1000 -DSTM8S103 -c blinky.c -o blinky.rel |
3 | sdcc -mstm8 --out-fmt-ihx blinky.rel -o blinky.ihx |
4 | |
5 | $make flash |
6 | stm8flash -c stlinkv2 -p stm8s103f3 -w blinky.ihx |
7 | Determine FLASH area |
8 | 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.
1 | $hd unlock.bin |
2 | 00000000 00 00 ff 00 ff 00 ff 00 ff 00 ff |...........| |
3 | 0000000b |
4 | |
5 | $stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w unlock.bin |
6 | Determine OPT area |
7 | Writing binary file 11 bytes at 0x4800... OK |
8 | Bytes written: 11 |
Und schon funktioniert auch das Flashen wieder:
1 | $make flash |
2 | stm8flash -c stlinkv2 -p stm8s103f3 -w blinky.ihx |
3 | Determine FLASH area |
4 | Writing Intel hex file 225 bytes at 0x8000... OK |
5 | Bytes written: 225 |
6 | |
7 | $stm8flash -c stlinkv2 -p stm8s103f3 -s flash -r flash.bin |
8 | Determine FLASH area |
9 | Reading 8192 bytes at 0x8000... OK |
10 | Bytes received: 8192 |
11 | |
12 | $hd flash.bin |
13 | 00000000 82 00 80 83 82 00 00 00 82 00 00 00 82 00 00 00 |................| |
14 | 00000010 82 00 00 00 82 00 00 00 82 00 00 00 82 00 00 00 |................| |
15 | * |
16 | 00000060 82 00 00 00 82 00 80 a4 82 00 00 00 82 00 00 00 |................| |
17 | 00000070 82 00 00 00 82 00 00 00 82 00 00 00 82 00 00 00 |................| |
18 | 00000080 cc 80 c0 ae 00 01 27 07 72 4f 00 00 5a 26 f9 ae |......'.rO..Z&..| |
19 | 00000090 00 00 27 09 d6 80 e0 d7 00 01 5a 26 f7 72 5f 00 |..'.......Z&.r_.| |
20 | 000000a0 01 cc 80 80 72 5d 00 01 27 06 72 5a 00 01 20 0b |....r]..'.rZ.. .| |
21 | 000000b0 ae 50 05 f6 a8 20 f7 35 14 00 01 35 00 53 44 80 |.P... .5...5.SD.| |
22 | 000000c0 35 20 50 07 35 20 50 08 35 20 50 05 35 07 53 47 |5 P.5 P.5 P.5.SG| |
23 | 000000d0 35 9c 53 48 35 01 53 43 35 01 53 40 9a 8f 20 fd |5.SH5.SC5.S@.. .| |
24 | 000000e0 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
25 | 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
26 | * |
27 | 00002000 |
Nachtrag: zum Locken des STM8 reicht es, 0xAA nach OPT0 zu schreiben:
1 | $hd lock.bin |
2 | 00000000 aa |.| |
3 | 00000001 |
4 | |
5 | $stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w lock.bin |
6 | Determine OPT area |
7 | Writing binary file 1 bytes at 0x4800... OK |
8 | Bytes written: 1 |
9 | |
10 | $stm8flash -c stlinkv2 -p stm8s103f3 -s opt -r opt.bin |
11 | Determine OPT area |
12 | Reading 64 bytes at 0x4800... OK |
13 | Bytes received: 64 |
14 | |
15 | $hd opt.bin |
16 | 00000000 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 |qqqqqqqqqqqqqqqq| |
17 | * |
18 | 00000040 |
:
Bearbeitet durch User
... 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)
1 | ~ $openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg |
2 | Open On-Chip Debugger 0.8.0 (2014-10-20-21:48) |
3 | Licensed under GNU GPL v2 |
4 | For bug reports, read |
5 | http://openocd.sourceforge.net/doc/doxygen/bugs.html |
6 | 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 |
24 | xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc |
25 | > exit |
26 | Connection closed by foreign host. |
Locken geht genauso, nur daß man "lock 0" statt "unlock 0" verwendet. Die Anleitung stammt im wesentlichen von hier: https://stackoverflow.com/questions/32509747/stm32-read-out-protection-via-openocd
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
Vielleicht baut das einfach mal jemand in STM8FLASH ein? Der Autor akzeptiert pull-requests... https://github.com/vdudouyt/stm8flash
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?
:
Bearbeitet durch User
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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.