Forum: Mikrocontroller und Digitale Elektronik STM32CubeProgrammer


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von pegel (Gast)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Es gibt etwas neues aus dem Hause ST. Den STM32CubeProgrammer.

Ersetzt das ST Link Utility und läuft prima unter Linux.
ST-Link Firmware Update hat auch funktioniert.

von Rene K. (xdraconix)


Bewertung
0 lesenswert
nicht lesenswert

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Habe es auch gerade mal ausprobiert. Bei mir funktioniert es weder unter 
Kubuntu 14.04, noch unter Arch. Führe ich STM32CubeProgrammer aus, 
bekomme ich immer den Fehler
1
Error: Could not find or load main class com.st.app.Main

Eventuell liegt es daran, dass ich kein Java von Oracle, sondern OpenJDK 
installiert habe. Der "Trusted Package Creator" funktioniert hingegen.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> dass ich kein Java von Oracle, sondern OpenJDK
> installiert habe

Mein OpenJDK ist von Oracle, oder sehe ich das falsch?

http://openjdk.java.net/

java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 
1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
2 lesenswert
nicht lesenswert
Unter OpenSuse ohne Sun Java aber mit dem normalen Distributionsjava 
muss man java-openjfx installieren.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Error: Could not find or load main class com.st.app.Main

Gleiches Problem hier.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Uwe B. schrieb:
> Unter OpenSuse ohne Sun Java aber mit dem normalen Distributionsjava
> muss man java-openjfx installieren.

Danke für den Hinweis!
Das hat auch unter Kubuntu zum Ziel geführt.

Beitrag #5270067 wurde vom Autor gelöscht.
von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Unter Arch hat es bei mir ebenfalls mit java-openjfx geklappt. Bei 
*buntu 14.04 finde ich beim besten willen keine fertigen Pakete und mir 
das selber zu kompilieren ist mir zu aufwändig, da ich das 14.04er 
ohnehin mal erneuern wollte.

pegel schrieb:
> Mein OpenJDK ist von Oracle, oder sehe ich das falsch?

Stimmt, scheint mittlerweile auch von Oracle betreut zu werden. 
Hauptsponsor und treibende Kraft hinter dem OpenJDK war lange Zeit 
Intel. Mit dem "Java von Oracle" meinte ich das "richtige" Java von 
Oracle ;)

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
... ich habs mit Slackware 14.2 ausprobiert und funktioniert mit 
java-openjfx

von Rene K. (xdraconix)


Bewertung
1 lesenswert
nicht lesenswert
Unter Windows 7 und Windows 10 läuft es ebenfalls absolut Problemlos.

Was ich ein bisschen "Naja" finde, ist der Updatezwang für den ST-Link. 
Lief aber absolut problemlos durch. Nur bei den kleinen China-ST-Link 
Clone hatte ich erst so meine Sorge, da hat er aber auch tadellos 
mitgemacht und läuft noch.

Der ST Link an den Nucleos geht wunderbar und auch der normale ST Link.

von pegel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Nach dem ich keine Möglichkeit gefunden habe den µC Speicher auszulesen 
und in eine Datei zu speichern, habe ich mir die Kommandozeilen Version 
angesehen.

Damit geht es, und noch mehr.

Hilfe:
./STM32_Programmer.sh -h

File -> µC:
./STM32_Programmer.sh -c port=SWD -w test1.bin  0x08000000

µC -> File:
./STM32_Programmer.sh -c port=SWD -r 0x08000000 0x10000 test2.bin

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ein direktes hochladen der .elf Datei und anschliessendes Reset geht so:

./STM32_Programmer.sh -c port=SWD -w Blinky.elf -rst

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
Rene K. schrieb:
> Nur bei den kleinen China-ST-Link
> Clone hatte ich erst so meine Sorge, da hat er aber auch tadellos
> mitgemacht und läuft noch.

... dann dürfte bei den Clones dann allerdings STM8 nicht mehr 
funktionieren, weil ja eine neue Firmware überschrieben wird, die keine 
Unterstützung für STM8 hat.

