Hallo ich habe ein Problem. Wenn ich auf mein STM32 Nucleo Board ein Programm drauf flashe funktioniert alles wie es sein soll solange ich die USB Verbindung zum PC nicht trenne. Wenn ich die USB Verbindung vom Board zum PC trenne und danach wieder verbinde läuft das Programm auf dem Board nicht mehr. Ich muss dann wieder das Programm nochmal über die IDE Workbench auf den Controller flashen damit es wieder läuft. Und nach dem Flashen läuft es so lange bis ich die USB Verbindung zum PC nicht trenne. Ich habe das Gefühl der Controller verliert nach dem Trennen der USB Verbindung das Programm. Meine Erwartung ist, der Controller sollte nach dem Trennen der USB Verbindung und wieder verbinden der USB Verbindung sich neu starten und weiter laufen.
Viktor schrieb: > Meine Erwartung ist, der Controller sollte nach dem Trennen der USB > Verbindung und wieder verbinden der USB Verbindung sich neu starten und > weiter laufen. Meine Erwartung ist, dass die Leute den Unterschied zwischen Debug Mode (Programm läuft nur mit angschlossener Debug Probe, da Breakpoints gesetzt sind und das Programm evtl sogar nur in den RAM geschrieben wird) und Release Mode (Programm läuft auch ohne Debug Probe, da fest im Flash ohne Breakpoints) kennen. mfg
:
Bearbeitet durch User
Es kann noch eine andere Ursache haben. Siehe unteren Link. Es hat was mit dem Nucleo onBoard ST-Link zu tun. http://www.openstm32.org/forumthread1831?forumId=7&comments_threshold=0&comments_parentId=1831&comments_offset=0&comments_per_page=25&thread_style=commentStyle_threaded
Felix F. schrieb: > Meine Erwartung ist, dass die Leute den Unterschied zwischen Debug Mode > (Programm läuft nur mit angschlossener Debug Probe, da Breakpoints > gesetzt sind Quatsch. Die Breakpoints verschwinden bei einem Power-Cycle. Lediglich Flash-Breakpoints bleiben bestehen, aber die Debugger die die unterstützen (zB JLink) löschen die auch wieder sofern man das nicht gerade hart abwürgt. > und das Programm evtl sogar nur in den RAM geschrieben > wird) Glaube nicht dass jemand "aus Versehen" das Linker-Script und den Startup-Code so ändert dass nur in den RAM geschrieben wird... Der Haupt-Unterschied zwischen Debug & Release sind die Optimierungen. Man kann auch Relase-Builds debuggen und Debug-Builds ohne Debugger ausführen.
Dr. Sommer schrieb: > Quatsch. Die Breakpoints verschwinden bei einem Power-Cycle. Lediglich > Flash-Breakpoints bleiben bestehen, aber die Debugger die die > unterstützen (zB JLink) löschen die auch wieder sofern man das nicht > gerade hart abwürgt. Es gibt Hardware UND Software Breakpoints. Die Software Breakpoints überschreiben den Code, damit ein Trap für den Debugger ausgelöst wird. Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger! Und sehr oft wird ein entsprechender Breakpoint am Einsprungspunkt (der Main) gesetzt. Dadurch starten viele Programme im Debug Modus nicht. Dr. Sommer schrieb: > Glaube nicht dass jemand "aus Versehen" das Linker-Script und den > Startup-Code so ändert dass nur in den RAM geschrieben wird... Meistens wird hier gar nichts umgestellt, da die meisten schon glücklich sind wenn ihr BlinkyLED läuft und deswegen sind sie auch falsch (für einen Release Build) Dr. Sommer schrieb: > Der Haupt-Unterschied zwischen Debug & Release sind die Optimierungen. UND die Einstellungen wie das Programm auf den Controller kommt! Am besten du schreibst lieber wieder Artikel in der Bravo ;) mfg
Felix F. schrieb: > Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger! Spannend. Und wie kommen die da hinein? Man schreibt jeden Breakpoint manuell über die "BKPT" Instruktion in den Code? Also ich mach das immer so: Ich setze in der IDE, während das Programm schon läuft, über GDB, Breakpoints. Die J-Link Software setzt automatisch die BKPT Instruktion in den Flash. Wenn ich die Debug-Session beende macht der J-Link das wieder rückgängig. Das erklärt, warum ich schon 1000x Debug-Builds geflasht, debuggt und abgebrochen habe, und sie danach immer noch funktioniert haben (ohne Debugger!). Felix F. schrieb: > Und > sehr oft wird ein entsprechender Breakpoint am Einsprungspunkt (der > Main) gesetzt. Dadurch starten viele Programme im Debug Modus nicht. Meine haben so immer funktioniert. Felix F. schrieb: > UND die Einstellungen wie das Programm auf den Controller kommt! Man kann sowohl Debug- als auch Release-Builds z.B. über den GDB oder auch direkt über ST-Link/J-Link Software flashen, das macht keinen Unterschied. Man kann sowohl Debug- als auch Release-Builds in den RAM oder Flash schreiben. Florian F. schrieb: > Wie steht denn Boot0? Das ist mal ein sinnvoller Hinweis...
Dr. Sommer schrieb: > Spannend. Und wie kommen die da hinein? The way software breakpoints work is fairly simple. Speaking about x86 specifically, to set a software breakpoint, the debugger simply writes an int 3 instruction (opcode 0xCC) over the first byte of the target instruction. This causes an interrupt 3 to be fired whenever execution is transferred to the address you set a breakpoint on. When this happens, the debugger “breaks in” and swaps the 0xCC opcode byte with the original first byte of the instruction when you set the breakpoint, so that you can continue execution without hitting the same breakpoint immediately. http://www.nynaeve.net/?p=80 mfg
Hmmm... Du widersprichst Dir selbst. Felix F. schrieb: > Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger! Felix F. schrieb: > the debugger simply writes > an int 3 instruction (opcode 0xCC) over the first byte of the target > instruction. Was denn nun? Schreibt's nun der Debugger oder was anderes? Wenn letzteres bleibt die Frage von Dr. Sommer bestehen.
Martin H. schrieb: > Hmmm... Du widersprichst Dir selbst. > > Felix F. schrieb: >> Und diese Breakpoints sind IMMER im Programm, auch ohne Debugger! > > Felix F. schrieb: >> the debugger simply writes >> an int 3 instruction (opcode 0xCC) over the first byte of the target >> instruction. > > Was denn nun? Schreibt's nun der Debugger oder was anderes? Wenn > letzteres bleibt die Frage von Dr. Sommer bestehen. Der Debugger überschreibt das erste Byte und flasht dann diesen Code. Somit wird immer der "falsche" Code ausgeführt, der erst durch den Debugger korrigiert wird. Was ist daran nicht zu verstehen? Ein "netter" Nebeneffekt ist dabei, dass zum auswechseln von diesem Code die Pipeline des Prozessors geleert werden muss, wodurch sich die Performance verschlechert, wenn auch nur um wenige Cycles. mfg
:
Bearbeitet durch User
Mitlesa schrieb: > Felix F. schrieb: >> Speaking about x86 specifically, > > Ohne weitere Worte. Für die ungebildeten Trolle hier nochmal explizit für ARM: Software instruction breakpoints For processors that do not support hardware instruction breakpoints, or in cases where you have used up all the available hardware breakpoint resources, you can use software instruction breakpoints. Software breakpoints modify the instruction in memory to create a special value that causes the processor to enter debug state when executed. The value written to memory depends on the processor you are using. For ARM processors, one of the following schemes is used, depending on the architecture and processor revision: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0498b/CHDFFICJ.html mfg
Felix F. schrieb: > Der Debugger überschreibt das erste Byte und flasht dann diesen Code. > Somit wird immer der "falsche" Code ausgeführt, der erst durch den > Debugger korrigiert wird. Was ist daran nicht zu verstehen? Aha, der Debugger macht das! D.h. wenn ich das Debug-Binary direkt flashe (ohne Debugger) sind keine Breakpoints drin? D.h. das hat nichts mit Debug/Release-Build zu tun? (q.e.d) Und welcher Debugger macht so etwas, und räumt nicht hinter sich wieder auf, d.h. ersetzt das BKPT nicht wieder durch die richtige Anweisung? Der J-Link tut das jedenfalls, und der ST-Link kann IIRC sowieso keine Flash-Breakpoints.
Dr. Sommer schrieb: > Aha, der Debugger macht das! D.h. wenn ich das Debug-Binary direkt > flashe (ohne Debugger) sind keine Breakpoints drin? D.h. das hat nichts > mit Debug/Release-Build zu tun? (q.e.d) Deshalb sprach ich auch vom Debug MODE, wo das Binary Debugger-freundlich geflasht wird, deshalb auch DEBUG MODE! Dr. Sommer schrieb: > Und welcher Debugger macht so etwas Keiner, aber im DEBUG MODE teilt es die IDE dem Debugger mit, dass er es so machen soll! Hast du überhaupt eine Ahnung wie so ein Debug-Prozess funktioniert?? mfg
Ah, jetzt werden wir freundlich. Ich kenne lediglich deine Wort-Definition von Debug-Mode vs. Release-Mode nicht. Alle mir bekannten IDE's nutzen das als Unterscheidung ob ohne bzw. mit Optimierungen und Debug-Informationen kompiliert wird (also z.B. ob -g -O0 oder -Os -DNDEBUG an den GCC übergeben wird). Was ist denn "Debugger-Freundliches" Flashen? Ich übergebe an den JLink.exe die Option -Freundlich? Und wenn ich die nicht übergebe, funktionierten die Breakpoints ja anscheinend trotzdem (nach meinem üblichen Vorgehen). Woher weiß der Debugger beim Debugger-Freundlichen Flashen überhaupt, wo welche Breakpoints sind? Die kommen doch erst nachher z.B. über den GDB-Server. Felix F. schrieb: > Keiner, aber im DEBUG MODE teilt es die IDE dem Debugger mit, dass er es > so machen soll! Und wie? Ich hab beim JLinkGDBServer.exe noch keine Option -BehalteFlashBreakpoints gesehen. Noch habe ich jemals so ein Verhalten beobachtet (wäre ja, wie wir sehen, völlig Banane). Felix F. schrieb: > Hast du überhaupt eine Ahnung wie so ein Debug-Prozess funktioniert?? Du anscheinend auch nicht. Zeige doch bitte mal ein reproduzierbares Vorgehen mit J-Link oder ST-Link, wo du nirgends im Code "BKPT" nutzt, aber dennoch Flash-Breakpoints im Controller übrig bleiben (sauberes Beenden vorausgesetzt, kein rabiates Trennen der Stromversorgung/JTAG-Leitung).
Dr. Sommer schrieb: > Zeige doch bitte mal ein reproduzierbares Vorgehen mit J-Link oder > ST-Link, wo du nirgends im Code "BKPT" nutzt, aber dennoch > Flash-Breakpoints im Controller übrig bleiben (sauberes Beenden > vorausgesetzt, kein rabiates Trennen der Stromversorgung/JTAG-Leitung) Ich hab auf Keil dazu sogar einen Artikel gefunden: The standard runtime library links in certain low-level debugging routines, i.e. semihosting functions. Legacy ARM emulators supported semihosting by responding to the SWIs and BKPTs events. For the non-debug (released) version of the application, a programmer would retarget these semihosting functions to non-semihosting equivalents. http://www.keil.com/support/docs/3614.htm Und jetzt habe ich keine Lust mehr mit einem Troll zu diskutieren, der nicht mal die einfachsten Dinge googlen kann und gut gemeinte Ratschläge mit seinem völlig falschem Halbwissen aufwiegt. Manche sind halt leider unbelehrbar.... mfg
Felix F. schrieb: > The standard runtime library links in certain low-level debugging > routines, i.e. semihosting functions. Gut erkannt. Da steht was von "linken". Nicht davon, wie geflasht/debuggt wird. Es gibt nämlich schlicht und ergreifend kein Debug/Release-Mode für den Debugger. In dem Artikel geht es um Semihosting, nicht um Breakpoints. Schlaue Implementierungen funktionieren auch ohne Debugger. Und normalerweise merkt man es auch, wenn man Semihosting aktiviert hat... Felix F. schrieb: > Und jetzt habe ich keine Lust mehr mit einem Troll zu diskutieren, der > nicht mal die einfachsten Dinge googlen kann und gut gemeinte Ratschläge > mit seinem völlig falschem Halbwissen aufwiegt. Manche sind halt leider > unbelehrbar.... Ah, wenn man widerlegt wurde bezeichnet man den anderen einfach als Troll! Also ich arbeite schon einige Jahre mit STM32 und habe auch schon viel debuggt und geflasht sowie mich mit den Details der Toolchain auseinander gesetzt. Ich habe im JLink Manual noch keine -Freundlich Option gefunden und auch noch nie gesehen, dass Flash-Breakpoints im Controller verbleiben. Statt zu Flamen könntest du ja einfach zeigen wo dein "Debugger-freundlich"-Modus herkommt!
Habe ich es hier schon mal erwähnt: ST-Link updaten ! "Both Nucleo 64 boards ( F401RE and L476RG ) are working now as they are expected ( from my side ;) ) The problem of the F401RE with the "mass storage download" was an on-board ST-LINK V2 proplem: I had to update it with the "STM32 ST-LINK Utility" then it was working correct."
Dr. Sommer schrieb: > Ah, wenn man widerlegt wurde bezeichnet man den anderen einfach als > Troll! Was hast du denn widerlegt kleiner Sommertroll?? Im gegensatz zu dir hinterlege ich meine Aussagen mit vernünftigen Quellen. Von dir kam nur heiße Luft, und davon gibt es aktuell schon genung... Dr. Sommer schrieb: > Gut erkannt. Da steht was von "linken". Nicht davon, wie > geflasht/debuggt wird. Es gibt nämlich schlicht und ergreifend kein > Debug/Release-Mode für den Debugger. > In dem Artikel geht es um Semihosting, nicht um Breakpoints. Schlaue > Implementierungen funktionieren auch ohne Debugger. Und normalerweise > merkt man es auch, wenn man Semihosting aktiviert hat... Seit wann geht es hier um Breakpoints?? Es geht hier darum, dass das Programm nicht startet und da kann Semihosting genauso schuld sein. Breakpoints waren nur mein erster Einfall. Also lenke nicht schon wieder vom Thema ab! Dr. Sommer schrieb: > Also ich arbeite schon einige Jahre mit STM32 und habe auch schon viel > debuggt und geflasht sowie mich mit den Details der Toolchain > auseinander gesetzt. Ich habe im JLink Manual noch keine -Freundlich > Option gefunden und auch noch nie gesehen, dass Flash-Breakpoints im > Controller verbleiben. Statt zu Flamen könntest du ja einfach zeigen wo > dein "Debugger-freundlich"-Modus herkommt! Die Segger Toolchain ist doch ein Abklatsch von Crossworks. Also eine All-in-One IDE für Leute ohne wirklich Ahnung, da prinzipiell alles geregelt wird, deshalb funktioniert es auch bei dir tadellos. Und hier sieht man auch, dass du dich eben nicht mit dem ganzen Debug-Prozess befasst hast, sondern nur Knöpfchen auf vorgefertigten IDEs drücken kannst. Markus schrieb: > Habe ich es hier schon mal erwähnt: ST-Link updaten ! > > "Both Nucleo 64 boards ( F401RE and L476RG ) are working now as they are > expected ( from my side ;) ) > The problem of the F401RE with the "mass storage download" was an > on-board ST-LINK V2 proplem: I had to update it with the "STM32 ST-LINK > Utility" then it was working correct." Das wird dem TE nichts bringen! Er muss sein Programm korrekt flashen! mfg
:
Bearbeitet durch User
Felix F. schrieb: > Im gegensatz zu dir > hinterlege ich meine Aussagen mit vernünftigen Quellen. Von dir kam nur > heiße Luft, und davon gibt es aktuell schon genung... ALso hier nochmal schriftlich: https://www.segger.com/downloads/jlink/UM08001_JLink.pdf Hier ist das User Manual vom J-Link. Ich finde da kein "Debugging-Freundliches" Flashen. Dass die Breakpoints automatisch wieder gelöscht werden steht da leider tatsächlich nicht, aber das kann man ja leicht ausprobieren. Zeige du doch mal eine Quelle, wo der "Debug/Release-Mode" beim Debuggen dokumentiert ist. Felix F. schrieb: > Seit wann geht es hier um Breakpoints?? Seit deinem 1. Beitrag: Felix F. schrieb: > (Programm läuft nur mit angschlossener Debug Probe, da Breakpoints > gesetzt sind Felix F. schrieb: > Es geht hier darum, dass das > Programm nicht startet und da kann Semihosting genauso schuld sein. Das kann wirklich sein. Aber das hat wenn schon was mit Debug/Release-Builds zu tun (Quelle hast du ja selbst gefunden), und nicht mit Debug/Relase "Debugging Modes", den es nicht gibt (siehe JLink-Manual). Felix F. schrieb: > deshalb funktioniert es auch bei dir tadellos Die benutze ich überhaupt nicht. Felix F. schrieb: > Und hier > sieht man auch, dass du dich eben nicht mit dem ganzen Debug-Prozess > befasst hast, sondern nur Knöpfchen auf vorgefertigten IDEs drücken > kannst. Woher weißt du das jetzt wieder? Ich arbeite zwar meistens mit eclipse, aber ich habe auch schon direkt auf der Konsole mit JLinkGDBServer, arm-none-eabi-gdb und GCC gearbeitet und auch mit den ST-Link-Äquivalenten und weiß daher durchaus wie das funktioniert. Da gibt es jedenfalls keine Option für Debugging-Freundliches Flashen.
Dr. Sommer schrieb: > ALso hier nochmal schriftlich: > https://www.segger.com/downloads/jlink/UM08001_JLink.pdf > Hier ist das User Manual vom J-Link. Ich finde da kein > "Debugging-Freundliches" Flashen. > Dass die Breakpoints automatisch wieder gelöscht werden steht da leider > tatsächlich nicht, aber das kann man ja leicht ausprobieren. > > Zeige du doch mal eine Quelle, wo der "Debug/Release-Mode" beim > Debuggen dokumentiert ist. Da ein Nucleo Board einen ST-Link eingebaut hat, sind diese Infos ziemlich wertlos. An Umschreibungen wie "Debug-freundlich" ziehen sich übrigens nur Sommertrolle auf ;) Dr. Sommer schrieb: > Seit deinem 1. Beitrag: Hier gehts aber um den 1. Beitrag des TEs, und da geht es um "nicht starten". Dr. Sommer schrieb: > Das kann wirklich sein. Aber das hat wenn schon was mit > Debug/Release-Builds zu tun (Quelle hast du ja selbst gefunden), und > nicht mit Debug/Relase "Debugging Modes", den es nicht gibt (siehe > JLink-Manual). Debug-Build + Grüner Pfeil = Debugging Mode = Mit Debug-Informationen modifiziertes Programm = im Normalfall nicht ohne Debugger lauffähig Zum 2. mal: JLink ist hier völlig uninteressant das ST-Link Dr. Sommer schrieb: > Debugging-Freundliches Flashen. Sommertroll?? Ich bleibe dabei, der TE hat einen Debug-Build erzeugt und hat dann eine Debug-Session gestartet, die einen Debugger zur Ausführung benötigt. Evtl. ist das Programm auch im RAM gelandet. mfg
Felix F. schrieb: > An Umschreibungen wie "Debug-freundlich" ziehen sich > übrigens nur Sommertrolle auf ;) Dann erläutere doch mal, was du damit eigentlich meinst. Das bist du uns bis jetzt schuldig geblieben. Du erzählst von Funktionen eines Debuggers die einfach nicht existieren, und wenn man nachbohrt wirfst du nur noch mit Beleidigungen um dich. Top Diskussionverhalten. Felix F. schrieb: > Hier gehts aber um den 1. Beitrag des TEs, und da geht es um "nicht > starten". Jaja, jetzt noch schnell Rückzieher machen und den eigenen Unfug als unwichtig wegwischen. Felix F. schrieb: > Debug-Build + Grüner Pfeil = Debugging Mode = Mit Debug-Informationen > modifiziertes Programm = im Normalfall nicht ohne Debugger lauffähig Die Debug-Informationen landen überhaupt nicht im Flash, sondern nur in der ELF-Datei. Im Allgemeinen ist das sehr wohl lauffähig (viele Programme sind sogar nur so lauffähig, weil die Leute nichtdefiniertes Verhalten von C/C++ ausnutzen welches im Release-Modus des Compilers kaputtoptimiert wird). Nur wenn man eine dumme Semihosting-Implementation nutzt, evtl nicht. Felix F. schrieb: > Ich bleibe dabei, der TE hat einen Debug-Build erzeugt und hat dann eine > Debug-Session gestartet, die einen Debugger zur Ausführung benötigt. Das hat auch niemand bezweifelt. Felix F. schrieb: > Sommertroll?? Damit hast DU angefangen, ohne es belegen zu können! Wenn du nicht diskutieren möchtest, schreibe vielleicht einfach keine frei erfundenen Fakten?
Dr. Sommer schrieb: > Die Debug-Informationen landen überhaupt nicht im Flash, sondern nur in > der ELF-Datei. OK, hier habe ich mich wirklich falsch ausgedrückt. Es sind keine Debug-Infos im Code, sondern nur Modifizierungen im Code die dann z.B. Traps, Interrupts etc. auslösen, die dann der Debugger auffängt und verarbeitet. Dr. Sommer schrieb: > Du erzählst von Funktionen eines Debuggers > die einfach nicht existieren, und wenn man nachbohrt wirfst du nur noch > mit Beleidigungen um dich. Top Diskussionverhalten. Softwareinterrupts und Traps zur Behandlung von Breakpoints und Interrupts sind z.B. solche Funktionen. Wie soll der Debugger sonst debuggen? mfg
:
Bearbeitet durch User
Felix F. schrieb: > Debug-Build + Grüner Pfeil = Debugging Mode Du kennst dich also auch nur mit bunten Knöpfen aus und weißt nicht was im Hintergrund passiert ;-)
Felix F. schrieb: > Softwareinterrupts und Traps zur Behandlung von Breakpoints und > Interrupts sind z.B. solche Funktionen. Wie soll der Debugger sonst > debuggen? Diese Funktion ist im Debugger aber immer aktiv. Dazu braucht es keinen "Debug-MODE", wie du es behauptest: Felix F. schrieb: > Deshalb sprach ich auch vom Debug MODE, wo das Binary > Debugger-freundlich geflasht wird, deshalb auch DEBUG MODE! Und diese Funktionen werden, wie gesagt, bei sauberer Beendigung der Session wieder deaktiviert. Sind daher nicht Grund für das Problem. Ich habe vorhin die JLink Doku bemüht weil der ST-Link ja keinen eigenen GDB-Server mitbringt. Aber du darfst gerne auch im Manual vom ST-Link oder der zugehörigen GDB-Server von texane/OpenOCD/Atollic den sagenumwobenene "Debug MODE" zeigen.
Hallo Leute, danke für die vielen Vorschläge. Ich habe Gestern das Problem gefunden. Es gibt einen Bug im onBoard ST-Link auf dem Board Nucleo F401RE. Man muss nur den OnBoard ST-Link updaten und das Problem verschwindet danach. Das Problem hatte nichts mit Debug oder Release Mode zu tun gehabt. Ich habe auch alle Einstellungen im Workbench so gelassen wie die waren und nach dem Update des OnBoard ST-Link verschwand das Problem. Ich habe den OnBoard ST-Link über das Programm ST-LINK Utility geupdatet.
Viktor schrieb: > Es gibt einen Bug im onBoard ST-Link auf dem Board Nucleo F401RE. > > Man muss nur den OnBoard ST-Link updaten Hallo Viktor, hast Du evtl. einen Link dazu?
>Man muss nur den OnBoard ST-Link updaten und das Problem verschwindet >danach. Das habe ich hier in diesem Thread schon zwei mal geschrieben, aber Ihr wolltet euch ja lieber streiten ...
Können wir uns drauf einigen, dass Felix F. offensichtlich Keil (uVision ?) verwendet, bei dem im "Debug-Mode" wohl ein immer Software-Breakpoint eingebaut wird (von wem auch immer) und das resultierende Binary nicht ohne Debugger lauffähig ist? Der vermutlich deutlich größere Teil der Forumsteilnehmer wird irgendwas auf eclipse und gcc basierendes benutzen, bei dem der "Debug Mode" lediglich die Compiler-Settings beeinflusst. Das resultierende Binary ist uneingeschränkt verwendbar.
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.