Hallo! Ich habe ein Problem und hoffe auf Ideen. Ich habe seit langem eine Schaltungen mit ATMega32, EADOGM162 und diversen Tasten im Einsatz. Diese funktionierte bisher immer recht gut. Nach diversen Änderungen um den Quellcode übersichtlicher und universeller zu gestalten habe ich nun ein Phänomen! Nach dem ausschalten startet die Schaltung nicht mehr. Es geht zwar noch eine LED an, aber das Display wird wohl nicht initialisiert... Aus diesem Zustand bekomme ich die Schaltung nur mit dem alten Programm wieder raus. Wenn ich das neue flashe, tut dies auch für unbestimmte Zeit wieder. Das Phänomen tritt also nicht bei jedem ausschalten auf, sondern nur manchmal. Hat jemand eine Idee was dort in dem Controller passiert? Den Quellcode zu posten wäre wohl sehr unübersichtlich, weil es sich um ca. 30 c-Files/Header-Files handelt... Gruß
>Den Quellcode zu posten wäre wohl sehr unübersichtlich, weil es >sich um ca. 30 c-Files/Header-Files handelt... Tja, da müssen wohl wieder die Glaskugeln an die Front.
Nimm einen 0815 Logikanalyser und vergleiche die beiden Inits des LCDs. Dann noch den init-Quelltext dazu und du solltest den Fehler finden. Ohne Schaltplan und Code wird dir nieman helfen können. Thomas PS: Ich hatte einen ähnlichen Fehler, beim Reset wurden die Register nicht sauber initiiert und deshalb kam ne falsche Init-Sequenz und das LCDblieb (zu recht!) dunkel.
Da kann viel passieren und es können verschiedenen Ursachen in Frage kommen. Du solltest hier und da in der Schaltung nach Eigentümlichkeiten suchen und vielleicht den einen oder anderen Befund sorgfältig prüfen. Auch im Internet finden sich viele Hinweise. Es gilt: Ruhe bewahren und den Anordnungen der Moderatoren folgen. Viel Glück!
Code und Funktionalität schrittweise soweit reduzieren bis der Fehler nicht mehr auftritt. Die letzte Version bei der der Fehler noch auftrat sollte dann so klein sein, daß man es posten kann. Ja Fehlersuche kann sehr mühsam sein.
Dennis schrieb: > Nach diversen Änderungen um den Quellcode übersichtlicher und > universeller zu gestalten Wozu ändert man etwas wenn es funktioniert? In dem Moment wo es funktioniert interessiert mich das Wie und Warum nicht mehr. Never touch a running system!
Dennis schrieb: > Das Phänomen tritt also nicht bei jedem ausschalten auf, sondern nur > manchmal. > > Hat jemand eine Idee was dort in dem Controller passiert? Könnte ein Brownout sein. Der Controller macht Mist, weil die beim Ausschalten langsam fallende Spannung ihm Zeit dazu gibt. Sie ist für eine nennenswerte Zeitspanne einerseits nicht mehr hoch genug, daß er korrekt arbeiten kann, andererseits aber noch nicht gering genug, daß er komplett stehenbleibt. Was dann genau passiert, ist teils Zufall, teils exemplarabhängig, teils gesetzmäßig. Es kann gut passieren, daß schon geringe Codeänderungen dafür sorgen, daß plötzlich mit stark erhöhter Wahrscheinlichkeit etwas passiert, was auch nach dem nächsten PowerUp noch wirkt (also Flash oder EEPROM teilweise überschreibt). Das liegt nicht daran, daß der Code an sich fehlerhaft ist. Er ist einfach nur anders und sorgt dafür, das die stochastischen Vorgänge beim Brownout anders verlaufen. Es gibt nur zwei Möglichkeiten, Brownout-Effekte zuverlässig zu verhindern. 1) Internen Brownout-Detector verwenden. 2) Externen Brownout-Detector verwenden (z.B. in Form eines sog. "Reset-IC") Beide machen aber letztlich das Gleiche: Bei Unterschreiten einer definierten Mindestspannung den µC möglichst fix in den Reset-Zustand zu versetzen. Dann steht er nämlich komplett und kann keinen sinnlosen Müll mehr ausführen. Diese Mindestspannung muß einerseits niedrig genug sein, daß nicht schon im normalen Betrieb gelegentlich der Brownout-Detector das Teil resettet, andererseits aber hoch genug, daß der Reset rechtzeitig wirksam wird, noch bevor der Controller anfängt Müll zu machen.
c-hater schrieb: > Könnte ein Brownout sein. [längliche Erklärung gesnipt] Das könnte man ganz einfach überprüfen, indem man den µC ausliest und mit dem Original .hex vergleicht. Bzw. falls die Programmierumgebung das kann, gleich ein Verify mit dem Original machen. XL
Axel Schwenke schrieb: > Das könnte man ganz einfach überprüfen, indem man den µC ausliest und > mit dem Original .hex vergleicht. Den Brown Out kann man denke ich ausschließen. Wenn ich das Flashfile per ISP neu reinschreibe ist ja noch das gleiche verhalten da. Erst wenn das alte Flashfile geschrieben wird tut es wieder. Ich bin dieses Wochenende aber nicht mehr zuhause, so das ich mich erst nächste Woche daran machen werde den Code zu reduzieren. Ich hoffe der Abstand tut mir gut, war heute nachmittag ganz schön genervt! :-( Danke schonmal für die vielen Tips!
... ist doch ganz klar: In Zeile 42 von Modul 5 wird eine Variable nicht richtig initialisiert. Darüber hinaus würde ich R10 etwas niedriger wählen. Meine Glaskugel ist aber leicht beschlagen.
Dennis schrieb: > Nach dem ausschalten startet die Schaltung nicht mehr. Bei mir passiert das immer wenn ich das TTL-Signal vom USB-> TTL-Wandler angeschlossen lasse. Gruß Anja
Hallo Anja, ja das kann ich auch bestätigen und tritt leider bei einem aktuellen Projekt mit m162 immer auf. RXD (TTL) hat auch einen Pullup erhalten.
Hallo, selbst wenn Daten dauerhaft verändert werden, die Init-Sequenz muss so gestaltet sein, dass das System unter allen Umständen starten kann. Da hilft eigentlich nur, den Ablauf logisch Schritt für Schritt durchzugehen, ob wirklich alles initialisiert wird und ob es denkbare Dateninhalte gibt, die ein Starten verhindern. Auch wenn es mühsam ist, sonst müsste man einen LA haben der den gesamten Startvorgang aufzeichnen kann. Man kann ja einen PC per BIOS-Einstellungen so versauen, dass die Hardware nicht mehr funktioniert, aber selbst dann stellt sich der PC spätestens beim nächsten Start auf erprobte Standard-Einstellungen zurück - wenn das BIOS sauber programmiert ist. So sollte das bei jedem System sein. Dauerhaft gespeicherte Daten, die einen Neustart verhindern, darf es keinesfalls geben. Gruss Reinhard
Ich hatte neulich mal einen hartnäckigen Fehler. Die Symptome waren wirr. Manchmal schien es, als liefe der µC kurz nach den ersten Initialisierungsschritten in einen Reset. Machmal lief auch die Hauptschleife, aber die Debug-Ausgabe über UART klappte nur bei zwei Schleifendurchläufen, dann zwei Durchläufe nicht, dann wieder von vorne, obwohl die Diagnose-LEDs eigentlich auf keine Störung schließen ließen. Durch Zufall bemerkte ich, dass der Reset-Knopf oft zu einem anderen Ergebnis führt als ein Power-Cycle. Selbstverständlich habe ich auch mal den µC ausgetauscht und die Schaltung komplett neu aufgebaut. Natürlich hat alles nichts geholfen. Die Ursache der Probleme war - wie sollte es anders sein - vollkommen unspektakulär: Ich hatte bei der Anpassung meines Makefile-Templates an das Projekt es fertiggebracht das -mmcu=atmega328p nur beim Kompilieren, nicht aber beim Linken einzubauen. Jetzt mit verbessertem Template passiert mir das nicht mehr - hoffentlich!
Uwe S. schrieb: > ja das kann ich auch bestätigen und tritt leider bei einem aktuellen > Projekt mit m162 immer auf. > > RXD (TTL) hat auch einen Pullup erhalten. Das Problem tritt dadurch auf daß der ATMEGA durch die TTL-Spannung halblebig versorgt wird. Es tritt also kein richtiger RESET auf. Gruß Anja
Anja schrieb: > Das Problem tritt dadurch auf daß der ATMEGA durch die TTL-Spannung > halblebig versorgt wird. Es tritt also kein richtiger RESET auf. Was ist denn aus den guten alten Resettastern geworden? Gruss Reinhard
Reinhard Kern schrieb: > selbst wenn Daten dauerhaft verändert werden, die Init-Sequenz muss so > gestaltet sein, dass das System unter allen Umständen starten kann. Wenn nun die dauerhaft veränderten Daten ausgerechnet der Code der Init-Sequenz oder irgendeiner ISR sind? Dann fällst du mit deinem absolut nicht durchdachten Ansatz gnadenlos auf die Schnauze. > Man kann ja einen PC per BIOS-Einstellungen so versauen, dass die > Hardware nicht mehr funktioniert, aber selbst dann stellt sich der PC > spätestens beim nächsten Start auf erprobte Standard-Einstellungen > zurück - wenn das BIOS sauber programmiert ist. Auch dort gibt's das gleiche Problem. Wenn z.B. das RAM, in den das BIOS aus dem seriellen Flash geladen wird, eine Macke halt... > System sein. Dauerhaft gespeicherte Daten, die einen Neustart > verhindern, darf es keinesfalls geben. Das wird aber schwierig. Code ist schließlich nix anderes als dauerhaft gespeicherte Daten.
Reinhard Kern schrieb: > Was ist denn aus den guten alten Resettastern geworden? Das macht man heutzutage automatisiert mit dem Flash-Tool. Dennis schrieb: > Wenn ich das neue flashe, tut dies auch für unbestimmte > Zeit wieder. Gruß Anja
c-hater schrieb: > Dann fällst du mit deinem absolut nicht durchdachten Ansatz gnadenlos > auf die Schnauze. So ein Blödsinn, es geht z.B. um Parameter - und nicht um selbstmodifizierenden Code. Natürlich kann ein PC-BIOS sich nicht selbst reparieren, sehr wohl aber falsche Parameter zurücksetzen. Aber das war für entschieden zu hoch. Auch beim vom TO beschreibenen Problem ist die Vermutung absurd, das der Fehler darauf beruht, dass sich beim Resetten die Firmware verändert. Gruss Reinhard
Du hat sporadisch nach dem Einschalten, aber nicht nach dem Flashen oder sonstigem Reset das Problem? Hat das Display beim Powerup genug Zeit, bis die Init-Sequenz kommt? Zu schnelles Ansprechen des Displays würde ja in dem Fall nur nach dem Ausschalten oder genauer nach dem Einschalten auffallen, während es nach einem Reset dann normal täte.
Reinhard Kern schrieb: > So ein Blödsinn, es geht z.B. um Parameter - und nicht um > selbstmodifizierenden Code. Ein Brownout kann (natürlich ungewollt) Code zu selbstmodifzierendem Code machen. Das geht immer dann, wenn der Code in einem Speicher steckt, der zur Laufzeit modifizierbar ist. Flash gehört zu dieser Kategorie. Das genau ist, was du scheinbar nicht zu begreifen vermagst. > Natürlich kann ein PC-BIOS sich nicht selbst > reparieren Es ist noch viel Schlimmer: Es kann nichtmal selbst zuverlässig erkennen, daß es beschädigt ist. Weil nämlich schon die Testroutine selber beschädigt sein kann. Und wieder: Das genau ist, was du scheinbar nicht zu begreifen vermagst. > Auch beim vom TO beschreibenen Problem ist die Vermutung absurd, das der > Fehler darauf beruht, dass sich beim Resetten die Firmware verändert. Natürlich nicht. Beim Resetten wird die Firmware ganz sicher nicht verändert, jedenfalls solange der Code selber keine Routinen zur Firmware-Manipulation enthält (z.B. einen Bootloader), die durch einen Reset zur Unzeit unterbrochen werden könnten. Bei einem unkontrollierten Powerdown hingegen ist das aber grundsätzlich immer möglich. Genau das ist ja das besonders fiese am Brownout. Er kann bleibende Schäden am Code anrichten, auch wenn dieser eigentlich überhaupt keinen Code zur Firmwaremanipulation enthält. Ob das hier in Frage kommt, ist nach den bisherigen Einlassungen des OP schlicht nicht entscheidbar. Er betreibt aus unerfindlichen Gründen leider keine sinnvolle Strategie zur Fehlereingrenzung, obwohl es wirklich einfach wäre, Brownout-Effekte als Ursache zuverlässig auszuschließen. Man bräuchte doch im sichtbaren Fehlerfall nur das Image aus dem Controller lesen und mit dem Sollimage zu vergleichen... Keine Ahnung, warum er das nach zwei Dutzend Postings im Thread noch nicht auf die Reihe bekommen hat und statt dessen nach der "es kann nicht sein, weil es nicht sein darf"-Methode diesen Mechanismus als Ursache ausschließt. Wenn es eine einfache Methode gibt, eine ganze Fehlerklasse zuverlässig als Ursache auszuschließen, dann benutzt man die. Alles andere ist nur eins: völlig idiotisch. Wenn er einfach das Sinnvolle getan hätte, bräuchten wir uns nicht mehr über Möglichkeiten zu streiten.
Wenn möglich, den BOR aktivieren, das verhindert schonmal einen amok laufenden Programmcounter. Ansonsten ist irgendeine Initialisierung unvollständig. Beim AVR gerne gemachter Fehler, das SPI initialisieren, bevor /SS als Ausgang gesetzt ist. Oder Eingänge als volle 8Bit abzufragen, anstatt nur den gewünschten Pin.
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.