Oder hat das Update auch gleich eine Software mit STM8-Unterstützung 
parat ?

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gute Frage.
Ich habe leider keinen STM8 hier um das zu probieren.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
stm8flash funktioniert bei mir mit der neuesten Firmware problemlos. Im 
Grunde muss das ja auch so sein, weil ST ja auch den ST-Link V2 als 
eigenes Gerät anbietet und der explizit auch für STM8 geeignet ist. Wäre 
ja echt ein Knaller wenn sie den STM8-Support per Update entfernen 
würden und das auch noch quasi unwiederbringlich. Lediglich die 
STM32CubeProgrammer Software hat keinen STM8-Support.

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Das Tool ersetzt so wies ausschaut auch gleich den alten "FlashLoader", 
der die meisten neuen Typen (z.B. L4) nicht einmal mehr erkannt hat...

Für die platformübergreifende Veröffentlichung gibts auch ein 
Mitarbeitsplus. Sehr brav ST, sehr brav ;)

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Interessant ist, wann (und zu welchem Preis) es den STLINKv3 geben wird.
SWD mit 24 MHz hört sich ja schon mal besser als 4 MHz an ...

von Basti (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hm, scheint mit dem alten USB DFU Mode nicht kompatibel zu sein.

Musste die alten Treiber löschen und ne *.bat für die neuen Treiber 
erneut anklicken... dann konnte ich DFU Mode programmieren.

Leider erstellt es keine *.dfu Files und kann auch keine Einspielen... 
also was DFU angeht, muss ich gleich wieder zurück rollen... :-/

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
A. B. schrieb:
> Interessant ist, wann (und zu welchem Preis) es den STLINKv3 geben wird.
> SWD mit 24 MHz hört sich ja schon mal besser als 4 MHz an ...

Woher hast du diese Info?

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> A. B. schrieb:
>> Interessant ist, wann (und zu welchem Preis) es den STLINKv3 geben wird.
>> SWD mit 24 MHz hört sich ja schon mal besser als 4 MHz an ...
>
> Woher hast du diese Info?


http://www.st.com/content/ccc/resource/technical/document/user_manual/group0/76/3e/bd/0d/cf/4d/45/25/DM00403500/files/DM00403500.pdf/jcr:content/translations/en.DM00403500.pdf

Seite 28 ->
"SWD: STLinkV2: 4000 kHz, STLinkV3: 24000 kHz"

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
./STM32_Programmer_CLI

Unter "JTAG/SWD debug port optional parameters:"

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Ahhh, ich hab natürlich das Kleingedruckte nicht gelesen. Klingt sehr 
interessant. Ich gehe mal davon aus, dass der V3 dann auf einem F7 mit 
USB-HS basiert. Das dürfte dann auch einen guten Geschwindigkeitszuwachs 
beim Tracing (SWO) bringen.

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> stm8flash funktioniert bei mir mit der neuesten Firmware problemlos. Im
> Grunde muss das ja auch so sein, weil ST ja auch den ST-Link V2 als
> eigenes Gerät anbietet und der explizit auch für STM8 geeignet ist.

... ich habe jetzt auch einmal einen China-Clone riskiert und ein Update 
darauf gemacht und der Clone funktioniert mit stm8flash bei mir auch 
immer noch.

Verwunderlich, dass ein China-Clone updatefähig ist. Das was China in 
den Clones am laufen hat, dürfte dann wohl eine Raubkopie (weil nirgends 
irgendwo eine Quelle im Source frei verfügbar ist).

Vewunderlich, dass ST dem kein Riegel vorschiebt.

von Dr. Sommer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ralph S. schrieb:
> Vewunderlich, dass ST dem kein Riegel vorschiebt.

Die machen vermutlich mit dem ST-Link eh kein Geld. Da freuen die sich 
dass ein paar Chinesen ihnen den Aufwand für Produktion & Betrieb 
abnehmen, um so auch den Markt der Ultra-Geizigen zu bedienen, die an 
jedem Tool noch ein paar € sparen wollen. Im Endeffekt machen sie so 
vermutlich noch Gewinn, weil sie so mehr Controller verkaufen.

von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Im Endeffekt machen sie so
> vermutlich noch Gewinn, weil sie so mehr Controller verkaufen.

Denke ich auch. Der originale ST-Link V2 kostet bei Mouser 18,79€. Was 
wollen sie denn daran noch groß verdienen?

Ralph S. schrieb:
> Verwunderlich, dass ein China-Clone updatefähig ist. Das was China in
> den Clones am laufen hat, dürfte dann wohl eine Raubkopie (weil nirgends
> irgendwo eine Quelle im Source frei verfügbar ist).
>
> Vewunderlich, dass ST dem kein Riegel vorschiebt.

Sie können dem auch keinen Riegel vorschieben. Findige Leute haben den 
Updatemechanismus des ST-Link reversed, die (verschlüsselten) Binaries 
stecken in den .jar-Dateien des Updaters und die Schlüssel sind bekannt. 
Siehe z.B. 
http://www.taylorkillian.com/2013/01/retrieving-st-linkv2-firmware-from.html 
oder auch 
https://lujji.github.io/blog/reverse-engineering-stlink-firmware/. 
Problematisch ist die Sache in meinen Augen vor allem für Firmen wie 
Segger, die dann per Update einen J-Link daraus machen, den aber nicht 
verschenken wollen, weil sie eben damit ihre Brötchen verdienen. Es 
grenzt für mich schon fast schon an ein Wunder, dass die ST-Link "mini" 
Dinger nicht auch in identischer Bauweise als J-Link "mini" verkauft 
werden.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:

> verschenken wollen, weil sie eben damit ihre Brötchen verdienen. Es
> grenzt für mich schon fast schon an ein Wunder, dass die ST-Link "mini"
> Dinger nicht auch in identischer Bauweise als J-Link "mini" verkauft
> werden.

Hm, 
https://www.aliexpress.com/item/CJMCU-Jlink-for-SWD-Jlink-3-Wire-for-STM32-on-SWD-Debug/32622682260.html 
sieht verdächtig genau danach aus.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Joa, sieht tatsächlich so aus. Scheint sich wohl noch nicht in ganz 
Shenzhen herumgesprochen zu haben, sonst wären es die exakt gleichen 
Dinger wie die ST-Link, also im USB-Dongle nur eben mit anderer Firmware 
und der Preisunterschied wäre geringer bzw. nicht vorhanden ;)

