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
Angehängte Dateien:
-
20190928_153930.jpg
230 KB -
20190928_153943.jpg
230 KB -
20190928_153949.jpg
240 KB
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.
:
Bearbeitet durch User
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.
Ich finde den Ansatz gut: doppelt hält besser! Mit zwei SWD in Reihe kann man noch tiefer debuggen. ;-)
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:
1 | ~ $ls -l /dev/stlink* |
2 | lrwxrwxrwx 1 root root 15 Oct 1 23:42 /dev/stlinkv2-1_3 -> bus/usb/003/009 |
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.
:
Bearbeitet durch User
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?
Angehängte Dateien:
-
STM32CubeIDE_Debugger.png
89 KB -
STM32CubeIDE_Debugger2.png
100 KB
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.
Angehängte Dateien:
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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.