Hallo zusammen, ich habe ein Problem und dazu möchte ich euch befragen: Ich habe eine größere Anzahl ATMEGA328 über einen Batchjob geflasht. Dabei wurde wohl beim Aufruf von AVRDUDE.exe in der Batchdatei der BitClock auf 1 gesetzt. Das heist ja 1uS "Verzögerung" beim Flashen. Die Clock-Fuses die vor dem Flash programmiert werden, stehen auf "int. RC 8MHz 6CK/14CK +65msec" Bei 8MHz sollte die BitClock doch kleiner (8MHz * (1/4)) sein also kleiner 2 MHz. 2MHz = 0,5usec Bitclock 1 usec wäre größer. Jetzt sind ein paar Controller ausgefallen. Das Produkt startete und während des Tests stellte es seinen Betrieb ein. Der Bootloader macht beim Starten eine CRC-Prüfung des Flash, diese muss zu diesem Zeitpunkt iO gewesen sein, sonst wäre die Application nicht los gelaufen. Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen. Die Lock-Bits sind gesetzt, aber unser Bootloader bietet die Möglichkeit das Flash Pageweise zu lesen. Fuses: set lfuse=0xE2 set hfuse=0xCC set efuse=0xFC set lock=0x2C Meine Fragen wären: - Kennt jemand das Problem? - kann das am "zu schnellem" Bit-Clock beim Flashen des FLASH liegen? - die Controller die jetzt noch gehen, kann man sich drauf verlassen, dass der Inhalt nicht auch irgendwann umkippt - Würde neu Flashen mit langsameren Bit-Clock das Problem lösen? Oder kann es sein dass das Flash dauerhaft geschädigt ist! Zusatzinfo: - Das Produkt läuft schon seit Jahren ohne Probleme. - Vorher wurde aber mit STK500.exe geflasht und auch langsamer - Programmer ist ein AVR MKII Clone (Diamex All AVR) - Verify beim Flashen ist "on" - Versorgung des Prüflings beim Flashen über Programmer an versorgten USB-Hub Anbei auch die komplette Batchdatei! zum Thema habe ich nur folgende Artikel gefunden: Beitrag "Atmega 1284p verliert Programm" (nicht passend) Beitrag "Atmega8 verliert Programmierung" (nicht passend) Beitrag "Probleme mit AVRdude - Linux" (INFOS zum Bitclock) Gruß und Danke allen schon mal Robert Hoffmann - KEE4 -
Robert H. schrieb: > Bei 8MHz sollte die BitClock doch kleiner (8MHz * (1/4)) sein also > kleiner > 2 MHz. 2MHz = 0,5usec Bitclock 1 usec wäre größer. Aber das passt doch. -B 1 entspricht ja 1 µs = 1MHz, das ist kleiner als 2MHz.
Beitrag #6346331 wurde vom Autor gelöscht.
Robert H. schrieb: > - kann das am "zu schnellem" Bit-Clock beim Flashen des FLASH liegen? > - die Controller die jetzt noch gehen, kann man sich drauf verlassen, > dass der Inhalt nicht auch irgendwann umkippt Soweit mir bekannt ist für das Schreiben der interne Takt zuständig, nicht der ICSP Takt. Bisher habe ich von noch keiner Methode gehört, wie man den Flash Speicher schwächen kann, außer durch Temperatur. ------ Robert H. schrieb: > set lock=0x2C Sagt das Datenblatt nicht dazu: > Further programming and verification of the Flash and EEPROM > is disabled in Parallel and Serial Programming mode. The Boot > Lock bits and Fuse bits are locked in both Serial and Parallel > Programming mode. Damit ist dann diese aussage hinfällig, oder? Robert H. schrieb: > Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen.
Hallo zusammen, danke schon mal für die Antworten. AdamP) so seh ich es auch, die Geschwinigkeit liegt innerhalb der Specs OliverSo) > Specify the bit clock period for the JTAG interface or the ISP clock (JTAG ICE only) + Hier verstehe ich das sich "(JTAG ICE only)" auf "Specify the bit clock period for the JTAG interface" bezieht. + "or the ISP clock" bezieht sich für mich auf ISP-Programmer an der SPI-Schnittstelle Richtig: Der DIAMEX ist ein "SPI-Programmer" Gruß KEE4
Robert H. schrieb: > - Versorgung des Prüflings beim Flashen über Programmer an versorgten > USB-Hub Wie gut und stabil ist diese Versorgung? > Fuses: > set efuse=0xFC Ist der BrownOut bei den defekten Controllern noch aktiv? > Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen. So wie dort? https://electronics.stackexchange.com/questions/116607/avr-flash-memory-corruption
Ich glaube nicht, dass ganze Pages einfach so umkippen und sich selbst löschen. Ich glaube eher, dass der Bootloader sie gelöscht hat. Wie schwer ist es, den Bootloader an die Codestelle springen zu lassen, die Pages löscht? Welche Bedingungen sind nötig? Sind noch Codefehler drin? Ist Brownout an?
Robert H. schrieb: > OliverSo) >> Specify the bit clock period for the JTAG interface or the ISP clock (JTAG ICE > only) > + Hier verstehe ich das sich "(JTAG ICE only)" auf "Specify the bit > clock period for the JTAG interface" bezieht. > + "or the ISP clock" bezieht sich für mich auf ISP-Programmer an der > SPI-Schnittstelle Ja, daher hatte ich meinen Beitrag dann auch wieder gelöscht. Wenn allerdings das den Verify nach dem Programmieren erfolgreich durchlaufen hat, und der bootloader CRC auch noch durchläuft, dann irgendwann später aber einzelne Pages gelöscht sind, dann wäre der offensichtlichste Kandidat dafür eben jener bootloader. Herauszufinden, warum der das macht, ist jetzt dein Job. Das du die Brown-out Fuse passend gesetzt und sonstige Probleme mit der Spannungsversorgung etc. ausgeschlossen hast, setzte ich jetzt einfach mal voraus. https://electronics.stackexchange.com/questions/116607/avr-flash-memory-corruption Oliver
:
Bearbeitet durch User
Hallo Robert Hast du die Möglichkeit deine Applikation ohne Bootloader zu testen. Vielleicht ist es ja ein Fehler im Bootloader. Gruß Rolf
> Vielleicht ist es ja ein Fehler im Bootloader.
Das wuerde ich auch denken. Ich hatte vor vielen Jahre auch mal ein
Problem mit einem MCS51 Derivat von Atmel. Das wurde gelegentlich mit zu
geringer Spannung gestartet (Rueckspeisung eines Motors der bewegt wurde
uns so als Generator lief). Darauf hat dann der Bootloader von Atmel der
im Prozessor integriert ist gelegentlich zufaellig eine Page im Flash
geloescht. Und das sogar wenn man den Resetpin dauerhaft auf Reset
kurzgeschlossen hat.
Jetzt hast du natuerlich einen anderen controller aber immerhin auch von
Atmel.
Olaf
Rolf D. schrieb: > Vielleicht ist es ja ein Fehler im Bootloader. Ich würde im Bootloader einen Schutz einbauen, damit die SPM-Routine nicht versehentlich von einem wilden Pointer aufgerufen wird. Z.B. ein Enable-Kommando schreibt ein 4 Byte-Pattern in dem RAM und die SPM-Routine prüft es. Wenn alle SPM-Aufrufe in einer Funktion erfolgen, kann man auch den SP prüfen, ob er genau diesen Level hat.
Beim EEPROm weiß ich mit Sicherheit, dass sogar Lesezugriffe den Speicherinhalt zerstören können, wenn die Versorgungsspannung instabil oder zu gering ist. Da Flash Speicher vermutlich nicht viel anders funktioniert, kann ich mir vorstellen, dass Flash da ebenfalls empfindlich reagiert.
Und ich weiß, dass es eine BOD Fuse gibt! Ganz sicher! Also: Wer die BOD Fuse "ausblendet" WILL Probleme.
Gerade was die Versorgungsspannung während des programmieren angeht kenne ich auch solche Fälle. Anderer uC Hersteller, aber gleiches Problem.
Arduino Fanboy D DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE! Arduino Fanboy D. schrieb: > Soweit mir bekannt ist für das Schreiben der interne Takt zuständig, > nicht der ICSP Takt. Aha: Daher darf BitClock maximal 1/4 der Oszillator-Frequenz sein! >> set lock=0x2C > Sagt das Datenblatt nicht dazu: > Further programming and verification of the Flash and EEPROM is disabled >> Damit ist dann diese aussage hinfällig, oder? > Eine Analyse ergab, dass einige Pages des Flash auf 0xFF stehen. Passiert mir auch ständig, dass ich antworte ohne alles verstanden zu haben: Unser Bootloader bietet die Möglichkeit die Pages zu lesen > Und ich weiß, dass es eine BOD Fuse gibt! Ich auch > Ganz sicher! Da bin ich mir auch sicher > Wer die BOD Fuse "ausblendet" WILL Probleme. Ich will aber keine Probleme, deßwegen ist die "Extended Fuses" 0x2C und somit ist BrownOut auf 4.3V gesetzt! DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE! Mfg
:
Bearbeitet durch User
Robert H. schrieb: > ist die "Extended Fuses" 0x2C und somit ist BrownOut auf 4.3V gesetzt! Ich frage zur Sicherheit einfach nochmal: hast du das bei den korrupten Controllern kontrolliert?
Hallo Lothar, vielen Dank für deine Antwort und für's Nachbohren!!! In meiner Batchdatei wird zwar eine Variable gesetzt: set efuse=0xFC Aber im Aufruf von AVRDude.exe wurde diese Variable nicht als Parammeter übergeben. Daher wurden bei allen Boards die Extended-Fuses nicht programmiert. SUPER - Danke für die Hilfestellung - die hat uns weiter gebracht! Allen anderen auch Danke die uns auf das Verhalten bei nicht eingeschalteten BrownOut hingewiesen haben. Das wäre unserer nächster Ansatzpunkt der Analyse gewesen. Ursache war, die Batchdatei AVRDuder.bat wurde von einem ATM16 Projekt übernommen und der hat ja kein BrownOut. Unser 4-fach-Gang-Programmer wurde von STK500.exe (AVRStudio) auf AVRDude umgestellt, da Mikisoft nach 28 Tagen die Ausführung von STK500.exe unter WIN10 ohne irgend einen Hinweis unterbunden hat. Leider lässt sich AVRDude trotz aller Versuche auch nur einmal zweitgleich starten! Wen es interssiert: Beitrag "STK500 aus AVRStudio unter WIN10 ging und jetzt plötzlich nicht mehr" und Beitrag "Re: STK500 aus AVRStudio unter WIN10 ging und jetzt plötzlich nicht mehr" DANKE Lothar Danke allen Gruß Robert
:
Bearbeitet durch User
Hi >Ursache war, die Batchdatei AVRDuder.bat wurde von einem ATM16 Projekt >übernommen und der hat ja kein BrownOut. Wenn du mit ATM16 den ATMega16 meinst. Der hat natürlich einen BOD. MfG Spess
Hallo spess53, Danke - hier waren die Finger schneller als der Kopf: Ich meinte "hat keine ExtenedFuse für's BrownOut" Danke
:
Bearbeitet durch User
Robert H. schrieb: > DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE! Gerne doch! Robert H. schrieb: > Aha: Daher darf BitClock maximal 1/4 der Oszillator-Frequenz sein! Schaue Datenblatt, und du wirst sehen, dass beides Wahr ist. 1. Es gibt die klare von dir genannte Anforderung für den ISP Takt. 2. Flash benötigt den internen Taktgenerator. Nachweis für Punkt 2: http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf Figure 9-1. Clock Distribution Merke: Verstelle den OSCAL Value auf absurde Werte und dein Flash+EEPROM schreiben wird versagen. Da kannst du so viele Quarze einbauen und nutzen, wie du willst. Zu finden, da im Datenblatt, wo auch OSCAL und der Speicher erklärt wird. (das findest du selber, wenn du die Augen aufmachst) Robert H. schrieb: > Passiert mir auch ständig, dass ich antworte ohne alles verstanden zu > haben Offensichtlich! Selbst nach Hinweis auf die Böcke, welche du schießt, hältst du es für wichtiger über andere zu urteilen, als ins Datenblatt zu schauen, oder in dich zu gehen. Das ist in gewisser Weise recht armselig, oder? Robert H. schrieb: > Ich will aber keine Probleme, deßwegen ist die "Extended Fuses" 0x2C und > somit ist BrownOut auf 4.3V gesetzt! .... > Daher wurden bei allen Boards die Extended-Fuses nicht > programmiert. Du siehst! Aber: Immerhin ein Hauch von Einsicht. Etwas spät, aber immerhin. Robert H. schrieb: > DANKE FÜR DIE QUALIFIZIERTEN BEITRÄGE! Und ich danke dir dafür, dass du mir vor Augen geführt hast wie boniert und abgehoben du sein kannst. Denn auf dieser Liste stehst du jetzt bei mir. Auf der Liste derjenigen, die lieber erst den Boten töten, bevor sie sich den Problemen stellen. Merke dir: Die meisten, welche versucht haben mich zum Idioten abzustempeln, durften danach irgendwann feststellen, dass sie selber, die noch viel größeren sind. In dem Punkt, hast du auch, eine feine Vorstellung abgeliefert.
Arduino Fanboy D. schrieb: > In dem Punkt, hast du auch, eine feine Vorstellung abgeliefert. Eines zum Nachdenken: du hast zwar völlig Recht gehabt. Aber der Witz ist: der Ton macht die Musik (ich weiß das, ich mache solche). Und wenn du dann falschen Ton anschlägst oder ihn zu derb anschlägst, dann hören die Leute halt einfach nicht mehr zu, auch wenn das Lied insgesamt noch erkennbar ist. Ich habe mit knapp 30 Worten (von denen gut die Hälfte für blumige Umschreibungen herhalten mssten) genaus das bewirkt, was ich wollte: dass Robert H. mal kontrolliert, ob seine Annahme mit den programmierten Fuses schon passt. > In dem Punkt, hast du auch, eine feine Vorstellung abgeliefert. Glashaus... ;-) Wie auch immer, der grundlegende Mechanismus für korrumpiertes Flash und EEPROM ist reine Hardware, völlig unabhängig vom Code(!) oder Bootlader oder sonstwas, auch wenn das irgendwie immer angenommen wird: irgendein Register/Flipflop im µC schaltet die Ladungspumpe ein, die zum Löschen des aktuellen Flash-Blocks bzw. der aktuellen EEPROM-Zelle benötigt wird. Normalerweise wird dieses Flipflop vom Ablauf der internen Programmierungs-FSM gesteuert. Allerdings können diese beiden Flipflops natürlich durch äussere Zustände wie z.B. eine zu niedrige Spannung selber ihren Zustand ändern. Und beim BrownOut durch eine "langsam" fallende Versorgung passiert es, das irgendwann das Bit "umkippt", die restliche Spannung aber reicht, noch die Ladungspumpe zu starten, die dann so lange läuft, dass mindestens noch einzelne Bits im Flash/EEPROM auf '1' gelöscht werden ("langsam" deshalb in Anführungszeichen, weil ja schon ein paar ms zum Löschen von Flash/EEPROM ausreichen). Und das passiert an der Stelle, an der der Schreibpointer aktuell steht. Blöderweise besteht der Pointer auch aus Flipflops, die ihrerseits wegen der fallenden Spannung irgendwie (am eheseten in Richtung '0', weil die Spannung ja sinkt) umkippen können. Das war dann auch der Grund, warum die EEPROM-Zelle an Adresse 0 am ehesten betroffen war. Und weil das Ganze auch von irgendwelchen internen Fertigungstoleranzen abhängt, "funktionieren" ein paar µC auch ohne BOD problemlos, weil dann zwar das "Einschalt-Flipflop" umkippt, die Ladungspumpe aber wegen zu niedriger Spannung nicht mehr anläuft. Glück gehabt!
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und weil das Ganze auch von irgendwelchen internen Fertigungstoleranzen > abhängt, "funktionieren" ein paar µC auch ohne BOD problemlos, weil dann > zwar das "Einschalt-Flipflop" umkippt, die Ladungspumpe aber wegen zu > niedriger Spannung nicht mehr anläuft. Glück gehabt! Ich würde eher sagen "Pech gehabt", denn dann merkt man das erst irgendwann später beim Bau weiterer Geräte oder anderen Umgebungsbedingungen oder oder oder... Und dann denkt man an sowas kaum, denn "es hat ja die ganze Zeit funktioniert, es kann also kein grundsätzlicher Design-Fehler sein".
Lothar M. schrieb: > dann hören die Leute halt einfach nicht mehr zu, Ein bisschen irre, heute? Falls du es noch nicht bemerkt haben solltest: Die "Leute"(einige) verachten mich! 1. Weil ich u.A. Arduino nutze 2. Weil ich Arduino im Namen habe Die beiden Punkte scheinen in vielen Fällen ausreichend zu sein, um Häme und Dreck auszuschütten. Diejenigen hören nicht zu, weil sie viel zu sehr damit beschäftigt sind, mich zum Idioten abzustempeln. Es ist eigentlich ganz richtig, den hier manchmal herrschenden Ton zu kritisieren. Aber es scheint mir etwas irrational, jetzt bei mir (in diesem Thread) damit anzufangen. Sicherlich gab es vorher schon, in diesem Forum, tausende von (verpassten) Gelegenheiten. Nett, dass auch du auf mich einschlägst. Aber das Jahre lange einschlagen, auf mich(und Andere), eben solche langen Jahre unkommentiert lässt. Aber besser spät als nie... denn der Ton, hier im Forum, könnte wirklich noch "netter" werden. Da liegt noch viel Arbeit vor dir. Lothar M. schrieb: > Glashaus... ;-) Ich denke, so als Moderator, sitzt du in deinem eigenen Glashaus. Lothar M. schrieb: > Ich habe mit knapp 30 Worten (von denen gut die Hälfte für blumige > Umschreibungen herhalten mssten) genaus das bewirkt, was ich wollte: > dass Robert H. mal kontrolliert, ob seine Annahme mit den programmierten > Fuses schon passt. Leute, welche sich gerade von ihrer bornierten Seite zeigen, Zucker in den Arsch zu blasen, ist sicherlich nicht meine Rolle hier. Das überlasse ich gerne dir/anderen. Merke: Ich bin verantwortlich, für das, was ich sage. Nicht für das, was deine Wahrnehmung daraus macht. Lothar M. schrieb: > du hast zwar völlig Recht gehabt. Danke für die Anerkennung.
Sommerloch, also sage ich auch mal etwas. Wir haben uns alle nicht mit Ruhm bekleckert, dabei war es so offensichtlich; ein einfaches CTRL F auf das zweifelhafte efuse in der gezeigten Batch-Datei hätte genügt. Und Robert H. sollte das Prozedere des Qualitätsmanagements überdenken (lassen). an ufuf: Nicht das "Arduino", sondern das "Fanboy" war für mich Alten anfangs etwas befremdlich, aber das hat sich schon lange gelegt (und wer weiß, was andere mit "Landolt" assoziieren). Dass die Umgangsformen hier im Forum stark zu wünschen übrig lassen, diese Meinung teilen wohl die meisten - es ist leider der Rest, der sich offenbar dabei wohl fühlt.
S. Landolt schrieb: > und wer weiß, was andere mit "Landolt" assoziieren Ich assoziiere damit Packet und TNC. Liege ich damit richtig?
S. Landolt schrieb: > Nicht das "Arduino", sondern das "Fanboy" ... Die Kombination ist die blanke, beabsichtigte, Provokation in Reinform.
Provozieren und sich dann in der Opferrolle gefallen - vertane Lebenszeit, und nicht gerade förderlich für ein gedeihliches Miteinander.
S. Landolt schrieb: > Provozieren und sich dann in der Opferrolle gefallen - vertane > Lebenszeit, und nicht gerade förderlich für ein gedeihliches > Miteinander. Hier sind schon ein paar hochgradig Gestörte unterwegs. Die ziehen jedes positive Signal auf "Low"
S. Landolt schrieb: > Provozieren und sich dann in der Opferrolle gefallen - vertane > Lebenszeit, und nicht gerade förderlich für ein gedeihliches > Miteinander. Naja.... Wenn Du das meinst, hast Du natürlich vollkommen recht. Meine Sicht auf die Angelegenheit ist eine leicht andere. Hier: Beitrag "Re: Arduino Mega hängt wenn String nicht global definiert ist"
Arduino Fanboy D. schrieb: > Die "Leute"(einige) verachten mich! > 1. Weil ich u.A. Arduino nutze > 2. Weil ich Arduino im Namen habe Das ist mir egal. Ich mag nicht, dass du andere Leute oder gerne auch mal die Allgemeinheit beleidigst. > Leute, welche sich gerade von ihrer bornierten Seite zeigen, Zucker > in den Arsch zu blasen, ist sicherlich nicht meine Rolle hier. Genau solche Ausdrucksweisen meine ich. Damit beleidigst du jeden, der es liest, also auch mich. Das mag ich bei dir nicht. Eigentlich ist das schade, denn du bist ja kein Dummkopf. Und wenn du mal gut gelaunt bist, dann auch durchaus hilfsbereit und nett. By the way: wo wir alle über die Umgangsformen in diesem Forum stöhnen: Draußen auf der Straße geht es seit Corona noch viel schlimmer zu. Im Vergleich dazu ist das Forum auf einem guten Weg der Besserung.
Stefan ⛄ F. schrieb: > Arduino Fanboy D. schrieb: >> Die "Leute"(einige) verachten mich! >> 1. Weil ich u.A. Arduino nutze >> 2. Weil ich Arduino im Namen habe > > Das ist mir egal. Ich mag nicht, dass du andere Leute oder gerne auch > mal die Allgemeinheit beleidigst. > >> Leute, welche sich gerade von ihrer bornierten Seite zeigen, Zucker >> in den Arsch zu blasen, ist sicherlich nicht meine Rolle hier. Haushaltstip zur rechten Zeit: Wenn man jemandem Zucker in den Arsch blasen will, sollte man keinen Würfelzucker verwenden. Er könnte sich verkanten.
S. Landolt schrieb: > und wer weiß, > was andere mit "Landolt" assoziieren Ich weiß nicht, was andere damit assoziieren, aber ich kann dir sagen, was ich damit assoziiere: 1. Pedant der alten Garde. Nix vertrauen, was was nicht selber am lebenden Objekt gemessen/überprüft wurde. Guuut! 2. Pedant der alten Garde. Keinesfalls offensichtliche geistige Schwächen des Peers bemängeln. (Vermutlicher Hintergrund: Könnte ja mal Geschäftspartner werden...). Schleeecht! (Jedenfalls in einem Forum, in der Praxis des Geschäftes handele ich natürlich ebenso) Und meine Meinung zu 2. kann ich auch begründen: Wenn offensichtlicher Bullshit verzapft wird, muss der sehr deutlich gebrandmarkt werden. Sonst erkennt das im allgemeinen Rauschen eines Forums nur noch der Wissende als Solchen. Und der braucht keine Hilfe, Hilfe brauchen die, die keine Ahnung haben und deswegen auch nicht den nötigen Eigen-Filter, um offensichtlichen Bullshit selbstständig identifizieren zu können.
Stefan ⛄ F. schrieb: > Genau solche Ausdrucksweisen meine ich. Hat sicherlich seine Gründe, dass du dich davon gerne angesprochen fühlen möchtest. Ist wohl ein tiefes inneres Bedürfnis, welches befriedigt werden will. Nicht wahr, nicht? Aber stimmt schon: Hacke auf mir rum! Dann ist das Bedürfnis befriedigt, und du kannst die anderen vielleicht eher in Ruhe lassen. Also weiter so! Immerhin bist sogar du mittlerweile etwas vorsichtiger geworden, mit deiner Arduinobasherei. Riecht noch nicht nach Einsicht, aber immerhin.... Ja, du warst wirklich ein harter Brocken. Waren einige Demütigungen/Demontagen nötig, um dir die Grenzen für deine Hochnäsigkeit aufzuzeigen. Du hast also alles Recht, auf mich sauer zu sein.
Hallo Zusammen Ich möchten mich hiermit für den LachFLASH meines Lebens bedanken!!! Grüße Oszimilian
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.