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,
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.
