OpenOCD und STM32VLDiscovery

[Simon K. (simon)]

Hallo Leute,
Ich habe mir zum Beginnen mit den ARM Prozessoren ein STM32VLDiscovery 
zugelegt. Ein Board von STM mit einem STM32F100 und einem ST-LINK 
Programmer.

Nach dem Installieren der Toolchain und dem Einrichten der IDE 
(CodeBench G++ Lite und Eclipse mit Eclipse ARM Plugin) stehe ich vor 
dem Problem, dass ich OpenOCD nicht mit dem ST-LINK ans laufen bekomme.

Ich habe erst mal ein ganz simples Beispielprogramm erstellt. Dieses 
Programm kann ich mit dem STVP (Original ST Programmiersoftware) auch 
herüberladen, nachdem ich unter "OPTION BYTE" erst mal die Read 
Protection ausgeschaltet habe (diese scheint sich immer wieder 
einzuschalten?).
Das Programm selbst funktioniert soweit auch (Die blaue LED auf dem 
Discovery Board fängt an zu leuchten).

Soweit so gut! Dann hab ich erstmal die LED angestarrt und mich dabei 
gefreut ;-)
Nun will ich die ganze Sache mit OpenOCD ans laufen bekommen. Also erst 
mal mittels "Zadig"-Software den WinUSB Treiber installiert und OpenOCD 
gestartet.

F:\Apps\openocd\openocd-0.6.0-rc2\openocd-0.6.0-rc2\bin-x64>openocd-x64-0.6.0-rc2.exe -f board/stm32vldiscovery.cfg -c init -c "halt" -c "stm32f1x options_read 0" -c shutdown
Open On-Chip Debugger 0.6.0-rc2 (2012-08-29-09:26)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Warn : target was in unknown state when halt was requested
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x10016420
Info : flash size = 5384kbytes
Option Byte: 0x3fffffe
Readout Protection On
Software Watchdog
Stop: No reset generated
Standby: No reset generated
shutdown command invoked

Das sollte ja eigentlich schon ganz gut aussehen. Nun habe ich folgende 
Probleme:
- "stm32f1x mass_erase 0" Funktioniert problemlos.
- "flash write_image $file" funktioniert auch problemlos, obwohl die 
Readout Protection aktiviert ist? Aber die LED auf dem Board geht nicht 
an.
- "flash write_image erase unlock $file" funktioniert dann nicht mehr. 
Da sagt er, dass der STM32F1x protected ist, womit er ja auch Recht hat.

Ich habe aber keinen Weg herausgefunden die Code Protection aufzuheben. 
Das direkte Schreiben in das option Byte wird wohl nicht unterstützt und 
"stm32f1x unlock 0" bewirkt gar nichts (auch nicht nach trennen der 
Spannungsversorgung).

F:\Apps\openocd\openocd-0.6.0-rc2\openocd-0.6.0-rc2\bin-x64>openocd-x64-0.6.0-rc2.exe -f board/stm32vldiscovery.cfg -c init -c "halt" -c "stm32f1x options_read 0" -c "stm32f1x unlock 0" -c "reset halt" -c "stm32f1x options_read 0" -c shutdown
Open On-Chip Debugger 0.6.0-rc2 (2012-08-29-09:26)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Warn : target was in unknown state when halt was requested
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x10016420
Info : flash size = 5384kbytes
Option Byte: 0x3fffffe
Readout Protection On
Software Watchdog
Stop: No reset generated
Standby: No reset generated
Info : Device Security Bit Set
stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Option Byte: 0x3fffffe
Readout Protection On
Software Watchdog
Stop: No reset generated
Standby: No reset generated
shutdown command invoked

Die Readout Protection ist also nach dem "reset halt" immer noch 
gesetzt.

Jetzt stellt sich mir die Frage, wie man denn nun die Readout Protection 
aufhebt? Ich kann nämlich unter keinen Umständen die LED mit dem OpenOCD 
als Programmiergerät zum leuchten bringen. Das schaffe ich nur mit dem 
STVP-Tool von STM.

Ich nehme gerne sämtliche Tipps an. Habe schon gelesen, dass das ST-LINK 
V1 irgendwie Murks sein soll? Was wären denn die Alternativen zu 
brauchbarer Programmiersoftware (OpenOCD macht EIGENTLICH einen ganz 
ordentlichen Eindruck), bzw. Programmierhardware?

[Simon K. (simon)]

Hier noch das Script, mit dem ich programmieren will.
"openocd.cfg"

init

proc program {file} {
    reset halt
    stm32f1x unlock 0
    reset halt

    stm32f1x mass_erase 0
    flash write_image $file
    
    reset run
    shutdown 
}

Aufruf mit den Optionen

-f board/stm32vldiscovery.cfg
-f ${project_loc}\openocd.cfg
-c "program {${project_loc}\${config_name:${project_name}}\${project_name}.hex}"

Ausgabe:

Open On-Chip Debugger 0.6.0-rc2 (2012-08-29-09:26)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
program
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000850 msp: 0x20002000
Info : device id = 0x10016420
Info : flash size = 128kbytes
stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000850 msp: 0x20002000
stm32x mass erase complete
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x41000000 pc: 0x2000003a msp: 0x20002000
wrote 2268 bytes from file F:\Projekte\_EclipseWorkspaces\STM32\Test\Debug\Test.hex in 0.306641s (7.223 KiB/s)
shutdown command invoked

Trotzdem keine Reaktion am Target-Prozessor.

[frame (Gast)]

Soweit ich weiß, ist die OpenOCD software für SWD generell und für den 
STLink im Speziellen eher noch im Prototypenstadium.

