Stlink: STM32F100RBT6: Fehler beim Lesen von core_id und unbekanntem Gerät

Danke für die Berichterstattung. Ich kann dies mit meiner STM32VL Discovery-Karte überprüfen, die mit diesem Chip geliefert wird.

Habe das gleiche Problem.
Überprüft mit der Version aus dem Repository community/stlink 1.6.1-1 und dem neuesten Entwicklungszweig.
Board - STM32VLDISCOVERY

Linux i5 5.4.61-rt37-MANJARO #1 SMP PREEMPT_RT Sat Aug 29 17:09:34 UTC 2020 x86_64 GNU/Linux
core/libusb 1.0.23-2
extra/libusb-compat 0.1.7-1

Letzte Arbeitsverpflichtung: e3aa887f7ffdfcfb3a0529ee3b94a7d3fe39b5d8

Wie ich in der stlinkV3-Ausgabe geschrieben habe: Der Patch kann die Unterstützung von Version 1 unterbrechen (https://github.com/stlink-org/stlink/issues/820#issuecomment-617591438).

@ WK-M Können Sie versuchen, Patch, um Zweig zu entwickeln:

index 9726ddc..a683267 100644
--- a/src/stlink-lib/usb.c
+++ b/src/stlink-lib/usb.c
@@ -261,7 +261,10 @@ int _stlink_usb_write_debug32(stlink_t *sl, uint32_t addr, uint32_t data) {
 }

 int _stlink_usb_get_rw_status(stlink_t *sl) {
-    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { return(-1); }
+    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { 
+        /* STLINK does not support getting statuses. Returns the IO operation is success */
+        return 0;
+    }

     unsigned char* const rdata = sl->q_buf;
     struct stlink_libusb * const slu = sl->backend_data;
@@ -300,7 +303,7 @@ int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {

     if (ret == -1) { return(ret); }

-    ret = send_only(slu, 0, data, len);
+    ret = send_only(slu, 1, data, len);

     if (ret == -1) { return(ret); }

Wie ich in der stlinkV3-Ausgabe geschrieben habe: Der Patch kann die v1-Unterstützung unterbrechen ( # 820 (Kommentar) ).

@ WK-M Können Sie versuchen, Patch, um Zweig zu entwickeln:

index 9726ddc..a683267 100644
--- a/src/stlink-lib/usb.c
+++ b/src/stlink-lib/usb.c
@@ -261,7 +261,10 @@ int _stlink_usb_write_debug32(stlink_t *sl, uint32_t addr, uint32_t data) {
 }

 int _stlink_usb_get_rw_status(stlink_t *sl) {
-    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { return(-1); }
+    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { 
+        /* STLINK does not support getting statuses. Returns the IO operation is success */
+        return 0;
+    }

     unsigned char* const rdata = sl->q_buf;
     struct stlink_libusb * const slu = sl->backend_data;
@@ -300,7 +303,7 @@ int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {

     if (ret == -1) { return(ret); }

-    ret = send_only(slu, 0, data, len);
+    ret = send_only(slu, 1, data, len);

     if (ret == -1) { return(ret); }

Wenn Sie "Patch zum Entwickeln eines Zweigs" angeben, wollten Sie, dass ich zum Entwicklungszweig auschecke und dieselben Befehle versuche? Wenn Sie das nicht gemeint haben, lassen Sie es mich bitte wissen.

Andernfalls habe ich den Checkout für den Entwicklungszweig durchgeführt und die ordnungsgemäße Neuinstallation durchgeführt. Ich habe immer noch die gleichen Fehler, die im ursprünglichen Beitrag erwähnt wurden.

@ WK-M Ich wende einen Patch auf den neuen Zweig https://github.com/Ant-ON/stlink/tree/try_fix_stlinkv1 an. Versuchen Sie, den Zweig try_fix_stlinkv1 zu klonen und das stlink-Tool aus dem Quellcode zu erstellen.

Danke für die Klarstellung. Ich habe den Patch geklont und stoße immer noch auf dieselben Probleme.

Ich bin nicht sicher, ob dies ein Fedora-spezifisches Problem ist, da auf meinem Ubuntu-Computer nicht derselbe Fehler auftritt.

@Vascom Irgendeine Idee bezüglich Fedora? Es sieht aus wie ein Problem mit libusb.
@ WK-M welche Version von libusb verwenden Sie? Haben Sie versucht, es neu zu installieren oder zu aktualisieren?

F32 verwendet libusbx-1.0.23.
Welche Version bei Ubuntu?

Entschuldigung für die späte Antwort.

Aus dem Befehl: dpkg -l libusb-1.0* ich Folgendes erhalten:

+++-======================-================-============-===================================================
ii  libusb-1.0-0:amd64     2:1.0.23-2build1 amd64        userspace USB programming library
ii  libusb-1.0-0-dev:amd64 2:1.0.23-2build1 amd64        userspace USB programming library development files

Wird dies in Angriff genommen, irgendein Fortschritt?
Ich habe die ID dafür bei der Ankündigung für 1.6.2 noch nicht gesehen, aber natürlich dank aller Bemühungen der Entwickler.
Ich selbst habe das gleiche Problem, bei VL Discovery bin ich unterwegs, werde aber meine Daten später veröffentlichen. Ubuntu 16.04LTS frische Box, ja, ich liebe irgendwie Retro! ....
Haben Sie es versucht, erinnern Sie sich an stlink-download.c, das woanders gepostet wurde? (Ich habe mit diesem Code herumgespielt, um zu sehen, ob die Nullen von einem anderen seltsamen Fehler stammen, aber ich habe auch das Gefühl, dass libusb schuld ist ...)
Grüße

Ich aktualisiere.
Für meine VL Discovery funktioniert jetzt alles.
Verwenden des Ubuntu 16.04LTS-Kernels 4.15.18-041518-generic.
Libusb-0.1.4 (2: 0.1.12-28) sowohl: amd als auch: i386 und
Libusb-1.0.0 (2: 1.0.20-1) Sowohl: amd als auch: i386 sind auf diesem Computer gemäß der Ausgabe von 'dpkg -l libusb ' installiert(Ich denke, das liegt daran, dass ich für andere Probleme, die ich zuvor hatte und die nicht mit STLink zu tun hatten, in der Vergangenheit viele Neukompilierungen und Versionsversuche für libusb durchgeführt habe. Ich kann mich jetzt nicht genau erinnern ...)(Korrigieren Sie mich auch, wenn ich mich irren könnte, aber ich glaube nicht, dass die Koexistenz von i386-Versionen einen Unterschied zu diesem gemeldeten Problem macht.)Jedenfalls hat das bei mir funktioniert:Ich musste nur -fr alle libstlink unter / usr / local / lib
Fahren Sie dann fort, stlink von 1.6.0-Baum neu zu kompilieren, den ich in der Sicherung hatte.
Vielleicht kann dies auch etwas Licht ins Dunkel bringen:
Ich hatte zuvor bemerkt, dass ich durch Aufrufen von 'stlink-download / dev / stlinkv1-1 info' direkt nach dem Anschließen der VL an den USB-Anschluss und anschließendes Aufrufen von 'stlink-gui' die Stlink-gui das Gerät abfragen und die Wertzeile erhalten konnte ID und Chipid ohne Probleme, und danach gab auch 'st-info —probe' die richtigen Werte aus, aber dann konnte keine Debug-Sitzung in gdb die zu löschende Flash-Routine in SRAM laden, und es schlug fehl. .
Wenn ich direkt nach dem Anschließen des USB-Sticks mit dem Starten von 'st-info -probe' fortfahre, hat dies nicht funktioniert. Ich musste immer 'stlink-download' (auch wenn es selbst fehlgeschlagen ist) für beide 'stlink-gui' starten. und 'st-info —probe', um von diesem Moment an die richtigen ID-Werte zu erhalten ... ziemlich seltsam, es scheint, als ob die ausführbare Datei zum Herunterladen von stlink beiläufig für einige nicht so eifrige interne Änderungen in VL sorgt, die es richtig machen (meistens) ) danach.
Dieses Experiment könnte den Entwicklern vielleicht einen Hinweis geben, was das Problem darunter sein könnte ... Ich hoffe es!
Wie ich bereits sagte, bestand die Lösung für mich darin, alte / widersprüchliche Bibliotheken zu löschen und neu zu kompilieren, ABER 1.6.0 zu verwenden. Vielleicht möchten Sie auch sicherstellen, dass Sie anschließend für alle Fälle eine 'sudo ldconfig' ausführen.
Übrigens finden Sie den oben genannten "stlink-download" unter:
https://github.com/vanbwodonk/arm-utilities/blob/master/stlink-download/stlink-download.c
(Diese Site scheint auch eine konsolidierte Version von Version 2 beizubehalten. Jede dieser beiden Versionen verdeutlicht - siehe Kommentare im C-Code - die tiefgreifende Natur der ST-Link / V1-SCSI-basierten Codierung ...)
Ich kann wirklich nicht verstehen, warum sich die ST-Ingenieure für diese unorthodoxe Art der Kommunikation mit dem F103-Chip entschieden haben ... das ist ein so kitschiger Programmier-Firmware-Job, wie ich ihn noch nie gesehen habe ... Ich denke, sie verdienen es, dass die Firmware "entschlüsselt" wird. bemerkt, dass sie unter einer Gruppe von Hobbyisten da draußen leiden mussten, verdiente meiner Meinung nach eine Bestrafung;)
Jetzt bin ich endlich glücklich und GDB-fähig unter Linux mit meiner VL Discovery.
Ich war so glücklich, dass ich ZWEI weitere von diesem Board bestellt habe, für nur 15 USD pro Stück, die beiden dort auf Lager befindlichen Finals waren von einem Distributor. Finde es heraus! Ich hasse programmierte Veralterung wirklich sehr, daher bin ich ziemlich glücklich, wenn ich veraltete Hardware für alles, was mit uC zu tun hat, wiederbelebe, besonders wenn es unter Linux läuft!

Libusb-0.1.x wird von diesem Toolset nicht verwendet und daher nicht benötigt.
@mosagepa Dies

Ich habe auch einen STM32F100RBT6 (VL Discovery) mit STLINK-V1, hatte aber leider noch keine Zeit, außer professioneller Arbeit irgendwelche Tests durchzuführen ...

Hallo, danke für deine Kommentare.

Die Lösung, die ich gefunden habe, um meine Anforderungen zu erfüllen, und die für unzufriedene StLink v1 / VL-Besitzer, die versuchen, sie unter Linux zu verwenden, nicht zu schwer zu befolgen ist, als Problemumgehung, bis die Entwickler einen Zeitrahmen dafür finden packe das an :) Aber ich stimme zu, die stlink-download.c ist eine Rigmarole, aber eine Rigmarole, die ich nur für den Fall erwähnt habe, dass sie dir einen Hinweis geben könnte. Ich meine, warum kann das Dienstprogramm st-info danach die richtigen Werte abrufen, wenn es ausgeführt wird? (Aber kein Blinken funktioniert, bis Sie die aktuellen Bibliotheken löschen und wie gesagt durch 1.6.0 ersetzen ...) Gibt Ihnen dies einen kleinen Hinweis, auch wenn dies nur aus Intuition geschieht?

Ich denke, ich kann versuchen, die tatsächlichen Aufrufe, Parameter und die Ausführung der aktuellen Version 1.6.x mit den "schlechten" Bibliotheken im Vergleich zu den Versionen 1.6.0 selbst zu vergleichen / zu verfolgen / zu debuggen, da es ziemlich offensichtlich ist, dass die Unterschiede nicht sein können Aufgrund unterschiedlicher Schnittstellen oder Ähnlichem bin ich mir fast sicher, dass dies eine subtile Eigenart sein muss, die wir / Sie noch nicht gefunden haben.

Wenn ich diesbezüglich Fortschritte mache, lasse ich die Leute jetzt hier.

Neues Update:
Ich habe festgestellt, dass selbst wenn die Bibliotheken wie oben beschrieben "gelöscht" wurden, der erste Aufruf von "st-info --probe" eine signifikante (und unterschiedliche, aber für jede meiner 3 VL Discoveries konsistente) Seriennummer ergibt. Kurz nachdem Sie sie an den USB-Anschluss angeschlossen haben, ABER sobald Sie 'st-info --probe' neu starten, wird das Modell immer noch korrekt als Wertlinie F1xxx bla bla erkannt ... ABER ergibt jetzt 0x30 0x30 0x30 ..... dh Alle Nullen verketten als "seriell".
Vielleicht gibt mir dies einen Anhaltspunkt, um zu debuggen, was hier wirklich passiert. Hoffentlich kann ich den "Fehler" (oder das Problem) nach den inneren Aufrufen in der 'st-info'-Ausführung bis zu seinem Ursprung zurückverfolgen.
Ich bin hartnäckig, nur weil ich möchte, dass die VL Discovery nicht für immer in Vergessenheit gerät, sondern unter Linux die richtige "Unterstützung" erhält. Ich denke, jede Hilfe in dieser Hinsicht kann von einer Reihe von Nutzern geschätzt werden VLs, wenn noch eine Minderheit, die ich kenne ...

Ich möchte hinzufügen (und ja, ich weiß, dass dies kein Forum ist, aber trotzdem ...). Ich hatte einmal einen Freund, der Firmwares und Produkte für Automobilprodukte mit NXP-Chips entwirft und Einwände gegen meine Behausung und Verschleierung von "End-Of-" erhebt. Life "-Produkte, so argumentierte er, haben die Entwicklungsboards und Kits die Lebensdauer von Fliegen und erfüllen nur ihren Zweck, während die HW-Leute das endgültige Board herausfinden, aber die SW / FW-Leute sollten den Support-Code auch mit den Prototypen entwickeln .
Wenn also die Chip- / uC-Hersteller eine neue "Linie" auf den Markt bringen, müssen sie (die Unternehmen, die echte Produkte herstellen) die Entwicklungskits kaufen, um schneller zu sein als ihre Konkurrenten, die ihr Endprodukt auf der Basis einer neuen Linie auf den Markt bringen.
Das heißt, jeder Hobbyist, der ältere veraltete Plattformen benutzte (oder wiederbelebte, wie ich es normalerweise tue) und diese veralteten Kits aus zweiter Hand kaufte, machte sich lächerlich.
Ich verstehe, kann aber nicht glücklich sein, mich solchen Überlegungen anzupassen, und deshalb bin ich so hartnäckig mit diesem und vielen anderen HW / FW-Dingen für UCs. Ich habe den gleichen Respekt vor Leuten, die darauf bestehen, beispielsweise 16F84-PICs zu verwenden, nur weil sie es wollen (oder sich nichts "schickeres" leisten können). Dieselbe Geschichte mit STM32, die sich ständig verbessert, um Linien und Kits zu verbessern: Ich hoffe, dass einige andere Seelen dort die VL Discovery noch in Projekten oder einfach nur zum Spaß verwenden möchten und von jedem Fortschritt in diesem Bereich profitieren können. Aber ich schweife ab...

Ich habe das gleiche Problem mit meinem STM32VLDISCOVERY-Board. ST-LINK V1 wird von Linux Mint 20.1 erkannt, aber st-util funktioniert nicht oder st-info liest die Chip-Informationen nicht richtig.

EDIT: Ich habe Folgendes getan, um es zum Laufen zu bringen:

cd /usr/local/lib
sudo rm -fr all libstlink*
rm ~/Repo/stlink/*.*
rmdir ~/Repo/stlink
git clone -b v1.6.0 https://github.com/stlink-org/stlink.git

make clean
make release
cd build/Release && sudo make install
sudo ldconfig
// the udev rules files are still in place
// the /etc/modprobe.d file is still in place for /etc/modprobe.d/stlink_v1.conf
sudo udevadm control --reload-rules
sudo udevadm trigger
reboot the system

Etwas in Version 1.6.1 hat dazu geführt, dass stlink-v1 nicht mehr funktioniert. Aber ich arbeite, wenn Sie auf V1.6.0 zurücksetzen

Genau der gleiche Ansatz, den ich verwendet habe, @GadgetAngel Herzlichen Glückwunsch!
Ich versuche, andere Berufe in den Griff zu bekommen, um herauszufinden, was genau die Unterschiede zwischen 1.6.0 und 1.6.1 sind.

Bitte können Sie bestätigen, ob Sie auch damit konfrontiert sind (ich kopiere hier das Fragment des vorherigen Beitrags):

_- "Ich habe festgestellt, dass selbst wenn die Bibliotheken wie oben beschrieben" gelöscht "wurden, der erste Aufruf von 'st-info --probe' eine signifikante (und unterschiedliche, aber konsistente für eine meiner 3 VL-Entdeckungen) ergibt. Seriennummer, kurz nachdem Sie sie an den USB-Anschluss angeschlossen haben, ABER sobald Sie 'st-info --probe' neu starten, wird das Modell immer noch korrekt als Wertzeile F1xxx bla bla erkannt ... ABER ergibt jetzt 0x30 0x30 0x30 ... .. dh alle Nullen Kette als "seriell" ._

_