Hallo zusammen! Ich suche seit Monaten einen Fehler in einer meiner Schaltung. Ich habe da einen Atmega328 eingesetzt. Da da alles auf Akkubetrieb arbeitet ist das alles sehr stromsparend aufgebaut und der Prozessor befindet sich meistens im Sleep und wird durch einen Uhrenbaustein geweckt. Leider bleibt der immer mal wieder "stehen". Das passiert mal nach ein paar Tagen, mal aber auch erst nach ein paar Wochen. Ich habe dann erst mal versucht den Interrupt zum wecken zu simulieren - geht nicht er läuft nicht an/weiter. Dann habe ich es mit einem Reset versucht - geht auch nicht. Nur ein komplettes trennen von der Versorgungsspannung und einem wieder einschalten bringt den wieder zum Leben. In meinen Augen ist da die Versorgungspannung gut, die habe ich recht gut abgeblockt. Hat hier jemand eine Idee, wo man da noch mal hinschauen sollte? Ich habe da ca. 6 verschiedene Baugruppen, den Fehler hatte ich aber immer mal wieder auf verschiedenen Baugruppen, also kein Fehler an einem Chip. Mir fällt fast nichts mehr ein. Ok, einen Versuch will ich noch mal machen, ich will in der Versorgung des uPs einen Ferrit einbauen. Aber das ist nur so eine Hoffnung. Vielleicht hat jemand schon mal was gehabt und eine Idee? Grüße Hans-Joachim
Hans-Joachim B. schrieb: > der Versorgungsspannung Wie sieht denn das Versorgungskonzept aus? Welche Akkus bei welcher Spannung sind da wie an den uC geschaltet? Welcher Oszillator wird verwendet? Wie sind die Fuses gesetzt?
:
Bearbeitet durch Moderator
Hans-Joachim B. schrieb: > Vielleicht hat jemand schon mal was gehabt und eine Idee? Dein Problem hast du schön beschrieben. Aber du hast und nicht gegeben, was wir überprüfen können. Also habe ich mangels Input keine Idee. Hilfreich sind üblicherweise: - Quelltext eines kleinen Demo-Programms das den Fehler zeigt 1) - Schaltplan - Fotos von den Platinen - Fotos von der Verkabelung - Messprotokolle 1) Dieses zu erstellen wird dich eventuell viel Zeit kosten, die es aber Wert ist. Denn auf dem Weg dahin entdeckt man meistens schon die Problemursache. Wenn die Stromversorgung offenbar OK ist, mache ich das immer als nächstes. Fast jedes mal finde ich dabei den Fehler selbst.
Hi OK, Schaltung und Programm geheim. Dann raten wir mal drauflos... Stacküberlauf, weil ISR kein RETI hat, oder sich selbst aufruft. Weil Speicherbereiche vom Stack überschrieben werden, oder umgekehrt. Weil das Programm aus unbekannten Gründen ins Nirvana läuft. Weil die Schaltung auf den Anruf des Inkassobüros reagiert. Weil die Mikrowelle undicht ist. Weil ein Polizeifahrzeug vor dem Haus einen Funkspruch empfängt oder sendet. Weil.... Weil...weil... da gibt es viele Gründe. Vielleicht ist aber auch Corona schuld. Such dir was aus, schließ es mit entsprechender Maßnahme aus und du wirst dich dem Fehler nähern. Oder es ist was ganz anderes. Gruß oldmax
Schau Dir die Stellen genau an wo Du IRQs deaktivierst. Kann es einen Zusand geben das die MCU in Sleep geschickt wird ohne das die IRQs wieder aktiviert sind? Genug Kerkos an der VCC? Akkus habe einen relativ hohen Innenwiderstand und es reicht ein kurzer Einbruch der VCC, um die MCU durch bitkipper irgendwo ins Nirvana zu schicken. Brownout Reset richtig gesetzt? Einbruch der VCC muss zum Reset führen, sonst macht die MCU die wildesten Sachen. Sowas hatten wir mal in der Serie. Bei jedem Power Off hat die MCU noch x Zyklen im unsicheren Spannungsbereich gearbeitet. Oft genug Power Off und durch den zufälligen Program Counter / zufällige Instructions überschrieb die MCU ihr Flash.
Also alles wie immer: > Ich habe ein Auto > Das tuts nicht mehr. > Was kann ich machen, damit es wider tut.
Hans-Joachim B. schrieb: > Dann habe ich es mit einem Reset versucht - geht > auch nicht. Wenn es aus einem Reset nicht in den normalen Betrieb geht, dann blockiert eine der Baugruppen den ordentlichen Lauf des Programms. Das betrifft nur Baugruppen die abgefragt werden, oder zu schreibende bei denen eine Hardwareaktion, z.B. das Einschalten einer weiteren Baugruppe, im Programmablauf benötigt wird. Reine Befehlsempfänger ohne Rückwirkung auf den Ablauf selbst, wie z.B. eine Anzeige, sind unkritisch. Man darf nur dann nicht "Anzeige aus" mit "Programm läuft nicht" gleichsetzen. Man debugt so was üblicherweise, indem man bei auf kritische Baugruppen zugreifenden Befehlen, vorher und nachher Ausgaben per Serieller Schnittstelle macht und protokolliert. Aufgrund des Protokolls sieht man, wo's hängt.
Beitrag #6967633 wurde von einem Moderator gelöscht.
Hi Klar, man kann Vieles vermuten und Einiges davon kann zum beschriebenen Fehler führen. Aber, hat die Schaltung eine Anzeige? Da steht nix. Da irgendwas eine zeitlang funktioniert, gibt es vermutlich ein Programm. Könnt aber auch der "Wecker" (Uhrenbaustein) sein, der unbekannterweise mit Firmware "fest verschaltet" ist. Also raten wir mal weiter bis dann irgendwann einmal der Ruf "Heureka" die gefundene Lösung verkündet. Aber bis dahin schätze ich mal, werden für den TO weitere Monate vergehen, wenn weiterhin nur über eine nicht funktionierende Blackbox geredet wird Gruß oldmax
Martin V. schrieb: > .... Ich stimme dir ja äußerst ungerne zu! Aber hier muss es mal sein. Voraussetzungen: - Schaltplan geheim - Programm geheim - Aufbau geheim Somit liegt der Fehler im tiefen Schatten. Die Zukunft: Und das wird auch so bleiben, bis sich die Voraussetzungen ändern. Herzschlag ist der Takt schrieb im Beitrag #6967633: > die üblichen Idioten hier Du meinst dich selber, oder?
Martin V. schrieb: > Aber, hat die Schaltung eine Anzeige? Da steht nix. Bei mir steht auch "z.B.", soll ich "z.B." zum besseren Verständnis ausschreiben? Das war eine Veranschaulichung. > Also raten wir mal weiter bis dann > irgendwann einmal der Ruf "Heureka" die gefundene Lösung verkündet. Ja, so ist es. Der Eingangspost war mir auch ein wenig zu viel "Prosa" und zu wenig Handfestes. Allerdings war der Hinweis, dass ein Reset des Controllers nicht zum erneuten Funktionieren führe, ein sehr deutlicher und da konnte man tatsächlich etwas dazu sagen, ohne den Rest, SW & HW zu kennen.
Hi Herzschlag ist der Takt schrieb im Beitrag #6967633: > Ja, zuerst beim Takt des Kontrollers. Schreib ein Programm, das den auf > einem Pin ausgibt und miß ihn dort. > BTW: Spring nicht auf die üblichen Idioten hier an! Die jagen Dich gegen > die Wand und verpissen sich dann -und Du hast immer noch keinen Hinweis. Na ja, die Möglichkeit gibt es, aber wenn ich richtig verstanden habe, schläft der Controller und wird geweckt. Das funktioniert manchmal tagelang, manchmal auch nicht. Viel Spaß also bei der Beobachtung des Taktes. Wenn der Controller nicht geweckt wird, sehe ich dann trotzdem den Takt? Sehe ich den Takt, wenn das Programm irgendwelche Adressen anspringt, die er aufgrund eines Stacküberlaufes aus dem Variablenspeicher liest? Daher ist der zweite von mir zitierte Satz auch nicht bei einer Fehlersuche hilfreich. Denk da mal drüber nach. Gruß oldmax
Hallo! Vielen Dank an alle, die hier beigetragen haben. Ich hatte nicht erwartet, dass hier die Lösung mundgerecht aufbereitet kommt. Das kann man keinem zumuten. Daher habe ich nicht die ganze Schaltung hier geschildert und auch nicht die 30k Programm abgedruckt. @Max M.; Danke, da muss ich bei der Brownoutdetection echt noch mal hinschauen. Beim Lesen der Hinweise sind mir da auch 3 per I2C angesprochene Bausteine eingefallen. Die sollten ja eigentlich mittels sauberer Start/Stopp Sequenzen auch einen "Reset" erhalten, aber ...... @ Lothar M.: Das Ganze wird über eine 18650er Lithium-Ionen Zellen betrieben. Eingangsseitig habe ich da einen 470uF Elko, dann noch mal 2 4,7uF Tantal und verteilt an jedem IC einen 100nf KerKo an der Versorgungsspannung. @Stefan: Das mit dem Testprogramm hatte ich schon mal versucht - ich konnte das Problem dadurch bisher nicht näher eingrenzen. Wie beschrieben, es kommt höchst sporadisch vor. Einmal hatte ich es an der gleichen Baugruppe nach drei Tagen und dann nach 6 Monaten wieder. @EAF: Sorry, ich dachte schon, dass ich da etwas spezifischer bei meinem Problem war. Noch mal vielen Dank an alle und ich schlage vor, wir schließen diesen Thread hiermit. Grüße Hans-Joachim
Hans-Joachim B. schrieb: > @EAF: Sorry, ich dachte schon, dass ich da etwas spezifischer bei meinem > Problem war. KA, was der Spruch bedeuten soll.... Da du nicht an einer Lösung deines Problems interessiert zu sein scheinst, wünsche ich dir, interessante Zeiten zu durchleben.
Wenn der selbst mit Hardreset nicht starten will, Zustände von außen (PIN-Spannungen) überprüfen. Vcc, Takt, Reset, Port-I/O, Pullups, irgendwas muß da ja schon bei den Basics faul sein.
Da sich dein Problem durch einen Reset nicht beheben läßt, würde ich auf einen blockierten Bus tippen (I2C?) der nicht durch Timeouts abgefangen wird. Also alle while Schleifen prüfen und ggv mit Timeouts abbrechen.
Thomas Z. schrieb: > Da sich dein Problem durch einen Reset nicht beheben läßt, würde ich auf > einen blockierten Bus tippen (I2C?) der nicht durch Timeouts abgefangen > wird. > Also alle while Schleifen prüfen und ggv mit Timeouts abbrechen. Hallo Thomas, ja, das hatte ich schon drin - aber wenn das direkt nach dem Reset klemmt sehe ich das ggf. nicht. Das werde ich auf jeden Fall verbessern. Danke.
Beitrag #6967831 wurde von einem Moderator gelöscht.
Hans-Joachim B. schrieb: > Wie beschrieben, es kommt höchst sporadisch vor. 1. Multipliziere den Fehler indem du viele solcher Geräte parallel laufen lässt. 2. Ändere irgendwas Grundlegendes an deiner Konfiguration zu ändern. Ich würde an deiner Stelle a. die Versorgung mit einem stabilen Labornetzteil machen und b. sicherstellen, dass der Takt stabil da ist (externer Quarzoszillator). 3. Baue LEDs ein, damit man sieht, wie weit dein Programm gekommen ist. (die Punkte 2 und 3 funktionieren natürlich nur mit stationärer Stromversorgung) > ich schlage vor, wir schließen diesen Thread hiermit. Warum hast du ihn denn dann aufgemacht? Stell dir mal vor, dass du ABSOLUT nichts von deiner Schaltung, deiner Anwendung, der Umgebung, dem Layout, dem Programm und auch sonst GAR NICHTS von deiner Schaltung weißt. Und dann lies deine Posts und überlege, ob du dazu was Brauchbares sagen könntest. Ich bin echt gut im Raten, aber ich kanns nicht...
Lothar M. schrieb: > Hans-Joachim B. schrieb: >> Wie beschrieben, es kommt höchst sporadisch vor. > 1. Multipliziere den Fehler indem du viele solcher Geräte parallel > laufen lässt. Es laufen 8 Geräte gleichzeitig > 2. Ändere irgendwas Grundlegendes an deiner Konfiguration zu ändern. > Ich würde an deiner Stelle a. die Versorgung mit einem stabilen > Labornetzteil machen und b. sicherstellen, dass der Takt stabil da ist > (externer Quarzoszillator). Es ist ein externe 8MHz Quarz verbaut. Ich hatte es natürlich im Büro längere Zeit mit einem Netzteil am laufen - leider ist in dieser Zeit der Fehler nicht aufgetreten. > 3. Baue LEDs ein, damit man sieht, wie weit dein Programm gekommen ist. > (die Punkte 2 und 3 funktionieren natürlich nur mit stationärer > Stromversorgung) Danke, das werde ich mal probieren. Der Akku hält ja eine Weile durch und wenn es steht (bekomme ich mit) muss ich das Teil halt in spätestens einem Tag besuchen und den Status mal anschauen. >> ich schlage vor, wir schließen diesen Thread hiermit. > Warum hast du ihn denn dann aufgemacht? > Stell dir mal vor, dass du ABSOLUT nichts von deiner Schaltung, deiner > Anwendung, der Umgebung, dem Layout, dem Programm und auch sonst GAR > NICHTS von deiner Schaltung weißt. > Und dann lies deine Posts und überlege, ob du dazu was Brauchbares sagen > könntest. Ich bin echt gut im Raten, aber ich kanns nicht... Wahrscheinlich liegt es an mir. Ich habe es ja auch gelesen, ich bin ein Troll - na ja. Ja, ich hatte was brauchbares erwartet, so was wie: "So was hatten wir auch mal. Da hat der Reset auch nicht mehr geholfen. Damals haben wir die Spannungsversorgung verbessert und dann war der Fehler weg." Ich hatte nie erwartet, dass hier jemand meine komplette Schaltung versucht nachzuvollziehen und dann auch noch in das Leiterplatten Design einzutauchen. Zudem kann man komplette Schaltungen leider nicht immer veröffentlichen, sehr wohl aber Erfahrungen austauschen. Als ich feststellte, dass es so nicht der Fall ist habe ich vorgeschlagen, den Thread zu schließen.
Hans-Joachim B. schrieb: > Es ist ein externe 8MHz Quarz verbaut. Und je nach Sleepmode muss der erst noch anlaufen. Nimm mal den internen Takt (der läuft schneller an) oder eben wie gesagt einen externen Taktgeber (= aktiver Quarzoszillator, der sicher schwingt und immer schwingt). > Ja, ich hatte was brauchbares erwartet, so was wie: "So was hatten wir > auch mal. Es hilft dir nicht, wenn ich sowas mit "eingefrorenem µC" auch mal hatte und dabei die Takterzeugung das Problem war. Allerdings war da das Problem nur bei langsam steigender Versorgung und es war der interne Oszillator. Hilft dir also gar nichts, dieser Tipp. Und um solche irreführenden "Tipps" auszuschließen, ist es eben sinnvoll, zu wissen, welchen Takt und welchen Sleepmode du verwendest.
:
Bearbeitet durch Moderator
Hans-Joachim B. schrieb: > "So was hatten wir > auch mal. Da hat der Reset auch nicht mehr geholfen. Damals haben wir > die Spannungsversorgung verbessert und dann war der Fehler weg." Ich hatte sowas tatsächlich mal. In einem 15kV Netzteil war nach einem Überschlag der Flash verändert und ich mußte ihn neu programieren. Grund war die GND-Plane, darüber koppelte der Entladestrom ein. Nach Aufteilung der GND-Plane in Inseln mit Net-Ties als Verbindung funktionierte alles einwandfrei. Aber das wird bestimmt nicht bei Dir der Fall sein. Die Möglichkeiten sind derart mannigfaltig, daß ein Tip wie ein Sechser im Lotto wäre.
Lothar M. schrieb: > dabei die Takterzeugung das Problem war Um das auszuschließen könnte man testweise einen externen Taktgenerator statt des Quarzes anschließen.
Hans-Joachim B. schrieb: > Dann habe ich es mit einem Reset versucht - geht > auch nicht. Schalte mal direkt als erstes ne LED ein, ob er wirklich nicht aus dem Reset kommt oder nur die Software hängt:
1 | int main (void) |
2 | {
|
3 | cli(); |
4 | watchdog_2s(); |
5 | led_ein(); |
6 | delay_300ms(); |
7 | led_aus(); |
8 | delay_300ms(); |
9 | // usw.
|
Sowas meine ich mit "Quarzoszillator": https://www.reichelt.de/de/de/quarzoszillator-1-0-mhz-oszi-1-000000-p13673.html Nur halt in der richtigen Frequenz mit der richtigen Versorgungssspannung. Hans-Joachim B. schrieb: > Ich hatte es natürlich im Büro längere Zeit mit einem Netzteil am laufen - > leider ist in dieser Zeit der Fehler nicht aufgetreten. Ja, warum läuft es nicht mehr? Du musst das natürlich immer weiter laufen lassen, bis der Fehler auftritt. Und wenn der Fehler bei allen anderen auftritt, aber nicht bei dir im Büro, auf welchen Schluss könnte man dann kommen? Was müsste man tun, um diesen Verdacht mehr zu belasten und zu verifizieren? Ich habe Dauertests laufen, die sind jahrelang aktiv. Einer davon hat jetzt 4 Steuerungen fast 2 Millionen mal jede Minute ein- und ausgeschaltet. Das sind annähernd 4 Jahre. Inzwischen bin ich mir sicher, dass ich an dieser Ecke keine Überraschungen erleben werde... ;-)
:
Bearbeitet durch Moderator
Hans-Joachim B. schrieb: > Ja, ich hatte was brauchbares erwartet, Die Schwierigkeit ist folgende: Du verstehst so wenig vom eigentlichen Problem, dass Du nicht einmal erkennen kannst, wenn Dir jemand Brauchbares schreibt. Du erwartest etwas in Deiner Tellerrandhöhe, alles darüber hinaus hört sich für Dich wie Esperanto an.
Ich würde versuchen das Problem schneller herbeizuführen. z.B. 10uF statt 470uF. Du greifst einmal pro Sekunde auf den I2C Bus zu, dann mach es 100 mal. usw.
batman schrieb: > Wenn der selbst mit Hardreset nicht starten will, Zunächst mal prüfen, ob er wirklich nicht mehr läuft oder einfach bei der Initialisierung oder vor einer Rückmeldung in eine Warteschleife gerät. Ich tippe daher auf irgendwelche blockierende Hardware und eine unglücklich gesetzte Warteschleife. Im Programm vielleicht eine LED blinken lassen (die kann man aus Stromspargründen auch abklemmen).
Christian H. schrieb: > batman schrieb: >> Wenn der selbst mit Hardreset nicht starten will, > > Zunächst mal prüfen, ob er wirklich nicht mehr läuft oder einfach bei > der Initialisierung oder vor einer Rückmeldung in eine Warteschleife > gerät. > Ich tippe daher auf irgendwelche blockierende Hardware und eine > unglücklich gesetzte Warteschleife. Im Programm vielleicht eine LED > blinken lassen (die kann man aus Stromspargründen auch abklemmen). Danke, so was werde ich mal einbauen
Hi Hans-Joachim B. schrieb: > Ich hatte nie erwartet, dass hier jemand meine komplette Schaltung > versucht nachzuvollziehen und dann auch noch in das Leiterplatten Design > einzutauchen. Zudem kann man komplette Schaltungen leider nicht immer > veröffentlichen, sehr wohl aber Erfahrungen austauschen. > Als ich feststellte, dass es so nicht der Fall ist habe ich > vorgeschlagen, den Thread zu schließen. Kann ich durchaus verstehen, aber doch komm einfach mal bei mir vorbei und lies deinen ersten Post. Du weißt natürlich sofort, das es sich um einen Profi handelt und dir ist auch sofort klar, das solche Fragen gar nicht von Bastlern, Schülern oder Studenten gestellt werden können. Und du weißt natürlich auch von Anfang an, das dieses Problem bei einem Gerät besteht, welches über einen Bus mit mehreren Teilnehmern verbunden ist. Außerdem ist das ja nicht relevant, um eine Fehlerdiagnose zu geben. Aber du schreibst im letzten zitierten Satz von fehlendem Erfahrungsaustausch -? Ernsthaft? Da stellt sich mir die Frage, kannst du nicht lesen oder verstehst du das geschriebene nicht? Wenn du in einem so offenen Forum postest, mußte du lernen, auch mal völlig unsinnige Antworten zu schlucken. Oder noch besser zu ignorieren. In einem Punkt hast du Recht, wir haben alle schon mal vor einer Schaltung gesessen und uns gefragt, was dieses dämliche Gerät gegen uns hat. Und genau diese Antworten hast du ja auch erhalten, vom fehlenden Takt (Hardware) bis zum Stacküberlauf (Software) Ob dir da etwas geholfen hat? Wär schön, wenn's dazu mal eine Antwort gäbe. Es wird nicht alle interessieren, aber vielleicht den ein oder anderen schon,allein um zu wissen, wer der Sieger im Ratespiel ist. Nun, nicht jeder meiner Sätze sind ernst zu nehmen, aber um nochmal auf den ersten Satz zu kommen, erwarte nicht, das in diesem Forum nur absolute Profis unterwegs sind und nur in der Profiliga gechatet wird. Und nun setz dich Mal vor den Bildschirm und vergiß deinen Namen und ließ, was du geschrieben hast und dann versuch mal eine treffende Antwort zu liefern. Gruß oldmax
:
Bearbeitet durch User
Hans-Joachim B. schrieb: > Leider bleibt der immer mal wieder "stehen". Das passiert mal nach ein > paar Tagen, mal Es haette Dir aich passieren koennen, dass gemeint wuerde, Du solltest froh sein das die stehen bleiben und nicht weg laufen bei dem aktuellen Chipmangel. Aber asynchrone Fehler im Verbund sind kaum zu finden.
Hallo! Um das noch abzuschließen: Mittlerweile habe ich mehrere Wochen keine Probleme mehr. Ursache waren wohl irgendwelche Störungen auf der Reset-Leitung. Es sind eigentlich keine langen Leitungen oder ähnliches dran, aber das war es wohl. Zunächst hatten wir einen Resetbaustein eingebaut (MAX803) eingebaut. Hier hatten wir versehentlich (nachher zum Glück) dem einen Arbeitswiderstand von 10k mitgegeben, den eigentlichen 10k Widerstand am Reset aber beibehalten. Damit lief die Schaltung sicher. Mittlerweile wissen wir, dass die Schaltung auch sicher läuft, wenn der Resetpin mit 4k7 gegen Vcc geschaltet wird. Wie gesagt: Am Reset-Pin gab es keine langen Leitungen (also Antennen) aber nach dieser Änderung geht es. Grüße
Damit hast Du zwar den Auslöser verringert, aber nicht den Fehler beseitigt. Der Fehler bleibt weiterhin bestehen, daß bei einem Reset eine Peripherie nicht richtig initialisiert wird und z.B. den I2C-Bus dauerhaft blockiert. Der Fehler kann daher bei einem Watchdogreset oder Spannungseinbruch wieder zuschlagen.
Hallo Peter, ich glaube nicht. Wir konnten feststellen, dass der Prozessor - also der sich in diesem seltsamen Zustand befand - nach einem Reset nicht mehr meldet. Keine Aktivitäten an den SCL und SDA Leitungen. Wir hatten probehalber einen Portpin unmittelbar nach dem Reset, also in der Initialisierung, toggeln lassen - das kam nie nach einer Betätigung des Resets wenn der Prozessor in diesem Zustand war. Spannung Aus-Ein zeigte dann aber wieder die normale Reaktion. Unsere Erklärung ist eigentlich nur so, dass sich durch einen Glitch am Resetpin, kürzer als die spezifizierte Zeit, der Prozessor im Microcode etc. irgendwo aufhängt.
Wie genau ist denn der !RST-Pin vorher und jetzt beschaltet? Gibt es da einen Pull-up Widerstand (gegen Vcc) und einen Abblockkondensator gegen GND? Wenn man hier den begrabenen Hund vermutet, dann kann man auch mal versuchen, den !RST-Pin als "normalen" I/O pin per Fuse zu konfigurieren. Dann führt "wackeln" an dem Pin nicht mehr in den Reset. Allerdings ist dann das Programmieren etwas ekeliger (HV-Programming). Wie sieht es eigentlich mit dem Watchdog aus? Ist der aktiv? mit Grüssen
Beitrag #7025011 wurde von einem Moderator gelöscht.
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.