von Bla (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat so ein Segger J-Link Vorteile gegenüber einem ST-Link? Außer dass 
der J-Link auch andere Controller als ST kann?

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bla schrieb:
> Hat so ein Segger J-Link Vorteile gegenüber einem ST-Link?
Die sind wesentlich schneller und stabiler, und es gibt offiziellen 
Linux-Support (auch zum Debuggen, nicht nur Flashen). Es hat vermutlich 
seinen Grund, warum ST bei seinen "Premium"-Eval-Kits einen J-Link und 
keinen ST-Link beilegt... ;-)

von Bla (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie viel ist denn wesentlich? Wenn ich 3-4 Sekunden brauche um mit dem 
ST-Link 64k Flash eines STM32F0 zu programmieren, was könnte so ein 
Segger zeitlich?

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bla schrieb:
> as könnte so ein
> Segger zeitlich?
Hier steht was dazu:
https://www.segger.com/products/debug-probes/j-link/technology/flash-download/#tab-3145-1

Bei mir war's jedenfalls so schnell dass das Starten der 
Debug-Configuration in eclipse schon länger dauert ;-)
Wichtiger als die Geschwindigkeit des Flashens ist aber IMO die 
Geschwindigkeit fürs Step-by-Step-Debuggen. Das war (zumindest bei mir) 
beim ST-Link immer 1-2sec pro Zeile, beim JLink kaum wahrnehmbar (0.1sec 
oder so).
Beim ST-Link haben mich die skurrilen wohl von der Mondphase abhängigen 
Fehler (selbst von der Original ST-Software) irgendwann so genervt dass 
ich mir einen JLink "gegönnt" habe... Das hat sich auf jeden Fall 
gelohnt. Für den Einstieg ist ein ST-Link aber gewiss nicht verkehrt.

von Bla (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Interessant, danke. Ich frage nicht einmal für mich. Die Fertigung hätte 
immer am liebsten alles ganz schnell, aber setzt nen ST-Link ein. Werde 
mal drauf hinweisen

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bla schrieb:
> Die Fertigung hätte
> immer am liebsten alles ganz schnell, aber setzt nen ST-Link ein. Werde
> mal drauf hinweisen
Jo. Die haben auch spezielle Production Programmer zum 
Massen-Programmieren:
https://www.segger.com/products/production/flasher/
Aber nicht ganz billig ;-)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich kann Dr. Sommers Bemerkungen zum ST-Link nicht bestätigen.

