Hallo, Referenz-Thread: Beitrag "USB CDC von Stefan Frings und WS" ich bekomme den Code nicht ans Laufen. Ich verwende die aktuellste Version 1.4.2 der STM32 Cube IDE und habe das Projekt dort (als Ac6 Toolchain) importiert. Das ging fehlerfrei und es kompiliert auch fehlerfrei. Aber wenn ich mein Blue Pill Board an USB stecke, wird es von Windows als "Anderes Gerät" identifiziert und es kann kein Treiber gefunden werden. VID und PID stimmen, also es werden Daten übertragen. Wenn ich HAL CDC verwende, läuft es problemlos, also liegt kein technischer Defekt vor. Woanders hier im Forum (Beitrag "STM32F103-USB-CDC von W.S.") entdeckte jemand, dass neuere Compiler die Nop() Funktion wegoptimieren, was mit Abschaltung der Optimierung via "void __attribute__((optimize("O0"))) Nop(uint32_t count)" gelöst werden kann. Aber auch das hat nicht geholfen. Hat jemand eine Idee, woran es liegen könnte, oder wie ich mich der Ursache des Problems nähern kann? Grüße Thorsten
Ich habe es gerade für dich mit der STM32 Cube IDE 1.4.0 und 1.4.2 unter Linux ausprobiert - läuft. Dann habe ich Windows gebootet, auch da wird das Board erkannt und ich sehe die "Hello World!" Meldungen im Hammer Terminal. Download: http://stefanfrings.de/stm32/STM32F103_usb_test.zip Hast du den Widerstand R10 korrigiert? Er soll 1,5kΩ haben. Ich habe zur Korrektur 1,8kΩ parallel zum falschen Bauteil geschaltet. Zur Zeit sind viele (alle?) Blue-Pill Boards mit gefälschten Chips bestückt. Hier im Forum hatte mal jemand ein Testprogramm veröffentlicht, mit dem man schlechte Fälschungen erkennen kann.
Thorsten S. schrieb: > ich bekomme den Code nicht ans Laufen. Welchen? Hast du die Fehler-korrigierte Version probiert? https://github.com/Erlkoenig90/WSusb Du könntest das Board an einen Linux-PC anschließen, Linux gibt im Kernel-Log deutlich bessere Fehlermeldungen aus wenn ein USB-Gerät nicht das tut was Linux erwartet.
@ Stefan: Ich habe einen 2K Widerstand nach 3.3V gelegt, daran liegt es nicht. Kannst du mir eventuell dein vollständiges CubeIDE Projekt per e-Mail senden? Hatte dir gestern eine e-Mail geschrieben (an die e-Mail Adresse von deiner Homepage).
Thorsten S. schrieb: > Kannst du mir eventuell dein vollständiges CubeIDE Projekt per > e-Mail senden? Ich habe es doch oben verlinkt!
Das habe ich auch verwendet. Musste ich aber in die Cube IDE importieren. Ich meinte das fertig importierte Projekt. Vielleicht ist beim Import etwas schiefgelaufen.
Beim Import kann gar nichts schief laufen. Wie gesagt habe ich es gerade noch ausprobiert.
Niklas G. schrieb: > Du könntest das Board an einen Linux-PC anschließen, Linux gibt im > Kernel-Log deutlich bessere Fehlermeldungen aus wenn ein USB-Gerät nicht > das tut was Linux erwartet. Unter Windoof gibts das hier: https://www.uwe-sieber.de/usbtreeview.html Hat mir bei vielen USB Dingen auch schon gut weitergeholfen.
Thorsten S. schrieb: > Wenn ich HAL CDC verwende, läuft es problemlos, also liegt kein > technischer Defekt vor. Stimmt, dann können wir falsche Widerstände und schlecht gefälschten Chip ausschließen.
USB-Treeview ist ein interessantes Tool. Bevor ich hier den ganzen Output poste, fällt mir diese Fehlermeldung auf: String descriptors are not available (because the device has problem code CM_PROB_FAILED_INSTALL) Eine Idee dazu?
Thorsten S. schrieb: > Eine Idee dazu? Laut Microsoft Knowledgebase bedeutet das, dass der Treiber nicht geladen wurde. Nicht sehr hilfreich.
Es ist verrückt. Wenn die Hardware läuft, kann es ja nur ein Problem mit der Softwareseite sein. Da die Software aber prinzipiell funktioniert, muss es irgendeine Compiler-Option oder sowas sein. Vielleicht ging beim Import des Projekts doch etwas schief. @Stefan: Können wir die Größen der Ausgabedatei im Release-Build vergleichen? text data bss dec hex filename 3884 12 1636 5532 159c STM32F103_usb_test.elf
Thorsten S. schrieb: > Können wir die Größen der Ausgabedatei im Release-Build > vergleichen? > text data bss dec hex filename > 3884 12 1636 5532 159c STM32F103_usb_test.elf Interessant, ich habe etwas andere Zahlen: text data bss dec hex filename 3856 12 1636 5504 1580 STM32F103_usb_test.elf Aber ob das jetzt irgend etwas zu bedeuten hat, und wenn ja, was ...? Ich habe dir mein Projekt inzwischen samt Binaries per mail geschickt. > Da die Software aber prinzipiell funktioniert, > muss es irgendeine Compiler-Option oder sowas sein. Ich habe nichts verändert. Die Assembler Optionen sind: -mcpu=cortex-m3 -c -x assembler-with-cpp --specs=nano.specs -mfloat-abi=soft -mthumb Die Compiler Optionen sind: -mcpu=cortex-m3 -std=gnu11 -DSTM32 -DSTM32F1 -DSTM32F103C8Tx -c -I"/home/stefan/Programmierung/STM32/STM32F103_usb_test/CMSIS/core" -I"/home/stefan/Programmierung/STM32/STM32F103_usb_test Die Linker Optionen sind: -mcpu=cortex-m3 -T"/home/stefan/Programmierung/STM32/STM32F103_usb_test/LinkerScript.ld" --specs=nosys.specs -Wl,-Map="${ProjName}.map" -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
Vielen Dank für eure Unterstützung! Ich werde dein Projekt heute Abend ausprobieren und berichte dann. (Übrigens waren beide deiner Mails im Spam, habe deine erste Antwort erst gerade gelesen.)
Thorsten S. schrieb: > Übrigens waren beide deiner Mails im Spam Und? Was kann ich dafür? Besorge dir lieber einen ordentlichen SPAM Filter, oder stelle ihn ab.
Stefan ⛄ F. schrieb: > Und? Was kann ich dafür? Das war nicht als Angriff oder Kritik gemeint, sondern als Information, warum ich auf deine erste Mail gar nichts erwidert hatte. Danke nochmal für eure Unterstützung.
Thorsten S. schrieb: > Aber wenn ich mein Blue Pill Board an USB stecke, wird es > von Windows als "Anderes Gerät" identifiziert und es kann kein Treiber > gefunden werden. VID und PID stimmen, also es werden Daten übertragen. Also welche vid+pid wird denn auf dem PC angezeigt? Wenn es die von Nuvoton ist, dann wundert es mich nicht, daß das Ding als 'anderes Gerät' angezeigt wird. Nochwas zu dem ewigen Thema Warteschleife bei GCC-Benutzern: Die dient wirklich nur dazu, daß ein paar µs vergehen, so daß der Host das ACK-Paket noch auf der Adresse 0 abholen kann, bevor man die gegebene Adresse per USB_SetAddress setzt. Im Prinzip müßte es auch ausreichen, nachzuschauen, ob im zugehörigen EP Register STAT_TX noch gesetzt ist. Wenn nicht, dann ist das (leere) ACK-Paket über die Bühne und man kann problemlos die Adresse setzen. Wenn ich mal Zeit dafür haben sollte, teste ich das mal aus. Also so etwa maximal 20x nachschauen, ob STAT_TX noch 3 ist. Ich füg dir mal einen Auszug aus meinem damaligen Projekt bei (was ich schon früher hier mal gepostet hatte): das ist die fertig übersetzte Firmware für einen STM32F103C8T6, die sich am USB als Nuvoton-Gerät meldet. Flashe die doch probehalber mal drauf, denn ich weiß, daß die bei mir so wie sie ist auch funktioniert. Und lade dir mal USBTREEVIEW herunter und schau damit mal, ob mit meiner Firmware die Strings einigermaßen vernünftig am PC aussehen. Mir kommt da nämlich der Verdacht hoch, daß etwas mit den EP-Puffern bei dir nicht stimmt. Die alten STM32F103C8T6 haben nämlich eine ausgesprochen eigenartige Art, wie man auf den Puffer zugreifen darf und wie nicht. Ich hatte das in der Quelle vermerkt, siehe:
1 | /* Layout des USB RAM's (512 Bytes) |
2 | ================================
|
3 | Der RAM geht aus Sicht der CPU von 0x40006000 bis 0x400063FF, |
4 | also 0x400 Bytes gleich 1024 Bytes und das Layout ist krötig, |
5 | weil die Hälfte nicht implementiert ist und zu 0 gelesen wird! |
6 | Er ist NUR 16 bitweise les- und schreibbar! NICHT byteweise |
7 | und auch nicht wirklich 32 bitweise. |
8 | Beispiel: |
9 | Text sei "Hello-World" |
10 | 0x40006000: 48 65 00 00 6C 6C 00 00 6F 2D 00 00 57 6F 00 00 72 6C 00 00 64 ... |
11 | H e l l o - W o r l d ... |
Und Stefan hat bemerkt, daß es bei anderen STM32 mit fast identischem USB_Core nicht mehr so eigenartig ist. Könnte ja sein, daß der Chip auf deinem Board das auch anders handhabt - ist ne Vermutung meinerseits. W.S.
@W.S.: Wenn ich die Blue Pill mit deiner Firmware einstecke, wird das Gerät gar nicht mehr erkannt. Inzwischen habe ich aber mehr meinen PC oder das USB-Kabel im Verdacht und werde da morgen weiter forschen. Die VID/PID von Stefans Treiber sind 0x0416 / 0x5011. (lt. Kommentar Realtek) Zunächst habe ich versucht herauszufinden, warum die Text-Segmente des Binaries unterschiedlich groß sind. Schuldig ist: void __attribute__((optimize(0))) Nop(uint32_t count) Wenn ich das zurücksetze auf den Original-Code: void Nop(uint32_t count) Ist das Binary identisch groß. Damit ist schon mal eine verwunderliche Sache geklärt. Morgen gucke ich weiter.
Welches OS benutzt du denn? Falls das < W8 ist gibt's keine direkte Unterstützung für CDC dann brauchst du eine inf Datei.
Thomas Z. schrieb: > Welches OS benutzt du denn? Falls das < W8 ist gibt's keine > direkte > Unterstützung für CDC dann brauchst du eine inf Datei. Gute Frage. Ich war einfach von Windows 10 ausgegangen, weil ich mir nichts anderes mehr vorstellen kann.
Ich benutze Windows 7. Der Hal CDC ging problemlos, woher bekomme ich eine .inf Datei?
Thorsten S. schrieb: > woher bekomme ich eine .inf Datei? Ha! Da haben wir vor lauter Bäumen den Wald nicht mehr gesehen. W.S. hier mal vor einigen Jahren mal die inf Datei von Nuvoton (als Kommentar am Ende der Datei usb.h) veröffentlicht: Beitrag "Re: USB des STM32 F103C8T6 nutzen" Ansonsten kannst du (falls es nicht kommerziell ist) vielleicht einfach die ID Nummern von ST kopieren, dann wird nämlich (hoffentlich) deren Treiber geladen, den die IDE freundlicherweise installiert hat. Den Treiber kann man auf der Webseite von ST natürlich auch einzeln downloaden.
Stefan ⛄ F. schrieb: > Thorsten S. schrieb: >> woher bekomme ich eine .inf Datei? > > Ha! Da haben wir vor lauter Bäumen den Wald nicht mehr gesehen. Thorsten S. schrieb: > Wenn ich die Blue Pill mit deiner Firmware einstecke, wird das > Gerät gar nicht mehr erkannt. Also, ihr beiden, was ist denn nun? Thorsten hätte ja auch mal etwas genauer die Situation bei sich beschreiben können - außer nur "gar nicht erkannt". Das ist ja noch 'vielsagender' als die Fehlermeldungen bei Windows. Was also mach denn Windows beim Reinstecken? Fängt es an zu rödeln und sagt dann unbekanntes Gerät? Oder tut sich rein garnix? Oder was? Bei Stefans Beitrag kommt mir der Verdacht, daß es schlicht und einfach nur an der .inf liegt, die da angeblich fehlt. Aber die ist ja bei der Quelle dabei - und zwar in der usb.h als Kommentar drin. Es wäre ja ein Treppenwitz, daß unsereiner grübelt, ob da bei Thorsten das ganze Pinsetup nicht stimmt oder der Chip ein Fake ist oder das Kabel nix taugt oder der GCC mal wieder Mist baut oder sonstwas Schlimmes - und dann liegt's nur an der Inf-Datei. Einen Punkt hätte ich aber noch: im Original von mir (wo Stefans Link hinzeigt) ist in Zeilen 291+292 die Power-Deklaration und je nachdem, was Thorsten bei sich ansonsten so mit dem Ding anstellt, wäre da eine Korrektur nötig:
1 | 0xC0, /* bmAttributes */ |
2 | 0x32, /* MaxPower */ |
Die bmAttributes sind Bit 7: 1=immer, 6: 1=selfpowered, 5: 0=kein remote wakeup und MaxPower 0x32=50=100mA. Wenn das nicht paßt, dann muß das angepaßt werden, sonst ist mitten im Enumerieren ggf. der Strom weg. Ist mir noch nie selber passiert, aber wie Win10 sich da benimmt weiß ich nicht. W.S.
W.S. schrieb: > je nachdem, was Thorsten bei sich ansonsten so mit dem Ding anstellt, > wäre da eine Korrektur nötig: 0xC0, /* bmAttributes > */ > 0x32, /* MaxPower */ > > Die bmAttributes sind Bit 7: 1=immer, 6: 1=selfpowered, 5: 0=kein remote > wakeup und MaxPower 0x32=50=100mA Das passt schon auch wenn bei selfpowered die Maxpower auch auf 0 gestellt werden kann. 100mA wäre lowpower das kann ein Usbanschluss immer. Das von dir genannte Szenario könnte nur bei einem Hipower Device auftreten. Dann wird aber die Enum nach dem Lesen des Devicedeskriptors abgebrochen und es erscheint eine Fehlermeldung in der Taskleiste.
Thomas Z. schrieb: > Das passt schon und jetzt wissen wir noch immer nicht, was denn nun genau bei dir mit dem Ding abgeht oder eben nicht. W.S.
Zu viele Infos könnten das Volk verunsichern. Er schrieb, dass er Windows 7 verwendet, ohne einen Treiber installiert zu haben. Ich denke, dann ist klar, dass genau dies der Fehler ist. Mit dem Code und Treiber von ST läuft die gleiche Hardware ja. Sein Dankeschön kommt sicher später, wenn er es ans Laufen gebracht hat. Stimmt's Thorsten?
W.S. schrieb: > und jetzt wissen wir noch immer nicht, was denn nun genau bei dir mit > dem Ding abgeht oder eben nicht. Das brauchst du auch nicht zu wissen, da ich deinen Code nicht einsetze. Ich benutzt schon seit geraumer Zeit den Code von Niclas
Thomas Z. schrieb: > Ich benutzt schon seit geraumer Zeit den Code von Niclas Der kommt aber ursprünglich von W.S.. Sei mal nicht so pampig zu ihm, sondern freue dich, dass er als Autor hier seine Hilfe anbietet. Von Niklas hast du zu diesem Code eher keine Hilfe zu erwarten, außer die alt bekannte Kritik, dass er den Coding Style von W.S. scheußlich findet. Niklas hat den Code im Rahmen einer Diskussion überarbeitetet, um zu beweisen, dass er nicht nur meckern, sondern auch Fehler korrigieren kann. Pass auf, dass du da nicht zwischen die Fronten der beiden gerätst. Und verärgere sie nicht, denn wenn die zwei dir hier nicht helfen können, dann niemand.
Niclas hat den Code auf Github abgelegt, da kann man Issues erstellen und Fehler dann ordentlich verfolgen. Mal hier, mal da ein zip abzulegen ist Web 1.0 und eher verwirrend.
Nicht jeder möchte seinen veröffentlichten Code zu einem Lebenswerk machen, was Support-Aufwände angeht.
Stefan ⛄ F. schrieb: > Der kommt aber ursprünglich von W.S.. Sei mal nicht so pampig sondern > freue dich, dass der Autor hier seine Hilfe anbietet. > > Von Niklas hast du zu diesem Code eher keine Hilfe zu erwarten, außer > die Kritik, dass er den schrecklichen unverkennbaren W.S. Style hat. > Niklas hat ihn offenbar in überarbeiteter Version veröffentlicht, um zu > beweisen, dass er nicht nur meckern kann, sondern auch Fehler > korrigieren. Woher weißt du was ich einsetze? Ich brauche auch keine Hilfe dazu, weil der 3fach Uart von Niklas macht alles was ich brauche. Funktionen die ich zusätzlich brauche ändere ich mir passend ab. Falls ihr zwei das noch nicht bemerkt habt ich bin nicht der TO.
Stefan ⛄ F. schrieb: > sondern auch Fehler > korrigieren. Bin mir garnicht sicher, daß das ne Fehlerkorrektur war oder eher ein Mißverständnis. Aber jetzt habt ihr ja einen geänderten Treiber, wo man aus der Anwendung heraus sich um das Leeren des Ringpuffers kümmern muß - wenn ich das richtig verstanden habe. Also Lowlevel-Treiberinterna nach oben hin exportiert. Ist nicht mein Ding. Aber es kann natürlich ein jeder sich dranmachen und ändern wie es ihm gefällt - aber wenn es nicht so geht wie gedacht, dann nicht mit mir meckern. W.S.
Thomas Z. schrieb: > Woher weißt du was ich einsetze? Von deiner eigenen Aussage: Thomas Z. schrieb: > Ich benutzt schon seit geraumer Zeit den Code von Niclas Thomas Z. schrieb: > Ich brauche auch keine Hilfe dazu, weil > der 3fach Uart von Niklas macht alles was ich brauche. Junge, dann schreibe das auch! Was du hier abziehst grenzt echt an mutwilliger Verarschung. Die ganze Diskussion hier dreht sich um den Code von W.S., der sowohl von mir als auch von Niklas überarbeitet neu-veröffentlicht wurde.
Stefan ⛄ F. schrieb: > Von Niklas hast du zu diesem Code eher keine Hilfe zu erwarten Ich habe sogar schon Hilfe geboten: Niklas G. schrieb: > Du könntest das Board an einen Linux-PC anschließen Das ist eine sehr zielführende Herangehensweise. Wenn die einfach ignoriert wird, habe ich auch keine Lust beim Kaffeesatzlesen zu helfen. Stefan ⛄ F. schrieb: > Niklas hat den Code im Rahmen einer Diskussion überarbeitetet, > um zu beweisen, dass er nicht nur meckern, sondern auch Fehler > korrigieren kann. Wie du sicher weißt, habe ich schon diverse Projekte und Artikel online gestellt, aus denen ersichtlich sein sollte, dass "Meckern" nicht meine Kernkompetenz ist. Das Meckern ist nur die Antwort auf das persistente Von-Oben-Herab-Behandeln durch W.S. W.S. schrieb: > Bin mir garnicht sicher, daß das ne Fehlerkorrektur war oder eher ein > Mißverständnis. Ich mir aber. Ich habe deine Bugs, die du selber aufgrund deiner Verteufelung von Debuggern nicht finden konntest, mithilfe eines solchen Debuggers im Handumdrehen gefunden und behoben. W.S. schrieb: > Aber jetzt habt ihr ja einen geänderten Treiber, wo man > aus der Anwendung heraus sich um das Leeren des Ringpuffers kümmern muß Muss man nicht. Das macht der Treiber intern automatisch. Nur halt nicht in einem völlig zweckentfremdeten SOF-Interrupt.
Niklas G. schrieb: > Wie du sicher weißt, habe ich schon diverse Projekte und Artikel online > gestellt, aus denen ersichtlich sein sollte, dass "Meckern" nicht meine > Kernkompetenz ist. Das Meckern ist nur die Antwort auf das persistente > Von-Oben-Herab-Behandeln durch W.S. Ja ich weiß. An deiner Stelle hätte ich es auch dabei belassen. Ihr zwei braucht euch nicht zu einigen, habt ihr beide nicht nötig. Ich finde eure Werke beide hilfreich bin euch dafür dankbar.
Stefan ⛄ F. schrieb: > Junge, dass schreibe das auch! Was du hier abziehst grenzt echt an > mutwilliger Verarschung. Die ganze Diskussion hier dreht sich um den > Code von W.S., der sowohl von mir als auch von Niklas überarbeitet > neu-veröffentlicht wurde. Komm mal runter und schalte den Denkapparat vor dem Posten ein. Ich hatte nur genau 2 Posts hier gemacht. Zum einen hab ich einen Hinweis auf die Inf gegeben. Zum 2. hab ich angemerkt dass eine mA Angabe bei einem selfpowered Device nicht so sinnvoll ist. Die Angiffe kamen dann von dir. WS hat mich vermutlich einfach mit dem TO verwechselt. Also fass dich mal an der eigenen Nase.
Niklas G. schrieb: > Das Meckern ist nur die Antwort auf das persistente > Von-Oben-Herab-Behandeln durch W.S. Du hast nicht gemeckert du hast ihm seine Fehler aufgezeigt. Aber sowas verträgt W.S. nicht und wird dann pampig und noch unausstehlicher. Denn da könnte sein Dogma/Weltbild zusammenbrechen!
guckmal schrieb: > du hast ihm seine Fehler aufgezeigt. > Aber sowas verträgt W.S. nicht und wird dann pampig und noch > unausstehlicher. Wenn man das weiß, kann man die betroffene Person auch einfach mal in Ruhe lassen. Von solchen "Fehlern" bricht schließlich nicht die Welt zusammen. Mich macht ihr ja auch nicht wegen meiner Rechtschreibschwäche fertig.
Stefan ⛄ F. schrieb: > Mich macht ihr ja auch nicht wegen meiner Rechtschreibschwäche fertig. Du machst auch keine Leute von oben herab, sondern hilfst. W.S. hilft nicht, er predigt nur. Stefan ⛄ F. schrieb: > kann man die betroffene Person auch einfach mal in > Ruhe lassen. Wer in Ruhe gelassen werden will, der soll auch Andere in Ruhe lassen. Das ist eine ganz einfache Formel.
Ich wollte mich nur kurz melden, dass ich gestern und heute sehr viel um die Ohren hatte und frühestens morgen dazu komme, das Board an einen Windows 10 Rechner anzuschließen. W.S. schrieb: > Also, ihr beiden, was ist denn nun? Thorsten hätte ja auch mal etwas > genauer die Situation bei sich beschreiben können - außer nur "gar nicht > erkannt". Das ist ja noch 'vielsagender' als die Fehlermeldungen bei > Windows. Gar nicht erkannt trifft es schon auf den Punkt. Im Gerätemanager erscheint nichts. Aber ich teste jetzt wie gesagt erst mal an W10.
Läuft unter W10 anstandslos. Ich war wirklich fest davon ausgegangen, dass W7 einen default CDC Treiber mitbringt. Im Anhang eine INF Datei, um das unter W7 ans Laufen zu bekommen. Rechts-Klick auf die INF Datei und "Installieren" wählen. Der Treiber ist natürlich unsigniert. Dann Board anstecken. Bei mir kommt eine Fehlermeldung, keine Ahnung warum. Einfach auf "weiter, ok, jaja" klicken, dann läuft es. Im Terminalprogramm erscheint der "Hello World!" Text.
Na also, geht doch. Solche Rückmeldungen sind immer hilfreich für andere, die das später lesen.
Mir ist gerade noch ein Fehler in der INF Datei aufgefallen: CopyINF=win7-driver.inf "win7-driver.inf" war der ursprüngliche Dateiname. Ich hatte die Datei vor dem Hochladen noch für das Forum editiert. Der Dateiname muss angepasst werden, also: CopyINF=win7-blue-pill-driver.inf
Thorsten S. schrieb: > Im Anhang eine INF Datei, > um das unter W7 ans Laufen zu bekommen. Nochmal zum besseren Verständnis: soll das die Inf-Datei für die USB-Implementierung von W.S. sein?
Ja, die INF Datei ist für den WS/Stefan Frings Treiber. Die VID/PID lautet 0x0416 / 0x5011 und wird an mehreren Stellen in der INF Datei verwendet.
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.