Eine kleine Schaltung mit dem ATmega hängt sich immer wieder auf. Jetzt bin ich auf der Suche nach möglichen Ursachen, um das zu beheben. Zur Schaltung: Ein ATmega88 (4MHz) liest alle paar Sekunden einen Schalter ein (Leitungslänge ~30cm). Der zugehörige Pin hat einen externen Pull-up (100k) und Kondensator (100n). Wenn sich der Zustand des Schalters ändert (Polling, kein Interrupt), wird das Ereignis über SPI einem Funkmodul übergeben. Der Reset-Pin hat einen externen Pull-up (10k) und einen Kondensator (100n). Die Spannungsversorgung erfolgt über eine Batterie, und beträgt minimal 2,4V (bei maximaler Belastung mit uC und aktivem Funkmodul), also weit über den geforderten 1,8V (Atmega88 bei 4MHz). Das ganze wurde mit mehreren (4) Platinen getestet, die sich alle so verhalten. Schlechte Lötstellen, die alle den gleichen Fehler produzieren, sind also unwahrscheinlich. Sicherheitshalber wurden bei einer Platine alle Lötstellen nochmal nachgelötet. Die Schaltung läuft mehrere Tage bis sie nicht mehr reagiert. Nach einem Reset (Pin manuell kurz auf Low) geht das wieder einige Tage gut bis der gleiche Zustand wieder auftritt. Es wurden einige Pins zur Ausgabe des aktuellen Zustands verwendet, um anzuzeigen, wo sich der Controller aufhängt. Es ist aber kein Muster erkennbar. Mögliche unerwartete Resets werden über das Statusregister ausgewertet und ausgegeben. Bisher traten jedoch keine auf. Auch wurde ein BADISR_vect eingefügt, der aber auch noch nie auftrat. Außerdem ist der Brown-out Detector aktiv, auch das hat noch nicht zu einem Reset geführt. Daneben wäre die Annahme, das der Controller nach einem zufälligen Reset sauber weiter laufen müsste, wie er das nach einem manuellen Reset auch tut. Die Aufhänger fallen jedoch nicht in diese Kategorie. Es wird kein dynamischer Speicher verwendet, auch keine Rekursionen oder dergleichen, was zu einem Speicherproblem führen könnte. Es wurde schon versucht, durch EMV Einkopplung (schaltender Schütz) den Controller aus dem Tritt zu bringen, ohne Erfolg. Natürlich könnte ich jetzt einen Watchdog mitlaufen lassen, der das Problem aber nur verschleiern würde. Was könnten also weitere Ursachen für die Aufänger sein? Danke schon mal.
Hallo, wie immer bitte mal den Schaltplan posten. Die Ursache kann an der Schaltung, aber auch an der Software liegen. Kommen bei der SPI Datenweiterleitung while - Schleifen vor, die kann man dann mit einem Timeout versehen, oder aber wie Du schreibst einen Watchdog verwenden.
Markus E. schrieb: > Die Schaltung läuft mehrere Tage bis sie nicht mehr reagiert. Meine Glaskugel sagt: Da läuft ein Zählvariable über, und du handelst das nicht richtig ab.
@ Markus E. (residuum) >Ein ATmega88 (4MHz) liest alle paar Sekunden einen Schalter ein >(Leitungslänge ~30cm). Der zugehörige Pin hat einen externen Pull-up >(100k) und Kondensator (100n). Der Pull-Up ist recht hochohmig und der Kondensator hat dort DIREKT nichts zu suchen, denn der wird vom Schalter hart kurzgeschlossen! Da sollte man immer einen Längswiderstand nutzen, dann ist auch der RC-Tiefpass voll wirksam. Etwa so! https://www.mikrocontroller.net/articles/Entprellung#Einfacher_Taster >Der Reset-Pin hat einen externen Pull-up (10k) und einen Kondensator >(100n). OK. >Die Schaltung läuft mehrere Tage bis sie nicht mehr reagiert. Aha. >Was könnten also weitere Ursachen für die Aufänger sein? Poste deinen Code als Anhang. Ein Schaltplan sowie ein Bild des realen Aufbaus wären auch hilfreich. Bitte die Bildformate beachten.
Hallo Markus E. , nimm mal ein Handfunkgerät mit 5Watt im 2m Band ~145MHz und du wirst sehr schnell feststellen können, das es der Tasteraufbau sein wird.
In den while-Schleifen blieb der uC bisher definitiv nicht hängen, das wäre an den Debug-Pins zu sehen gewesen. Den Kondensator am Schalter entferne ich mal. Und dann nehme ich auch nochmal ein Handy her. Schaltplan und Code kann ich leider nicht veröffentlichen, auch wenn's hilfreich wäre.
Markus E. schrieb: > Schaltplan und Code kann ich leider nicht veröffentlichen, auch wenn's > hilfreich wäre. OK..... Dann bleibt nur der Yin Weg: Wir können über das Problem reden... Manchmal ändert sich das Problem, während man darüber redet. Und manchmal ändert sich die Sicht auf das Problem. (was beides irgendwie aufs gleiche hinaus läuft) Alternativ, die Yang Variante: Problem erkennen Lösung erarbeiten Lösung durchsetzen
Schaltplan, Layout, Programm. Es versuchen zwar immer viele wie Du, aber ich kenne kein funktionierendes Exportfilter Schematic -> Prosa, bzw. *.c -> Prosa. SCH -> PDF, PCB -> PDF, *.c,*.h als *.c,*.h, zippen und ab damit. SCH geht auch als Handzeichnung und PCB als Foto. Fotos natürlich nicht wie das verwackelte Selfie einer 3-jährigen.
Markus E. schrieb: > Schaltplan und Code kann ich leider nicht veröffentlichen wer oder was hindert dich? brauchst du Hilfe beim upload?
Markus E. schrieb: > Schaltplan und Code kann ich leider nicht veröffentlichen, auch wenn's > hilfreich wäre. Es wäre überhaupt erstmal ein Ansatz. Ich gehe ja auch immer ohne Fernseher zur Werkstatt, erzähle dem Mechaniker was vom Pferd und er gibt mir dann das richtige Ersatzteil mit. Letztens wars R42, eingelötet und er geht wieder.
Abgesehen davon, dass der Code ~3000 Zeilen umfasst, die sich kaum jemand im Detail durchsehen wird, darf ich keine IP veröffentlichen. Ich hatte gehofft, dass jemand ähnliche Erfahrungen gemacht hat und evtl. sogar eine Lösung gefunden hat, die auch für das beschriebene Problem passt. Es gibt ja einige bekannte Fehlerquellen, die immer wieder Probleme bereiten. Vielleicht hat da jemand auch eine Checkliste. Was ich vergaß zu erwähnen ist, dass der Aufhänger zwar meist nach einigen Tagen passiert, es aber auch schon wenige Minuten nach Einschalten bzw. Reset auftrat.
Markus E. schrieb: > Ich hatte gehofft, dass jemand ähnliche Erfahrungen gemacht hat und > evtl. sogar eine Lösung gefunden hat, die auch für das beschriebene > Problem passt. Wurden doch schon genannt: 1. Störeinstrahlung 2. Überläufe Versorgungsprobleme zähle ich mal zu 1 und Heap/Stack Kollisionen zu 2. Und dann gibts ja noch Millionen von verschiedensten Böcken, welche du da geschossen haben könntest. Es wird dir nichts anderes übrig bleiben, als den Fehler einzugrenzen. Helfen können wir dir dabei nicht.
Abstürze sind bei mir meistens Ram, Zaehler und zu kleine arrays.. Vielleicht ist es auch ein problem in einer Schleife das unendlich landet...
Markus E. schrieb: > Ich hatte gehofft, dass jemand ähnliche Erfahrungen gemacht hat ja diese Erfahrungen finden sich hier zu Hauf: vergessene Abblock Kondis, freihängende Resets, unsaubere Versorgung, fehlerhafter Code, unsaubere Lötstellen, fehlerhaftes Layout, wilde Verdrahtung, klappriges Steckbrett, EMV verseuchte Umgebung, das wäre der Ansatz wo du schauen könntest. :-) PS Markus E. schrieb: > darf ich keine IP veröffentlichen. an einer IP ist hier niemand interessiert, Markus E. schrieb: > Schaltplan und Code kann ich leider nicht veröffentlichen, zwischen kann und darf erkennst du einen Unterschied?
:
Bearbeitet durch User
Besten Dank für eure Ideen dazu. Ich werde denen nachgehen und bei Erfolg hier die Ursache beschreiben.
@ Markus E. (residuum) >Was ich vergaß zu erwähnen ist, dass der Aufhänger zwar meist nach >einigen Tagen passiert, es aber auch schon wenige Minuten nach >Einschalten bzw. Reset auftrat. Eine nicht ganz unwesentliche Information. Sowas kann ein Zugriffsfehler auf Variablen sein, welche im Hauptprogramm und im Interrupt benutzt werden, siehe Interrupt. Der Zugriff muss volatile und atomar sein.
Markus E. schrieb: > Abgesehen davon, dass der Code ~3000 Zeilen umfasst, die sich kaum > jemand im Detail durchsehen wird Unabhängig davon ob du darfst oder nicht... es ist deutlich leichter, in 3000 vollständigen Codezeilen die relevanten Stellen und damit den Fehler zu finden... als auf Auszüge davon zu starren, raten zu müssen wie das Programm drumrum aussieht und wie die Auszüge aufgerufen werden, und am Ende steckt der Fehler in einem ganz anderen Teil vom Programm.
Markus E. schrieb: > Abgesehen davon, dass der Code ~3000 Zeilen umfasst 3000 Zeilen nur für ne Tasterabfrage, das ist aber heftig. Eine Methode SW-Fehler zu finden ist, den Code soweit abzuspecken, daß der Fehler gerade nicht mehr auftritt und dann anzuschauen, was man zuletzt entfernt hatte. Man kann auch umgekehrt vorgehen. Alles bis auf das notwendigste minimieren und dann schrittweise weitere Teile wieder hinzufügen. Falls dann schon das Minimalprogramm den Fehler enthält, ist die Suche wesentlich einfacher. Auch steigt dann die Chance, daß es ein Schaltungs- oder Layoutfehler ist.
Falk B. schrieb: > Eine nicht ganz unwesentliche Information. Sowas kann ein Zugriffsfehler > auf Variablen sein, welche im Hauptprogramm und im Interrupt benutzt > werden, siehe Interrupt. Der Zugriff muss volatile und atomar sein. ...auch nicht initialisierte Variablen können zu ähnlichen Sympthomen führen. Speziell wenn es sich um Zähler handelt, die irgendwann mal überlaufen.
Hallo Makus, in der Annahne es ist kein Softwarefehler. Kann es auch an der Spannungsversorgung des Atmega88 liegen. 2,4 Volt mit Takt 4MHz sollte noch OK sein. Aber, Aber ein sehr kleiner Einbruch der Spannung ist fatal(1,8 Volt und 4MHz ist der Grenzwert) Einfach mal den µC eine externe Spannung z.B. 3,3 Volt können oder den Takt auf 1MHz einstellen. Mit freundlichen Grüßen fredred
Markus E. schrieb: > In den while-Schleifen blieb der uC bisher definitiv nicht hängen, das > wäre an den Debug-Pins zu sehen gewesen. Wo dann? Konkret ist es so, dass ein uC nicht "nichts tut", sondern er tut irgendetwas mit maximaler Rechenleistung. Jetzt musst du herausfinden, was das ist. Und dann, wie er dorthin gekommen ist. Ganz gern ist auch ein ungeprüfter Pointer, der verstümmelt über eine Schnittstelle gekommen ist, die Fehlerquelle. Oder ein verpasstes Ende-Zeichen. Meist sind solche Fehler einfach "Naivitätsfehler" frei nach den Motto: "Die Daten, die da kommen, sind sicherlich korrekt."
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.