Ich experimentiere seit einem Jahr mit STM32F103 Controllern und hatte 
bisher noch kein einziges mal Fehlfunktionen oder Treiberprobleme. Auch 
die Geschwindigkeit beim Debuggen ist völlig Ok (weitaus schneller als 
1-2s pro Step). Ich habe keineswegs das Gefühl, dass der ST-Link mich 
irgendwo merklich ausbremst oder behindert.

Meine Erfahrungen beziehen sich auf den ST-Link v2.1, der am Nucleo64 
Board hängt. Den nutze ich auch für "externe" Chips.

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der STLink kann fast so schnell sein wie ein JLink wenn die Software 
mitmacht. Mit OpenOCD hatte ich auch das Problem daß jeder Einzelschritt 
eine gute Sekunde gebraucht hat. Mit Crossworks dagegen geht das 
praktisch ohne Verzögerung - wie mit einem JLink.
Das Flashen ist mit dem JLink vielleicht 30% schneller.

Einziges Problem das ich mit dem STLink habe ist daß ich das Teil kurz 
vom USB abstecken muß wenn ein Verbindungsfehler aufgetreten ist. Z.B. 
wenn ich die Stromversorgung vom Controller abgeschaltet habe. Beim 
JLink reicht dann ein einfacher "Reconnect" per Software.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Einziges Problem das ich mit dem STLink habe ist daß ich das Teil kurz
> vom USB abstecken muß wenn ein Verbindungsfehler aufgetreten ist

Ist mir noch nicht passiert. Meiner kann "einfach so" reconnecten.

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Das GUI Dingens mach hier Zicken (die CLI Version nicht). Umgebung: 
Debian 8, x86_64. Schon der Installer wollte nicht mit meiner 
default-JRE 1.7.0_151 starten, also habe ich JAVA_HOME auf die 1.8-er 
JRE gesetzt. Dann lief immerhin der Installer los. Die Anwendung selber 
dann nicht.

Fehlermeldung:
1
Exception in Application start method
2
... (stack trace)
3
There is an incompatible JNA native library installed on this system
4
Expected: 5.2.0
5
Found:    4.0.0
6
...
7
To resolve this issue you may do one of the following:
8
 - remove or uninstall the offending library
9
 - set the system property jna.nosys=true
10
 - set jna.boot.library.path to include the path to the version of the 
11
   jnidispatch library included with the JNA jar file you are using

Punkt 1 kommt nicht in Frage. Punkt 2 führte zum Ziel, nachdem ich 
herausgefunden habe, wie man dieses dämliche Java bequatschen muß, damit 
es tut was man will:
1
cat STM32CubeProgrammer
2
#!/bin/bash
3
4
# XL was here!
5
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
6
export JAVA_TOOL_OPTIONS=-Djna.nosys=true
7
# end XL
8
9
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
10
export LD_LIBRARY_PATH=$DIR/../lib:$LD_LIBRARY_PATH
11
$DIR/STM32CubeProgrammerLauncher

Warum STM ihr Startup-Gerümpel als Binärcode ausliefert und Java nicht 
einfach aus einem Shellskript aufruft wie alle anderen das tun, verstehe 
ich auch nicht.

von Til S. (Firma: SEGGER) (til_s)


Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Bla schrieb:
>> Die Fertigung hätte
>> immer am liebsten alles ganz schnell, aber setzt nen ST-Link ein. Werde
>> mal drauf hinweisen
> Jo. Die haben auch spezielle Production Programmer zum
> Massen-Programmieren:
> https://www.segger.com/products/production/flasher/
> Aber nicht ganz billig ;-)