Mit den üblichen limitierten IDE-Versionen (Keil, IAR, Atollic) hättest 
du diesbezüglich keine Probleme, die unterstützen den STLink V1.

Es gibt übrigens auch eine "STLink Utility" Software, mit der ein 
rudimentäres Debuggen möglich ist. Vor allem kann man damit eine 
gesetzte Readout-Protection deaktivieren.
Deine diesbezüglichen Probleme kann ich so nicht nachvollziehen, wobei 
ich allerdings keine Versuche mit OpenOCD gemacht habe.

Ohne große Umstände ist auf dem VL-Discovery nur die SWD-Schnittstelle 
verfügbar, und da ist die Auswahl nicht groß.
Ich benutze den STLink-Teil eines STM32F0-Discovery Boards in solchen 
Fällen. Bei STLink V2 sind dafür einfach 2 Jumper umzustecken.

[Simon K. (simon)]

frame schrieb:
> Soweit ich weiß, ist die OpenOCD software für SWD generell und für den
> STLink im Speziellen eher noch im Prototypenstadium.
Oha, okay. Da werd ich mich noch mal informieren müssen. Gegebenenfalls 
wende ich mich da mal an die Newsgroup.

SWD brauche ich aber in jedem Falle. Eventuell sollte ich doch auf eine 
andere Programmierhardware umsteigen. Für 12€ war der STM32VLDiscovery 
halt ein Schnäppchen ;-)

> Mit den üblichen limitierten IDE-Versionen (Keil, IAR, Atollic) hättest
> du diesbezüglich keine Probleme, die unterstützen den STLink V1.
Ja, das weiß ich. Hab mich da einen halben Tag mit verfügbaren IDEs 
auseinandergesetzt. Leider gibt es tatsächlich überall Begrenzungen, die 
nichts für mich sind (z.B. kein C++ in Atollic - Na super).
Da es aber mit CodeBench G++ Lite eine kommerziell gepflegte und 
aktuelle Toolchain umsonst gibt, bin ich eben einen anderen Weg 
gegangen.

> Es gibt übrigens auch eine "STLink Utility" Software, mit der ein
> rudimentäres Debuggen möglich ist. Vor allem kann man damit eine
> gesetzte Readout-Protection deaktivieren.
Da schau ich mal rein, danke!

Wie auch immer, danke fürs durchlesen :-)

[frame (Gast)]

> Leider gibt es tatsächlich überall Begrenzungen, die
> nichts für mich sind (z.B. kein C++ in Atollic - Na super).

Das habe ich auch festgestellt.
Und da ich auch noch andere Controller beackere (LPC, AT91SAM3), habe 
ich eine Crossworks-Lizenz geordert - nicht kostenlos. Auch deswegen, 
weil sie
auch unter Linux läuft. Dort wird der STLink V1 aber nicht unterstützt, 
aus eben den genannten Gründen (unter Windows schon, allerdings mit 
Fremdtreiber).

Das STLink Utility gibt es auf der ST-Webseite.
Ich habe es bis jetzt hauptsächlich für Notfälle eingesetzt, also um 
eine gesetzte Readout-Protection zu deaktivieren, oder mit "Mass Erase" 
eine wildlaufende loszuwerden.

[Simon K. (simon)]

frame schrieb:
>> Leider gibt es tatsächlich überall Begrenzungen, die
>> nichts für mich sind (z.B. kein C++ in Atollic - Na super).
>
> Das habe ich auch festgestellt.
> Und da ich auch noch andere Controller beackere (LPC, AT91SAM3), habe
> ich eine Crossworks-Lizenz geordert - nicht kostenlos. Auch deswegen,
> weil sie
> auch unter Linux läuft. Dort wird der STLink V1 aber nicht unterstützt,
> aus eben den genannten Gründen (unter Windows schon, allerdings mit
> Fremdtreiber).
Das ist dann aber sicher die nicht-kommerzielle Lizenz oder?
Ich hätte eventuell doch schon vor, ein kommerzielles Projekt damit zu 
realisieren.

[Simon K. (simon)]

Problem erkannt und umschifft:
http://www.mail-archive.com/[e-mail]/msg02461.html

Das ging schnell!

Was mir noch komisch vor kommt ist, dass nach einem Druck auf den 
RESET-Button auf dem STM32VLDiscovery Board das Programm offensichtlich 
nicht mehr anläuft oder gelöscht ist, obwohl es direkt nach dem Ende der 
Programmierung noch lief.
Das ist aber nur so, wenn ich den Code per OpenOCD übertrage. Wenn ich 
das STM32 ST-Link Utility benutze, dann kann ich RESET gefahrlos 
betätigen und das Programm läuft immer noch.

Fast so, als würde OpenOCD das Programm in den RAM schreiben, was aber 
definitiv nicht so ist.
Weiß da jemand, was da los ist?

[frame (Gast)]

> Das ist dann aber sicher die nicht-kommerzielle Lizenz oder?
> Ich hätte eventuell doch schon vor, ein kommerzielles Projekt damit zu
> realisieren.

Ja, genau.

Eine weitere gcc-basierte freie Toolchain fällt mir da ein, die den 
STM32 unterstützt, und zwar die summon-arm-toolchain. Läuft unter Linux 
und unterstützt den F1 und den F4 (hat es jedenfalls damals).
Auch der STLink (V1 für das F1-basierte VL_Discovery, und V2 für das 
F4_Discovery) wird unterstützt. Bei der STLink Treibersoftware ist auch 
ein GDB dabei.

[d.k. (Gast)]

Wie wäre es damit ?

http://www.coocox.org/CoFlash_Programmer.htm