Hallo Entwickler,
ich bin ein STM32-Beginner und habe das Board
STM32L152C-Discovery-Board, einen ST-LINK-V2-Adapter und Debian (Linux)
als Betriebssystem auf meinem Rechner installiert.
Als IDE benutze ich STM32CubeIDE.
Ich habe damit mein erstes Projekt mit der automatisierten Grund- und
Initialisierungscode-Generierung erstellt und meinen eigenen Code in
main.c hinzugefügt, welcher die LED 4 ein- und ausschalten soll
(toggling).
Ich kann das Projekt auch ohne Probleme und Fehler kompilieren, jedoch
erhalte ich wenn ich es mit dem angeschlossenen ST-LINK-V2 debuggen
möchte, folgenden Fehler-Stack-Trace:
Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-06-12-13:05)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
adapter speed: 8000 kHz
adapter_nsrst_delay: 100
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1800 kHz
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'
Ich benutze den OCD-Debugger
Was könnte ich falsch gemacht haben? Sind vielleicht die Drähte nicht
korrekt angeschlossen (obwohl ich das mittlerweile mehrfach probiert
habe).
Im Anhang sind Bilder.
Ich habe auch mal den GBD-Server zum Debuggen von C/C++-Projekten
probiert, jedoch bekomme ich da den Fehler, daß kein Board erkannt
werden konnte, weil Timeout erfolgte.
Mittlerweile habe ich alle möglichen Debugger und
Einstellungen/Konfigurationen durchprobiert, auch den integrierten
OnBoard-Debugger nur mit USB-Kabel mit dem Rechner verbunden und ohne
den externen ST-LINK-V2-Debugger. Dabei habe ich die Jumper auf CN3 auch
wieder gesteckt, so wie es dafür sein soll.
Ich bin nun mit meinem Latein wirklich am Ende und ich hoffe, daß mir
jemand helfen kann.
Vielen Dank im Voraus für euere Mühen!
Gruß,
Marco
Klar geht das so nicht. Die Stiftleiste links dient zum Anschluß des
internen ST-Links an ein externes Target, nicht umgekehrt!
Um einen externen ST-Link mit dem internen Target, also dem L151, zu
verwenden, müssen die beiden Jumper am CN3 gezogen und SWCLK, SWDIO vom
externen ST-Link nicht etwa an CN2, sondern an CN3, Pin 2 bzw. Pin 4
angeschlossen werden. S. Schaltplan im UM1079 zum
STM32L151C-Discovery-Kit
und Table 4:
Both CN3 jumpers ON: ST-LINK/V2 functions enabled for on board
programming
(default)
Both CN3 jumpers OFF: ST-LINK/V2 functions enabled for external
application through CN2 connector (SWD supported).
VDD_TARGET (Pin 1) und GND (Pin 3) müssen an CN2 bleiben, NRST (Pin 5)
darf man nicht anschließen, weil sonst beide NRST-Ausgänge der bei
ST-Links gegeneinander arbeiten ...
Also ich hab meine Demoboards (von STM und auch die von Freescale) alle
auf J-Link umgeflasht (bei den meisten geht das) und verwende jetzt den
J-Link-GDB-Server, so kann ich für meinen Bastelkram zuhause das gleiche
Werkzeug verwenden wie auf der Arbeit, das J-Link Zeug spielt
hervorragend unter Linux. Sehr empfehlenswert.
Marco schrieb:> Ich kann das Projekt auch ohne Probleme und Fehler kompilieren, jedoch> erhalte ich wenn ich es mit dem angeschlossenen ST-LINK-V2 debuggen> möchte, folgenden Fehler> Was könnte ich falsch gemacht haben? Sind vielleicht die Drähte nicht> korrekt angeschlossen
Sind sie nicht. Darf man fragen, warum du einen externen ST-Link
verwenden willst, obwohl dein Discovery-Board doch einen solchen bereits
mitbringt? Häng das Discovery einfach mit seiner USB-Buchse an deinen PC
und bring die Jumper an CN3 wieder in Normalstellung. Dann klappt das
auch.
Wenn du die IDE von ST verwendest, gibt es auch keinen Grund, irgendwas
umzuflashen (@Bernd K. - das war nicht hilfreich!). Die Hardware von
ST funktioniert mit der Software von ST direkt.
Nochwas:
Marco schrieb:> Mittlerweile habe ich alle möglichen Debugger und> Einstellungen/Konfigurationen durchprobiert, auch den integrierten> OnBoard-Debugger nur mit USB-Kabel mit dem Rechner verbunden und ohne> den externen ST-LINK-V2-Debugger
Welche Fehlermeldung bekommst du da? Die #1 Fehlerursache unter Linux
ist die Rechtevergabe für USB-Geräte, die traditionell eher restriktiv
ist. Wenn du die IDE als normaler Nutzer (also nicht root) laufen läßt,
dann muß du die entsprechenden udev-Regeln für den ST-Link installieren
und den ST-Link neu anstöpseln.
Die Zugriffsrechte kannst du bei angeschlossenem ST-Link so prüfen:
Hier ist z.B. ein ST-Link V2-1 angeschlossen, der für jedermann schreib-
und lesbar ist. So wie es erforderlich ist.
(OK, noch sauberer wäre es, den ST-Link der Gruppe plugdev zuzuweisen
und dich als Nutzer in dieser Gruppe einzutragen. Aber auf Einbenutzer-
Linuxkisten ist das übertriebene Mühe.)
Hallo Axel,
danke für den Hinweis.
Das mit der IDE als root starten habe ich schon so eingestellt.
Allerdings ist es so, daß das das per USB angeschlossene STM32-Board von
meinem Linux gar nicht erkannt wird, also es taucht nicht in der Liste
von lsusb auf.
Ich denke, da brauche ich vermutlich noch einen USB-Treiber dafür, oder?
Also auf der st-Seite gibt es solche Treiber, allerdings nur für
Windows.
Gruß,
Marco
Marco schrieb:> Das mit der IDE als root starten habe ich schon so eingestellt.
Falsche Methode. Stattdessen über udev die richtigen Rechte einstellen.
Wenn ST das richtig gemacht hätte dann hätte der Installer für die IDE
das schon bei der Installation eingerichtet (so wie zum Beispiel J-Link
das tut), kann man aber auch von Hand eintragen.
> Ich denke, da brauche ich vermutlich noch einen USB-Treiber dafür
Nein, das ist nicht nötig, das findet alles im Userspace statt. Nur
USB-Geräte die Systemressourcen bereitstellen auf die der Kernel intern
selbst zugreifen muss wie Netzwerkschnittstellen oder dergleichen
brauchen spezielle Treiber für den Kernel. Das ist hier nicht der Fall,
hier gibt es einfach nur ein generisches USB-Gerät mit dem eine
Anwendung direkt sprechen kann, der Kernel muss nicht selbst wissen wie
man damit umgeht, er reicht es einfach nur durch. Das Treibergestresse
für jeden Pipifax ist eine reine Windows-Krankheit, das gibts nirgendwo
sonst im Universum.
Marco schrieb:> Allerdings ist es so, daß das das per USB angeschlossene STM32-Board von> meinem Linux gar nicht erkannt wird, also es taucht nicht in der Liste> von lsusb auf.
Wenn nach dem Anstecken des STLink z. B. bei 'dmesg' keine Meldung dazu
erscheint, ist der USB-Port, das Kabel oder der STLink kaputt.
Bernd K. schrieb:> Falsche Methode. Stattdessen über udev die richtigen Rechte einstellen.> Wenn ST das richtig gemacht hätte dann hätte der Installer für die IDE> das schon bei der Installation eingerichtet (so wie zum Beispiel J-Link> das tut), kann man aber auch von Hand eintragen.
Ok, doch wie stelle ich die Rechte ein? Also in welcher Datei? Und woher
kriege ich die für mein Board notwendigen Informationen? Ich habe auch
im Netz nichts auf Anhieb gefunden (vielleicht habe ich auch nicht
korrekt gesucht).
Marco schrieb:> Bernd K. schrieb:>> Falsche Methode. Stattdessen über udev die richtigen Rechte einstellen.>> Wenn ST das richtig gemacht hätte dann hätte der Installer für die IDE>> das schon bei der Installation eingerichtet (so wie zum Beispiel J-Link>> das tut), kann man aber auch von Hand eintragen.>> Ok, doch wie stelle ich die Rechte ein? Also in welcher Datei?
google: stlink udev
> Und woher> kriege ich die für mein Board notwendigen Informationen? Ich habe auch> im Netz nichts auf Anhieb gefunden (vielleicht habe ich auch nicht> korrekt gesucht).
Starte dmesg -w in einer Konsole und dann stöpsel es an und schau nach
ob idVendor und idProduct zu dem Beispiel passen das die obige
Google-Suche gleich als erstes Ergebnís liefert. Dann siehst Du auch
gleich ob es überhaupt funktioniert oder das Kabel kaputt ist oder das
Gerät.
Wenn es passt dann wirf diese Datei in den Ordner /etc/udev/rules.d/ wo
vielleicht auch schon andere ähnliche Dateien für bestimmte Geräte
herumliegen.
Ok, habe ich kontrolliert. Die Datei liegt bereits auf meinem Rechner
und ich kann sie auch im dmesg -w sehen.
Allerdings sieht es für mich so aus, als ob sich das Board ständig als
USB-Device verbindet um sich dann anschliessend wieder zu trennen.
Es sieht so aus:
[ 2.992013] usb 2-1.1.2: new full-speed USB device number 6 using
ehci-pci
[ 3.103473] usb 2-1.1.2: New USB device found, idVendor=0483,
idProduct=3748, bcdDevice= 1.00
[ 3.103477] usb 2-1.1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 3.103480] usb 2-1.1.2: Product: STM32 STLink
[ 3.103482] usb 2-1.1.2: Manufacturer: STMicroelectronics
[ 3.103485] usb 2-1.1.2: SerialNumber: Sÿrr\xc2\x87UQ9g
Dann kommt kurz darauf:
[ 3592.740008] usb 2-1.1.2: USB disconnect, device number 6
Dann später wieder:
[ 6549.761557] usb 2-1.1.2: new full-speed USB device number 7 using
ehci-pci
[ 6549.872059] usb 2-1.1.2: New USB device found, idVendor=0483,
idProduct=3748, bcdDevice= 1.00
[ 6549.872063] usb 2-1.1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 6549.872065] usb 2-1.1.2: Product: STM32 STLink
[ 6549.872067] usb 2-1.1.2: Manufacturer: STMicroelectronics
[ 6549.872069] usb 2-1.1.2: SerialNumber: Sÿrr\xc2\x87UQ9g
Daraufhin dann erneut:
[ 8358.435528] usb 2-1.1.2: USB disconnect, device number 7
Als würde das Board einen Reboot und Reset in einer Endlosschleife
ausführen.
Ich muss dazu sagen, ich habe vorhin an den Ausgängen PC7 und PC6 ein
Oszilloskop angeschlossen, weil ich da das PWM-Signal messen wollte.
Daraufhin hat auch das LCD seltsame Zeichen angezeigt und jetzt zeigt es
überhaupt nichts mehr an. Ich hoffe, ich habe nichts geschrottet
dadurch..
Doch vielleicht habe ich dadurch auch das Verbindungs-Trennungs-Problem
ausgelöst?
Also die USB-Ports an meinem Rechner sind in Ordnung, das Kabel habe ich
auch überprüft (habe zwei andere Kabel benutzt, doch gleiches
Verhalten).
Es scheint wohl an meinem Board zu liegenl
Bernd K. schrieb:> Stattdessen über udev die richtigen Rechte einstellen.> Wenn ST das richtig gemacht hätte dann hätte der Installer für die IDE> das schon bei der Installation eingerichtet
Tut er normalerweise auch.
> Ok, doch wie stelle ich die Rechte ein? Also in welcher Datei?
Erstmal die Rechte kontrollieren.
> ls -l /dev/stlink*
Gibt es eine Gruppe mit Schreibrecht? Wenn ja, trage dich in die Gruppe
ein (in /etc/group) und logge dich neu ein.
Wenn nur root Schreibzugriff hat, dann prüfe, ob die udev Regeln
installiert sind. Bei mir:
> ls /etc/udev/rules.d
49-stlinkv2-1.rules 49-stlinkv2.rules 49-stlinkv3.rules
50-salae.rules 50-usb-conf.rules 99-jlink.rules
In den Dateien steht drin, dass alle User Schreibrecht bekommen solle
(MODE:=666).
Wenn die Dateien fehlen, dann schau mal in das Installationsverzeichnis
der IDE oder installiere den STM32 Cube Programmer, da sind die nötigen
Dateien auch mit drin. Bei mir:
> ls /opt/STM32CubeProgrammer/Drivers/rules> 49-stlinkv2-1.rules 49-stlinkv2.rules 49-stlinkv3.rules 50-usb-conf.rules
Readme.txt version.txt
Die rules Dateien kopierst du nach /etc/udev/rules.d. Dann steckst du
das Gerät neu an. Kontrolliere mit dem Befehl dmesg, ob es erkannt
wurde.
Nachtrag: Ich hatte angefangen, dies vor deiner letzten Rückmeldung zu
schreiben. hat sich inzwischen wohl erübrigt.
> Als würde das Board einen Reboot und Reset in einer Endlosschleife
ausführen.
Versuche ein anderes USB Kabel und einen anderen USB Port.
Wenn du die Stromversorgung durch externe Beschaltung belastest,
versuche ein 3,3V Netzteil oder mach den Krempel erstmal ab.
Wenn du demnächst mit dem Oszilloskop arbeitest, pass auf dass nicht
hohe Ausgleichsströme durch die GND Leitungen fließen. GND vom PC sollte
die Spannung haben, wie GND vom Oszilloskop (also 0.0 Volt DC und 0.0
Volt AC dazwischen). Ich sorge immer dafür, dass alle verbundenen Geräte
in der gleichen 6-Fach Steckdosenleiste stecken.
Marco schrieb:> [ 3.103473] usb 2-1.1.2: New USB device found, idVendor=0483,> idProduct=3748, bcdDevice= 1.00> [ 3.103477] usb 2-1.1.2: New USB device strings: Mfr=1, Product=2,> SerialNumber=3> [ 3.103480] usb 2-1.1.2: Product: STM32 STLink
32-platzverweis-fuer-trimmel-95684> [ 3.103482] usb 2-1.1.2:
Manufacturer: STMicroelectronics
> [ 3.103485] usb 2-1.1.2: SerialNumber: Sÿrr\xc2\x87UQ9g>> Dann kommt kurz darauf:>> [ 3592.740008] usb 2-1.1.2: USB disconnect, device number 6
"Kurz darauf" ist wohl nicht ganz richtig ... Dazwischen liegt doch fast
eine ganze Stunde! Dazwischen nix vom STLink???
Außerdem ist das doch sicher nicht der STLink auf dem Discovery-Board,
sondern der externe??? Schonmal die Firmware aktualisiert?
Vielleicht ist das Ding auch einfach defekt oder eine schlechte Kopie.
Um einen falschen Anschluss auszuschließen sollte bei diesem Versuch am
STLink nichts weiter angeschlossen sein! Nur das USB-Kabel zum PC.
Und was ist mit dem internen STLink?
Oh ja, das mit der Zeit dazwischen habe ich wohl übersehen..
Also nun habe ich jedenfalls wieder das Discovery-Board via USB-Kabel an
meinen Rechner angeschlossen, es kommt folgender Output bei dmesg -h:
[15206.911023] usb 2-1.1.2: new full-speed USB device number 9 using
ehci-pci
[15207.022255] usb 2-1.1.2: New USB device found, idVendor=0483,
idProduct=3748, bcdDevice= 1.00
[15207.022259] usb 2-1.1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[15207.022261] usb 2-1.1.2: Product: STM32 STLink
[15207.022263] usb 2-1.1.2: Manufacturer: STMicroelectronics
[15207.022265] usb 2-1.1.2: SerialNumber: Sÿrr\xc2\x87UQ9g
Also das ist nun definitiv der board-eigene STLink.
Doch wie soll ich ein Firmware-Update machen, wenn ich auf das Board gar
nicht erst zugreifen kann?
Vom Firmware-Update abgesehen, wie muss die Debug-Einstellung in meiner
IDE sein? (Bilder im Anhang)
Marco schrieb:> Doch wie soll ich ein Firmware-Update machen, wenn ich auf das Board gar> nicht erst zugreifen kann?
Das Board wurde erkannt. Du kannst es mit einem ST-Link Steuerprogramm
(z.B. STM32 Cube Programmer) ansprechen. Du brauchst dazu Oracle Java 8
(https://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html)
und ein Startscript (http://stefanfrings.de/stm32/start.sh).
Auch die IDE sollte den ST-Link ansprechen können. Klicke dazu auf den
grünen Käfer.
> wie muss die Debug-Einstellung in meiner IDE sein?
Offensichtlich musst du "ST-Link" einstellen. Openocd und gdb
funktionieren beide. Womit du besser klar kommst, musst du selbst
probieren.
Interface ist SWD, nicht JTAG.
Schalte "Use specific ST-Link S/N" aus.
Serial Wire Viewer brauchst du vorläufig nicht.
Hallo Stefanus,
den CubeProgrammer habe ich schon, jedoch kann dieser auf mein Board
ebenfalls nicht zugreifen: "Error: No debug probe detected".
Und der Debugger in der IDE bringt folgenden Fehler bei Starten mit der
Konfiguration wie im Bild:
STMicroelectronics ST-LINK GDB server. Version 5.2.3
Copyright (c) 2019, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
LogFile Name :
/home/marco/STM32CubeIDE/workspace/STM32L152-DiscoveryBoard_FirstTest/De
bug/st-link_gdbserver_log.txt
Logging Level : 31
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Enabled
SWD Debug : Enabled
ST-Link enumeration failed
Error in initializing ST-LINK device.
Reason: ST-LINK DLL error.
Marco schrieb:> Error in initializing ST-LINK device.> Reason: ST-LINK DLL error.
Ich dachte, du nutzt Linux?!
Das passt nicht zusammen!
kontrolliere,ob die udev-rules vorhanden sind!
1
harry@hl-blue:~/Labor/AFU/tool-serial-pcap$ ls -l /etc/udev/rules.d/
2
insgesamt 100
3
-rw-rw-r-- 1 root root 627 Jun 12 16:06 49-stlinkv2-1.rules
4
-rw-rw-r-- 1 root root 503 Jun 12 16:06 49-stlinkv2.rules
5
-rw-rw-r-- 1 root root 885 Jun 12 16:06 49-stlinkv3.rules
6
-rw-r--r-- 1 root root 58549 Mai 22 18:04 70-snap.core.rules
7
-rw-r--r-- 1 root root 429 Mai 22 18:12 70-snap.gimp.rules
8
-rw-rw-r-- 1 root root 18450 Jun 12 15:28 99-jlink.rules
9
-rw-rw-r-- 1 harry harry 128 Okt 13 2018 99-MySmart.rules
10
harry@hl-blue:~/Labor/AFU/tool-serial-pcap$
Für dich wichtig ist die Datei 49-stlinkv2.rules.
Normalerweise wird die bei der Installation von CubeProgrammer usw.
automatisch erzeugt.
Wenn die fehlt, ist da im Vorfeld bereits eine ganze Menge schief
gelaufen.
Doch, ich benutze Linux, genauer gesagt Debian Version 10.
Du meinst, bestimmt wegen dem Wort "DLL" in der Debugger Ausgabe?
Die Datei 49-stlinkv2.rules existiert bei mir übrigens in
/etc/udev/rules.d und hat auch die richtigen Werte.
Systematische Fehlersuche ist nicht dein Ding, oder? Irgendwas ist da
sauer mit deinem ST-Link. Eingrenzen mußt du es selber.
1. Hardware (Kabel, Buchsen, etc.). Steck deinen ST-Link an. Wackle und
biege am Kabel. Schau nebenher mit "dmesg -w", ob er vom Kernel erkannt
wird und sich auch nicht ohne erkennbaren Grund abmeldet.
2. Zugriffsrechte. Du sagst, die udev-Regeln sind da, aber funktionieren
sie auch? Schau bei angestecktem ST-Link, ob udev den Symlink in /dev
angelegt hat und mit welchen Zugriffsrechten: "ls -l /dev/stlink*"
3. Grundlegende Funktion. Besorge dir die ST-Link Tools von
https://github.com/texane/stlink (für Debian mußt du selber
compilieren). Versuche "st-info --probe". Zeigt das deinen ST-Link und
Informationen über das Target? Probiere auch die anderen Tools. Da ist
eins zum flashen (auch mit GUI). Und ein gdb Server ist da auch.
Wenn dein ST-Link alles obige übersteht und in der IDE trotzdem nicht
funktioniert, dann liegt dort das Problem.
Hallo Axel,
doch, ich habe schon analytisch nach dem Fehler gesucht.
Zu meiner Verteidigung muss ich auch dazusagen, daß ich nicht nur
STM32-Neuling, sondern auch relativer Linux-Neuling bin ;-).
Die Kabel und USP-Ports habe ich ja bereits überprüft, auch daß die
Rechte stimmen sowie daß in /dev der stlink.. angelegt wurde. Allerdings
wurde dieser wieder nur für den externen ST-Link-Adapter angelegt,
jedoch nicht für mein Board, wenn ich dieses allein angeschlossen habe.
Bei dem externen Adapter zeigt mir der Befehl "st-info --probe" auch was
an, wenn ich dann jedoch wieder nur mein Board anschließe, ergibt der
Befehl "0 programmers found".
Also ich bin mir nun ziemlich sicher, daß mit meinem Board was faul ist
und werde das beanstanden.
Gruß
Marco
Marco schrieb:> Die Kabel und USP-Ports habe ich ja bereits überprüft, auch daß die> Rechte stimmen sowie daß in /dev der stlink.. angelegt wurde. Allerdings> wurde dieser wieder nur für den externen ST-Link-Adapter angelegt,> jedoch nicht für mein Board, wenn ich dieses allein angeschlossen habe.
Dann kann es durchaus an den udev-Regeln liegen. Auf dem STM32L152
Discovery ist ein ST-Link2 verbaut. Der muß einen Symlink in /dev
bekommen, wenn er enumeriert wird. Schau dir die VID und PID in dmesg an
und vergleiche, ob es für genau diese Kombination eine udev-Regel gibt.
Marco schrieb:> Bei dem externen Adapter zeigt mir der Befehl "st-info --probe" auch was> an, wenn ich dann jedoch wieder nur mein Board anschließe, ergibt der> Befehl "0 programmers found".
Das würde genauso passieren, wenn dir einfach nur die Zugriffsrechte auf
das USB-Gerät fehlen. Wie gesagt: Details sind wichtig!
Es kann natürlich sein, daß der ST-Link auf dem Discobery-Board kaputt
ist. Und es ist nicht mal ausgeschlossen, daß du ihn kaputt gemacht
hast. Immerhin hast du seine Ausgänge mit den Ausgängen des externen
ST-Link verbunden und so kurzgeschlossen.
Axel S. schrieb:> Es kann natürlich sein, daß der ST-Link auf dem Discobery-Board kaputt> ist. Und es ist nicht mal ausgeschlossen, daß du ihn kaputt gemacht> hast. Immerhin hast du seine Ausgänge mit den Ausgängen des externen> ST-Link verbunden und so kurzgeschlossen.
Das ist die wahrscheinlichste Variante.
Der externe ST-Link v2 und der interne ST-Link V2.1 (auf den Discovery
und Nucleo) benutzt die selbe UDEV-Regel.
20190928_153930.jpg
(230 KB)
20190928_153943.jpg
(230 KB)
20190928_153949.jpg
(240 KB)