Ich denke ~600,- Euro in die Fertigung investieren kann sich lohnen. 
Wenn die Produktion steht wird es wahrscheinlich teurer ;-). Kommt aber 
sicherlich immer auf die Anzahl der gefertigten Geräte an. Wenn ich nur 
10 Geräte im Jahr fertige reicht vielleicht auch ein ST-Link.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Ich kann Dr. Sommers Bemerkungen zum ST-Link nicht bestätigen.
>
> Ich experimentiere seit einem Jahr mit STM32F103 Controllern
Ja es kann gut sein dass sich das geändert hat, seitdem ich meine 
Probleme damit hatte (ca 2012). OpenOCD hatte da IIRC noch gar keinen 
ST-Link Support, das ging unter Linux nur mit dem texane st-link 
utility. Oft hatte ich die Situation, dass entweder nur das texane 
st-link funktionierte oder das ST-Eigene ST-Link Utility - aber nie 
beide an einem Tag. Außerdem konnte das ST-Link keine Controller 
resetten, die sich im Sleep-Mode ("WFI"-Instruktion) befinden - der 
JLink hat da keine Probleme mit. Deswegen hab ich gewechselt und nicht 
zurückgeblickt ;-)
Vor ca. 2 Jahren hab ich mir ein STM32F7-Discovery zugelegt, und der 
interne ST-Link hat natürlich überhaupt nicht funktioniert - die 
ST-eigene SW4STM32-Software hat nur kuriose Fehlermeldungen produziert. 
Das war mir zu blöd, hab mir von einem Freund helfen lassen die 
SWD-Leitungen rauszuführen (super dass die kaum zugänglich sind), JLink 
drangeklemmt, hat sofort funktioniert.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
PS: Ich habe mal mit einen STM32-Discovery-Board von der Uni gearbeitet 
und da ganz naiv auch "WFI" genutzt - ich kannte den Trick, den 
Reset-Button im richtigen Moment zu drücken, ja. Am nächsten Tag 
beschuldigte mich der Prof den Controller zerstört/gebrickt zu haben 
(Debug-Interface abgeschaltet oder so), weil die integrierten ST-Links 
nicht mehr funktionierten. Da wusste ich wieder warum ich dieses Teil 
wenn möglich vermeide!

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Außerdem konnte das ST-Link keine Controller
> resetten, die sich im Sleep-Mode ("WFI"-Instruktion) befinden

Das kann er inzwischen, wenn man die optionale Reset Leitung verbindet.

Bei den Nucleo64 Boards ist die Reset Leitung auch ordentlich mit dem 
Target verbunden.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok, das ist gut. Wäre auch leicht absurd, stromsparende Controller wie 
die STM32L*-Serie zu vermarkten, und dann die Nutzung der wichtigstem 
Stromspare-Maßnahme (Sleepmodes) unnötig zu erschweren...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Offensichtlich befindet sich die Software von ST auf breiter Front noch 
im Entwicklungsstadium. Naja, Atmel war in dieser Hinsicht auch nicht 
besser.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert
Demnächst soll es einen ST-Link/v3 geben, der wohl deutlich schneller 
als die bisherigen ST-Link und ST-Link/v2v sein soll:

https://community.st.com/thread/46479-stlinkv3

Philipp

von Til S. (Firma: SEGGER) (til_s)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hmm...wenn ich auf den Link klicke, komme ich auf die Seite im 
Screenshot...SCNR ;-)

: Bearbeitet durch User
von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das kommt weil du das vom Firmennetz aus aufrufst!

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
Til S. schrieb:
> Hmm...wenn ich auf den Link klicke, komme ich auf die Seite im
> Screenshot...SCNR ;-)

Ja, ein Bug in der Forensoftware von ST. Manchmal geht es, manchmal 
nicht. Für viele (einschließlich mir) funktioniert es nahezu immer, wenn 
ich bei ST eingeloggt bin, aber ohne Login nur etwa jedes zweite Mal. 
Scheint sich aber jeden Tag zu ändern. Dazu gibt es schon eine lange 
Diskussion: 
https://community.st.com/message/180957-re-how-to-use-forum-nowdayshttps://community.st.com/message/180957-re-how-to-use-forum-nowdays

Philipp

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Für viele (einschließlich mir) funktioniert es nahezu immer, wenn
> ich bei ST eingeloggt bin

Das hatte ich noch nicht probiert aber nachdem ich mich mal eingeloggt 
habe, hat es dann auch funktioniert. Es kam dann gleich ein "Welcome to 
Jive" und danach gleich oben die Meldung "We have identified the 
technical issues..." vom 01.01.18 ;)

Naja, die Mühlen bei ST mahlen eben manchmal etwas langsamer :D

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Man kann den Stlink auch zu einem BMP Debugger umflashen:
https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe

Single Stepping geht da ohne nennenswertes Delay.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert
Uwe B. schrieb:
> Man kann den Stlink auch zu einem BMP Debugger umflashen:
> https://embdev.net/articles/STM_Discovery_as_Black_Magic_Probe
>
> Single Stepping geht da ohne nennenswertes Delay.

Aber dann halt nicht mehr für den STM8.

Philipp

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Der STLink auf den Disco/Nucleo Boards kann aber sowieso kein SWIM fuer 
STM8.

von J.P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dabei das Tool (STM32CubeProgrammer) auszuprobieren.

Die Verbindung mit dem Device über UART funktioniert.
Beim Ausführen der "STM32Bootloader.bat"-Datei, für die Installation des 
"USB DFU" Treibers, bekomme ich folgende Fehlermeldung:

"Verarbeitungsinf.:            DFU_in_HS_Mode.inf
Fehler beim Hinzufügen des Treiberpakets: Der Hashwert für die Datei ist 
in der angegebenen Katalogdatei nicht vorhanden. Die Datei ist 
wahrscheinlich beschädigt oder wurde unerlaubt geändert."

Den alten USB-Treiber für das "DfuSe" Tool habe ich inkl. des Tools 
deinstalliert und dann die .bat-Datei ausgeführt. Also genau so wie es 
in der Anleitung steht.

Das STM32CubeProgrammer Tool läst sicht einwandfrei starten und die 
Verbindung zum Device über UART funktioniert auch.

Ist dieses Problem auch schon bei jemandem aufgetretten?
Gibt es eine Lösung?

von pegel (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt habe ich auch ein Problem mit dem CubeProg.
In Ubuntu nach der Aktualisierung von openjdk-8 auf openjdk-11 startet 
die graphische Oberfläche nicht mehr.
Hat jemand eine Lösung, ohne zur Version 8 zurück zu kehren?

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
openjfx ist natürlich installiert und aktuell.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Du musst Oracle JRE 8 verwenden. Ist doof, geht aber nicht anders. Nimm 
diesen Download: 
https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

Und starte das Programm mit folgendem Script:
1
#!/bin/bash
2
3
# Set path of Oracle JRE 8
4
JAVA_HOME=/opt/jre1.8.0_202-amd64/
5
6
PATH=$JAVA_HOME/bin/:$PATH
7
8
# Unpack libraries, if necessary
9
cd $JAVA_HOME/lib
10
if [ ! -f rt.jar ]; then
11
    ../bin/unpack200 rt.pack rt.jar
12
fi
13
if [ ! -f jsse.jar ]; then
14
    ../bin/unpack200 jsse.pack jsse.jar
15
fi
16
if [ ! -f charsets.jar ]; then
17
    ../bin/unpack200 charsets.pack charsets.jar
18
fi
19
20
# Start STM32 Cube Programmer
21
cd /opt/STM32CubeProgrammer
22
bin/STM32CubeProgrammer

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ist doof

Das stimmt. Darum will ich das möglichst vermeiden.
Problem ist, auch die Versionen 1.0 und 1.4 vom CubeProg wollen nicht 
mehr.
Ob ST das wohl ändern wird?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ob ST das wohl ändern wird?

Ich glaube nicht, dass sie die alten Programme noch pflegen. Aber sie 
sollten wenigstens die aktuelle Version für Java 11 fit machen und die 
Abhängigkeit zu Java FX loswerden.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die 2.0 hatte ich noch am Laufen.
Mit der 2.1 und dem neuen CubeMX wollte ich alles auf den neuesten Stand 
bringen. :(

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Die 2.0 hatte ich noch am Laufen.
> Mit der 2.1 und dem neuen CubeMX wollte ich alles auf den neuesten Stand
> bringen. :(

Läuft 2.1 schon wieder nicht? Auch nicht mit Orale JRE 8?

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe openjdk-8 vollständig deinstalliert, da kein anderes Programm 
das mehr benutzt hat.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ich habe openjdk-8 vollständig deinstalliert, da kein anderes Programm
> das mehr benutzt hat.

Ich rede aber von Oracle JRE 8. Und zwar von dem Download der Oracle 
Seite.

Oracle JDK ist nicht Oracle JDK und Oracle JRE ist wieder (in Details) 
anders.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ist wohl irgendwie alles Oracle, nur die Lizenzen unterscheiden sich.
Mit Oracle JRE 8 geht es mir nicht sonderlich gut.
Deshalb mein zögern.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ach ja, der Unterschied JDK zu JRE ist mir bekannt.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Ist wohl irgendwie alles Oracle, nur die Lizenzen unterscheiden sich.

Nein.

Oracle JRE enthält nur die Laufzeitumgebung, während Oracle JDK auch 
Entwickler-Tools enthält. Beide Oracle Pakete enthalten Features, die in 
Open JRE/JDK nicht enthalten sind. Umgekehrt enthält die Open-Variante 
Features, die die der kommerziellen Version von Oracle nicht enthalten 
sind.

Ich programmiere beruflich seit 20 Jahren mit Java. Dieser Cube 
Programmer ist allerdings mein erster Fall, wo diese feinen Unterschiede 
zwischen geht und geht-nicht entscheiden.

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist nur die graphische Oberfläche.
Die Kommandozeilen Version funktioniert ja.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Version 2.1.0 läuft jetzt bei mir.

https://community.st.com/s/question/0D50X00009q3X4jSAE/stm32cubeprogrammer-for-linux

Dank dem Beitrag:
1
Kolja Waschk (Community Member)
2
a month ago
3
4
For the record, I seem to have succeeded in Ubuntu 18.04 with openjdk-11 and openjfx 11 after commenting out the check for javafx in STM32CubeProgrammer/util/OpenJFXScript.csh and replacing the 
5
6
    $DIR/STM32CubeProgrammerLauncher in STM32CubeProgrammer/bin/STM32CubeProgrammer by
7
        java --module-path /usr/share/openjfx/lib --add-modules=javafx.controls,javafx.base,javafx.fxml,javafx.media,javafx.web,javafx.swing -jar $DIR/STM32CubeProgrammerLauncher

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich meine natürlich die graphische Oberfläche.

Im Textmodus funktioniert auch die neue 2.2.1 .

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde gar nicht so großartig herum fummeln sondern das Programm 
einfach mit der Java Version starten, für die es geschrieben wurde. Und 
das ist Oracle JRE 1.8.

https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

Benutze dazu das Startscript aus Beitrag 
Beitrag "Re: STM32CubeProgrammer"

Das funktioniert mit allen Programm-Versionen, die bisher veröffentlicht 
wurden. So spart man sich, bei jeder neuen Version mit neuen Problemen 
zu kämpfen.

Ich verstehe auch gar nicht, warum manche Leute sich so schwer damit 
tun, neben der aktuellen auch eine alte Java Version zu installieren. 
Die schließen sich ja nicht gegenseitig aus!

Wer das für grobe Platzverschwendung hält möge mal bitte die Größe des 
Paketes mit dem tatsächlichen Disk Space vergleichen. Oder schau mal in 
deine Windows Installation, wie viele Versionen vom wesentlich größeren 
.NET Framework da parallel installiert sind. Auch auf Linux Rechnern 
findet man zahlreiche Bibliotheken parallel in unterschiedlichen 
Versionen - so what?

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich will OpenJava! Nicht Oracle! ;)

Davon habe ich die 8 und die 11 umschaltbar installiert.
Die 2.2.1 funktioniert auch mit der 8 nicht.

Ausserdem ist es nur vorübergehend.
STM ist sehr dynamisch, ich denke die schaffen das bald.

Bis dahin ist das für die gedacht, die das so sehen wie ich.

Andere können das gern ignorieren.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> STM ist sehr dynamisch, ich denke die schaffen das bald.

Ich warte seit einem Jahr darauf.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan F. schrieb:
> Ich warte seit einem Jahr darauf.

Noch etwas Geduld bitte.

Das mit CubeMX auf 4k Schirm und viele andere Kleinigkeiten sprechen für 
sich.

Ich bin guter Hoffnung.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.