Guten Tag zusammen, ich habe ein Programm geschrieben welches mittlerweile recht groß geworden ist. Nur habe ich ein großes Problem nach 2-4 Monaten hängt sich vermutlicherweise der Controller auf. Folgendes zum Aufbau. Mit dem Controller werden ein paar Pumpen und Ventile, über ein LCD mit Menu, geschaltet. Doch irgendwann nach einer großen Zeitspanne hängt sich der Controller auf und schaltet alles aus und auf dem Display werden Nur Hyroglyphen angezeigt. in den Letzten 12 Monaten ist das 3 Mal passiert :( Ich habe nun mal zusätzlich einen Watchdog in die Software implementiert um irgendeine blöde Sache abzufangen wo sich die Controller aufhängen würde und das er sich einfach resetet. Es ist auch immer Passiert wenn keiner in der Nähe war - das heisst es hat keiner irgendwelche tasten gedrückt oder sonst irgendwas. Es gab auch KEINEN spannungsausfall das kann ich mit 100%tiger sicherheit sagen. Desweiteren kann es auch nicht wirklich ein reset sein denn dann würde das Display ja ganz normal initialisiert werden. Wie könnte ich nun am besten rausfinden woran es liegt? Könnte ich vieleicht einem Stack Overflow zum Opfer fallen? so das er mir quasi in mein Ram schreibt und dann irgendwas überschreibt? Das Programm ist leider zu groß um es hier rein zu posten. Aber vieleicht hat ja jemand einen Lösungseinsatz?! Ich würde mich riesig freuen. Schönen Gruß
Poste dein Programm doch als Anhang, sonst können wir nur rätselraten... Hast Du eigentlich den BrownOut-Detector an?
>> nach 2-4 Monaten hängtsich vermutlicherweise der Controller auf
Nicht ungewöhnlich!
=> Watchdog ist das Zauberwort. Entweder im Controller oder ein
externer WD.
Genau dafür sind die WauWau's
Juppes
Hallo, ein Stack-Problem ist oftmals der Fall bei sporadischen Ausfällen. Genauso gut kann es aber auch sein, dass deine Schaltung empfindlich gegen EM-Strahlung ist und dann aussteigt... das könnte man feststellen, wenn man die Schaltung absichtlich solcher Strahlung aussetzt (z.B. Relais als Summer ohne Funkenlöschung...) Auch möglich sind Störungen von außen (über die Betriebsspannung). Bei Software-Problemen wird es eklig. Evtl. kannst du die Software im "Zeitraffer" ablaufen lassen? Oder im Simulator laufen lassen und schauen, was der Stack so macht. Mit einem Watchdog sollte das Problem erstmal gelöst sein - wenn damit auch nur die Symptome bekämpft werden und nicht die Ursache. Viel Erfolg bei der Suche...
Ich weiss nicht ob das Programm veröffentlich werden darf - ist zwar komplett von mir geschrieben - aber gerade auch kein vorgesetzter da den ich fragen könnte. Brown Out ist an, aber wie gesagt einen spannungseinbruch kann ich zu 99,9 Prozent ausschließen weil diese mehrfach überwacht und mitgeloggt wird. Ja einen Watchdog habe ich nun aktiviert und eingebunden. Nur muss ich jetzt erstmal wieder 2-4 Monate warten :(. Gibt es eine Möglichkeit in der Simulation vom AVR Studio die Zeit extrem zu beschleunigen? also quasi 1 Tage in einer Sekunde ? Dann könnte ich ja mal die Simulation laufen lassen und gucken ob es dort auch passiert.
Juppes schrieb: >>> nach 2-4 Monaten hängtsich vermutlicherweise der Controller auf > > Nicht ungewöhnlich! Eigentlich schon. So ein Controller sollte sich aus Softwaregründen nie aufhängen! Mein Mega in der Heizungssteuerung läuft jetzt seit ich ihn eingebaut habe durch. 24 Stunden am Tag, 7 Tage die Woche ... seit 2.5 Jahren. > => Watchdog ist das Zauberwort. Entweder im Controller oder ein > externer WD. Ein Watchdog sollte aber nicht dazu missbraucht werden, Software Fehler zu ignorieren. Wenn es einen Programmfehler gibt, dann muss man den korrigieren, den Fehlschaltung aufgrund erster Fehlfunktionen im Programm kann auch ein Watchdog nicht verhindern. Aus Softwaresicht ist ein Watchdog das letzte Bollwerk, wenn sonst gar nichts mehr geht.
Karl Heinz Buchegger schrieb: > Aus Softwaresicht ist ein Watchdog das letzte Bollwerk, wenn sonst gar > nichts mehr geht. Ja das sehe ich auch so, habe ihn nun erstmal verwendet um erstmal in einen Sicheren Zustand zu kommen, da es ja anscheinend einen Software Fehler gibt. Die Frage ist nur wie ich Ihn am Besten finde :/
So sporadische Fehler sind schwer zu finden, kenne das. Manche µC bieten die Möglichkeit festzustellen wer z.B. Reset ausgelöst hat (Watch-Dog, Brown out, Power-On etc.) siehe Datenblatt, einfach diese Ereignisse registrieren (z.B. im EEPROM mitzählen) und Auswerten. Hilft manchmal bei der Suche nach der Ursache weiter. Würde für Testzwecke auch mal das RAM mit einem bestimmten Wert pro Byte (z.B. 0x5A) laden, aber jede Zelle mit dem gleichen Wert. Nach einiger Betriebszeit -ohne über Reset zu gehen- RAM auslesen. Gibt es noch ein paar 0x5A Bytes die direkt aufeinander folgen? Je mehr, desto besser.
Das Problem ist ja irgendwie das er nicht so wirklich resetet wird. Denn nach einem Brown Out oder Power-On Reset oder meinet wegen auch nach einem Strom - AUS / AN Reset sollte er ja wieder quasi im ersten Menu sein und das Display zeigt normale Sachen an. Aber das 4 Zeilen 20 Zeichen Display ist Komplett mit Hyroglyphen vollgeschrieben also nicht nur Zeile 1 und 3. Ich meine mich auch Daran zu errinnern das Wenn man eine Taste gedrückt hat um durchs Menue zu Scrollen das dann irgendwas hyroglyophen mässiges auf das LCD geschrieben wurde. /EDIT Achja ich habe den Watchdog ja jetzt implementiert und natürlich WENN dieser auslöst dann bekomme ich das in der Hauptschleife mitgeteilt das seit dem letzten normalen Start der Reset ausgelöst wurde.
Karl Heinz Buchegger schrieb: > Ein Watchdog sollte aber nicht dazu missbraucht werden, Software Fehler > zu ignorieren. Sagt die Theorie. Bloss lassen sich Fehler, die nur alle paar Monate sporarisch auftreten, mitunter derart schwer eingrenzen, dass als Notwehr nur der Watchdog praktikabel ist. Freilich sollte man beides anpeilen. Neben dem Watchdog noch ausreichend detailfreudige Protokollierung in einen round-robin Speicher, um ggf. den Ablauf nachvollziehen zu können. Nach einen WD-Reset wird der dann eingefroren und kann zur Analyse verwendet werden.
Softwareseitig könntest du deinen Quellkode mit statischen Analyse-Werkzeugen überprüfen: Z.B. splint? Passt es mit dem Stack? Gibt es vielleicht irgendwelche Compiler/Linker-Warnungen?
Kann sollte auch mal prüfen, ob man grundlegende Reglen bei der Programmierung eingehalten hat. Beliebte Stolperfallen, nicht nur für Anfänger, sind Zugriffsfehler bei Variabeln, die im Hauptprogramm und in Interrupts genutzt werden, Stichwort volatile und atomar. BEIDES muss erfüllt sein. Pufferüberläufe durch falsche, nicht geprüfte Parameter in Funktionen sind auch sehr "beliebt". >Achja ich habe den Watchdog ja jetzt implementiert und natürlich WENN >dieser auslöst dann bekomme ich das in der Hauptschleife mitgeteilt das >seit dem letzten normalen Start der Reset ausgelöst wurde. Da hast du glaub ich was falsch umgesetzt. WENN der Watchdog zuschlägt, gibt es einen Reset. In den meisten Controllern kann man per Register auslesen, was die Resetursache war. Das macht man direkt beim Programmstart. Im Fehlerfall (Watchdogreset), zeigt man eine Fehlermeldung an und das Programm bleibt stehen. Man kann, je nach Hardware, auch die aktuelle Zeit anzeigen, bei der der Watchdogreset auftrat. Damit muss man nicht immer neben der Kiste stehen, sondern es reicht, einmal die Woche nachzuschauen. HighTec Enthusiasten verschicken im Fehlerfall eine SMS per Handmodul. MfG Falk
Falk Brunner schrieb: > Im Fehlerfall (Watchdogreset), zeigt man eine > Fehlermeldung an und das Programm bleibt stehen. Das würde ich beispielsweise bei einer Heizung lieber nicht so machen. Sonst darfst du, wenn du Pech hast, nach dem Urlaub sämtliche Heizkörper und Rohrleitungen auswechseln. ;-) > HighTec Enthusiasten verschicken > im Fehlerfall eine SMS per Handmodul. Hatte ich mir auch überlegt, aber ein kleiner Webserver erschien mir praktischer. Insbesondere wenn man bei 23°C am Urlaubsort auf dem Phone zusehen kann, wie die Leute zu Hause bei -10°C frieren. ;-)
Nein stehen bleiben darf das Programm nach einem Watchdog Reset auf gar keinen Fall. Ich speicher im EEPROM zu ausgewählten Momenten diverse Stati-Meldungen. Anhand dieser Meldungen wird nach einem Reset das Gerät wieder in den letzt bekannten Zustand gefahren.
Naja Folgendes : 1. Wenn du ne keine Taste drückst und sich nichts auf dem Display ädert. 2. Du ne Taste drückst und sich auf dem Display genau dann was ändert. Dann scheint er ja noch sein Program auszuführen aber sendet falsche Daten ans Display. Die Tasten werden ja auch ausgewertet. Das würde bedeuten das ecventuel auch noch der Watchdog resetet wird. Da die Tasten warscheinlich hart is flash als Konstanten compiliert sind scheint alles was aus dem flash kommt noch (einigermaßen) zu funktionieren. Also ich würde auf RAM inhalt zerstört Tippen. Wenn du den Spannungseinbruch wirklich ausschließen kannst würde ich auch auf den Stack tipppen (irgendwo nen pop vergessen in einer Funktion die nicht sooft ausgeführt wird so alle 3-4 Monate).
Die vom TO geschilderten Probleme laufen zu 90% auf Fehler bei atomaren Zugriffen (schon erwähnt) oder ungültige Array-Indizierung hinaus. Alternativ kann dann auch noch der Stack zu groß werden.
A. K. schrieb: > Karl Heinz Buchegger schrieb: > >> Ein Watchdog sollte aber nicht dazu missbraucht werden, Software Fehler >> zu ignorieren. > > Sagt die Theorie. Bloss lassen sich Fehler, die nur alle paar Monate > sporarisch auftreten, mitunter derart schwer eingrenzen, dass als > Notwehr nur der Watchdog praktikabel ist. Wenn das der Fall ist, dann ist, mit Verlaub gesagt, der Programmierer ein dummer Hund. Klar lassen sich solche Fehler nur schwer finden. Und es gibt Fehler die sind lange Zeit gut versteckt. Ich hatte letzte Woche einen Fehler zu tracken. Nach einem halben Tag hatte ich die vergessene Epsilon Abfrage bei einem Floating Point Vergleich entdeckt. Das Programm hat einen Wert von -9E-17 als negativ klassifiziert (anstelle von 0) und daher komplette Geometrieaufbauten in die verkehrte Richtung durchgezogen. Ich hab den Code dazu mit Sicherheit mehr als 30 mal durchgesteppt (der Bereich um den es da ging umfasst ca. 8000 bis 10000 Lines of Code), in wechselnden Aufrufhierarchietiefen, bis ich dann endlich so tief unten war, dass in der 10-ten oder 12-ten Hierarchiestufe, in den Basisroutinen die zu einer Kontur eine bestimmte Parallelkontur berechnen, das Problem offen dalag. Der Code war datiert mit September 1993 (kein Scherz. Der Bug war seit 19 Jahren im Code ohne dass er auffiel. Ich hatte das Pech/Glück beim Testen auf eine bestimmte Geometriesituation zu stossen, bei der er sich erstmals auswirkte). Es hilft aber nichts. Wenn es ein Softwarefehler ist, dann muss er gefunden werden. Und anschliessend muss man überlegen, wie es dazu gekommen ist und für die Zukunft lernen, wie man seinen Code so aufbaut, dass einem dieser Fehler nicht mehr passiert. Alles andere ist Amateurvorgehen. Und zumindest für mich nicht tolerierbar.
Karl Heinz Buchegger schrieb: > Und zumindest für mich nicht tolerierbar. Im Prinzip ja richtig. Aber was tun wenn ein Kunde die Sachen gleich haben will ? Wer testet denn ein System monatelang um solche Sachen zu finden ? Alleine die Entscheidung Soft- oder Hardwareproblem ist sehr schwierig.
Warum denn keinen Not-(Watchdog-) Reset ? Ist es ein Flugzeug ? Ich hatte vor längerer Zeit mal eine Telefonanlage (eines renomierten, noch aktiven Herstellers). Das Teil war ganz neu --zu neu--. Es hat seinen eigenen Flashspeicher (Programmbereich) überschrieben durch seine wohl damals noch fehlerhafte "EEPROM" Emulation. Immer nach einigen -zig Betriebsstunden trat das auf. Totaler Hänger der Anlage. Der Hersteller hatte auf die Schnelle keine neue SW. Die Hotline sagte: Nehmen Sie eine Schaltuhr, stellen diese Nachts auf 03:30 und nehmen damit für 5 Minuten die Netzspannung weg. Diese Lösung hat prima funktioniert! Gruss
Joachim Drechsel schrieb: > Karl Heinz Buchegger schrieb: >> Und zumindest für mich nicht tolerierbar. > > Im Prinzip ja richtig. > > Aber was tun wenn ein Kunde die Sachen gleich haben will ? Wer testet > denn ein System monatelang um solche Sachen zu finden ? Brauchst du mir nicht sagen. Aber die Methode "da kleben wir ein Pflaster drüber" ist nun mal keine adequate Methode um Rostlöcher in der Karosserie zu 'beheben'. Ausnahmslos jede Nachlässigkeit, die ich mir in der Vergangenheit zu schulden kommen habe lassen, aber wirklich jede einzelne, sei es ein Designfehler von dem ich wusste, sei es eine lasche Implementierung, sei es Abfrage von Fehlersituationen die ich auf 'später' verschoben habe, egal was ... jede einzelne dieser bewussten Nachlässigkeiten ist mir irgendwann auf den Kopf gefallen. Der einzige Unterschied im Vergleich zum Zeitpunkt des Nichtbehandelns ... alles war danach nur noch schlimmer zu beheben. > Alleine die Entscheidung Soft- oder Hardwareproblem ist sehr schwierig. Schon klar. Aber unter den Tisch kehren ist keine Lösung. Gebranntes Kind scheut das Feuer.
Karl Heinz Buchegger schrieb: > Ausnahmslos jede Nachlässigkeit, die ich mir in der Vergangenheit zu > schulden kommen habe lassen, aber wirklich jede einzelne, sei es ein > Designfehler von dem ich wusste, sei es eine lasche Implementierung, sei > es Abfrage von Fehlersituationen die ich auf 'später' verschoben habe, > egal was ... jede einzelne dieser Nachlässigkeiten ist mir irgendwann > auf den Kopf gefallen. Der einzige Unterschied zum Zeitpunkt des > Nichtbehandelns ... alles war danach nur noch schlimmer. Äm ... ja ... (ich weiß, ist auch meine Erfahrung). Dazu kommen aber wieder mal die lieben Kunden. Meist "muß es gestern fertig sein", ständig kommen Änderungswünsche oder man haut ihnen mal schnell ein Muster zusammen was sie dann nicht mehr herrausrücken. Ich habe da das "Glück" immer Zugriff auf die fertigen Sachen zu haben (alles läuft über's Web) und habe da wenigstens noch Möglickeiten einzugreifen und zu korrigieren. Alles austesten ist schlicht nicht möglich. Beispiel: Ich hatte mal einen Datenimport der damals auf einemm 386er mit W311 12,5 Tage (!) ohne Absturz (!!!) gelaufen ist. Crash ? Wie denn da einen Fehler finden ? HW, SW, Windows ? Hmmm ...
Karl Heinz Buchegger schrieb: > dass einem dieser Fehler nicht mehr passiert. Alles andere ist > Amateurvorgehen. Und zumindest für mich nicht tolerierbar. Wenn du aber Microsoft heisst und ein Betriebssystem programmierst, dann kannst du vor dem Dilemma stehen, dass in den 19 Jahren seither hunderte Programmierer den Bug im API oder der Lib bereits gefunden haben und die Macke in den eigenen Programmen ausmerzen. Wenn du dann den Bug behebst, dann funktionieren diese Programme nicht mehr, weil sie den Fehler voraussetzen (kein Witz!).
Joachim Drechsel schrieb: > Beispiel: Ich hatte mal einen Datenimport der damals auf einemm 386er > mit W311 12,5 Tage (!) ohne Absturz (!!!) gelaufen ist. Crash ? > Wie denn da einen Fehler finden ? HW, SW, Windows ? Hmmm ... Extrem schwer, da irgendwas zu finden. Ist mir schon klar. Sowas kriegt man nur in den Griff, wenn man von vorne herein bei der Implementierung schon rigoros vorgeht. Jedes Subsystem durchläuft Tests ehe es zum Einsatz kommt. Gerade in C: Jede Stringoperation wird hingeschrieben und gleich danach überlegt: Kann der String zu groß sein, wo kommt er her, ist er dort getestet worden, etc. Dasselbe für Array-Dinge. Möglichst wenig Querverknüpfungen zwischen Codeteilen die unkontrolliert auf Variablen zugreifen (die große Stärke der OOP). Ganz wichtig: sein Werkzeug (die Programmiersprache) wirklich beherrschen und nicht auf in Foren zusammengeschnorrtem 1/4-Wissen sitzenbleiben (wichtig zb für Datentyp-Promotionen. Das sind Dinge, die müssen sitzen!) Wenn man Fehler macht (und wer macht die nicht), nicht danach zum Tagesgeschehen übergehen sondern ein paar Minuten Zeit nehmen: wie ist es dazu gekommen, was kann ich für die Zukunft daraus lernen, wie kann ich den Code so gestalten, dass mir das nicht nochmal passiert? Nur so kriegt man das letzten Endes in den Griff. Und das geht auch nicht von heute auf morgen, ist schon klar. Aber wer nie anfängt, kommt auch nie am Ziel an. Wartbarkeit muss von vorne herein in den Code eingebaut sein. In einem sauber aufgebauten modularen System ist das schon zu knacken. Programme auf einem µC sind ja nicht so dermassen groß, dass man sie nicht noch einigermassen überblicken könnte.
A. K. schrieb: > Karl Heinz Buchegger schrieb: > >> dass einem dieser Fehler nicht mehr passiert. Alles andere ist >> Amateurvorgehen. Und zumindest für mich nicht tolerierbar. > > Wenn du aber Microsoft heisst und ein Betriebssystem programmierst, dann > kannst du vor dem Dilemma stehen, dass in den 19 Jahren seither hunderte > Programmierer den Bug im API oder der Lib bereits gefunden haben und die > Macke in den eigenen Programmen ausmerzen. Wenn du dann den Bug behebst, > dann funktionieren diese Programme nicht mehr, weil sie den Fehler > voraussetzen (kein Witz!). Genau das ist einer der Punkte, die ich mit ".... danach ist alles nur noch schlimmer" gemeint habe. Denkst du, das ist mir noch nie passiert, dass ich um einen Bug zu beheben, erst mal alle Codestellen finden musste, die auf diesem Bug aufbauen? Alles schon dagewesen. Noch schlimmer ist nur noch: Du kommst drauf, dass du den Bug nicht beheben kannst, weil das komplette Design Scheisse ist. Design kannst du aber nicht ändern, weil alles rundherum darauf aufbaut, dass sich ein Subsystem genau so verhält wie es sich verhält. Und mit dem Design das du hast, ist der Bug systemimanent. Da sitzt du erst recht in der Tinte und schweren Herzens schluckst du die nächste Krot in Form eines halbherzigen Fixes, genau wissend, dass dir genau dieser Fix irgendwann in den nächsten 5 Jahren wieder auf den Kopf knallen wird. Und zum Thema Mikrosoft: Meine persönliche Meinung - das ist der größte Haufen Amateurprogrammierer auf Gottes Erdboden überhaupt. Ein paar gute Köpfe sind schon dabei, aber der überwiegende Anteil der Entwickler ist bestenfalls unterer Durchschnitt.
@ Karl Heinz Buchegger (kbuchegg) (Moderator) >Und zum Thema Mikrosoft: >Meine persönliche Meinung - das ist der größte Haufen >Amateurprogrammierer auf Gottes Erdboden überhaupt. Ein paar gute Köpfe >sind schon dabei, aber der überwiegende Anteil der Entwickler ist >bestenfalls unterer Durchschnitt. Hmm, keine Ahnung. Aber rein praktisch gesehen kann es gar nicht anders sein. In einem Laden dieser Größe KÖNNEN niemals nur Elite-Leute sitzen. Rein statistisch nicht machbar. Wichtig ist wie immer, dass an den kritischen Positionen TOP-Leute sitzen und gute Konzepte erarbeiten bzw. deren Umsetzung überwachen. Die "Drecksarbeit" kann auch der Durchschnitt dann erledigen. Ist keine Abwertung, nur nüchterne Betrachtung der Realität. Die Masse ist nicht zum Nobelpreisträger geboren, ich auch nicht ;-) Es gab mal hir im Forum einen Link auf ein Video einer Präsentation von so einem Softwerker, bissel korpulent. Ging um Extreme Programming etc. Fand ich richtig gut, wenn gleich an einigen Stellen schon sehr selbsbewusst ;-) Finde ich leider nicht mehr. MfG Falk
Karl Heinz Buchegger schrieb: > Sowas kriegt man nur in den Griff, wenn man von vorne herein bei der > Implementierung schon rigoros vorgeht. Jedes Subsystem durchläuft Tests > ehe es zum Einsatz kommt. Subsystem ? Wie soll das funktionieren ? Subsysteme habe ich erst wenn die Idee steht. Ist die schon Murks kann ich mir die Subsysteme sowieso schenken (an der Idee scheitern doch schon die meisten). Programmieren ist eine Bauchsache, die Idee kommt aus dem Gefühl - in den seltensten Fällen aus der Logik. Ich habe da schon einigen gestandenen Informatikern mal die Klemmen zeigen müssen in die sie sich manövriert hatten. Die technische Umsetzung ist das Einfachste. Bis auf meine 8080, 6502 und AVR-Sachen habe ich jetzt noch nicht soviel Erfahrungen mit Mikrocontrollern, ich kann aber aus dem Gefühl heraus ungefähr abschätzen was ich brauche und wie ich an das Problem herangehe. Aber noch BEVOR ich auch nur einen Programmteil schreibe. Da hat man im Lauf der Zeit dann (für sich selbst) gelernt wie man das halbwegs unfallfrei hinbekommt. <bash>Informatiker: A5 - Zettel Millimeterpapier und dann links oben mit einem H5-Bleisift eine Miniatur hinkrakeln. Die können nicht mal mit Papier umgehen. Mann nimmt min A3 und einen fetten Stift ... und fängt in der Mitte an</bash> Ich plädiere für top-down ;)
@ Joachim Drechsel (Firma: JDCC) (scheppertreiber) >Subsystem ? Wie soll das funktionieren ? So wie es die Profis machen (die ihren Namen verdienen). >Subsysteme habe ich erst wenn die Idee steht. Ja und? Das sollte AM ANFANG sein! > Ist die schon Murks >kann ich mir die Subsysteme sowieso schenken Welch Erkenntnis! >(an der Idee scheitern doch schon die meisten). Nö, "nur" an der Umsetzung. >Programmieren ist eine Bauchsache, die >Idee kommt aus dem Gefühl - in den seltensten Fällen aus der Logik. ??? Reden wir über das Gleiche? Programmieren von Sequentiellen, finiten Algorithmen? Mit Bauchsache hat das sehr wenig zu tun, bestenfalls ERFAHRUNG, Wissen und ein Schuß Intuition. >Ich habe da schon einigen gestandenen Informatikern mal die Klemmen >zeigen müssen in die sie sich manövriert hatten. Du Held. >Die technische Umsetzung ist das Einfachste. ;-) Maulheld. Papier ist geduldig, Forumstexte erst recht. >Bis auf meine 8080, 6502 und AVR-Sachen habe ich jetzt noch nicht >soviel Erfahrungen mit Mikrocontrollern, ich kann aber aus dem Gefühl >heraus ungefähr abschätzen was ich brauche und wie ich an das Problem >herangehe. >Aber noch BEVOR ich auch nur einen Programmteil schreibe. Logisch. Jeder der die "Sturm und Drang" Zeit hinter sich hat, macht das. >Da hat man im Lauf der Zeit dann (für sich selbst) gelernt wie man >das halbwegs unfallfrei hinbekommt. Einige lernen es nie wirklich. MfG Falk
Sebastian B. schrieb: > ich habe ein Programm geschrieben welches mittlerweile recht groß > geworden ist. Was Du als einsamer Held ganz allein? Wer hat Dein Design und Deinen Code gereviewt und freigegeben? Welcher (unabhängige) Tester hat das getestet? Du glaubst gar nicht wie schnell ein anderer Bediener Dein Gerät zum Absturz bringen kann wenn da nicht alles sauber designed und codiert ist. Gruß Anja
Hübsch, wie sich der Thread entwickelt hat. Aber ich möchte nochmal zum ersten Beitrag zurückkommen. Auch wenn sich alle gleich auf mögliche Software-Fehler eingeschossen haben (Erfahrungssache?? ;-) ), möchte ich unbesehen Designschwächen der Hardware nicht ganz ausschließen. Sebastian B. schrieb: > Mit dem Controller werden ein paar Pumpen und Ventile, über ein LCD mit > Menu, geschaltet. Doch irgendwann nach einer großen Zeitspanne hängt > sich der Controller auf und schaltet alles aus und auf dem Display > werden Nur Hyroglyphen angezeigt. in den Letzten 12 Monaten ist das 3 > Mal passiert :( Pumpen und Ventile schalten klingt für mich nach Relais oder elektronische Schalter und induktive Lasten. Damit kann man auch viel Spass haben! Gibt es vielleicht noch ein paar mehr Infos zum Design und Aufbau? Woraus wird das Ganze versorgt? Was hängt noch am selben Netz? Wie sehen die Filterschaltungen an Versorgung, Ein- und Ausgängen aus? Haben die Schalter Snubber (Funkenlöschglieder)?
>Du glaubst gar nicht wie schnell ein anderer Bediener Dein Gerät zum >Absturz bringen kann wenn da nicht alles sauber designed und codiert >ist. Korrekt. Der Entwickler bedient das Gerät immer richtig. Man muss den DAU (Dümmsten anzunehmenden User) auf das Gerät loslassen. Der darf gar nicht wissen wie man es bedient. Einfach nur Tasten drücken lassen wie ein Wahnsinniger. >Aber ich möchte nochmal zum ersten Beitrag zurückkommen. Auch wenn sich >alle gleich auf mögliche Software-Fehler eingeschossen haben >(Erfahrungssache?? ;-) ), möchte ich unbesehen Designschwächen der >Hardware nicht ganz ausschließen. Kann man im Moment halt nicht sagen was da passiert ist. Display abgefault könnte ESD sein. Controller abgeschmiert auch ESD, aber möglicherweise auch irgendwo ein Stackoverflow. Oder irgendein Zähler läuft nach drei Monaten über. Den dann als Index für ein Array und bumm. Wirkt sich mit hoher Wahrscheinlichkeit auch auf die Displayausgabe aus.
holger schrieb: > Kann man im Moment halt nicht sagen was da passiert ist. > Display abgefault könnte ESD sein. Es ist ja nicht nur das Display sondern auch die Lasten sind ausgeschaltet. -> das ganze klingt für mich wie Brown out mit für Display und Prozessor unterschiedlichen Schaltschwellen bzw. unterschiedlichem Timing. Gruß Anja
Handelt es sich um ein 8 Bit Prozessor? Solche Fehler sind dann typisch, wenn Variablen > 8 Bit also (u)int16 oder (u)int32 im Hauptprogramm und in einem Interupt verwendet werden. Und zwar dann, wenn man mit dem Wert im Hauptprogramm arbeitet - ohne vorher den entsprechenden IRQ zu sperren. Man muss sich nämlich im klaren sein, dass es sich um einen 8bit Prozessor handelt und 16 oder 32bit Operationen mehrere Zyklen brauchen, die durch den IRQ unterbrochen werden könnten. Dies tritt dann aber meist sehr selten auf und das macht es so schwierig. Beispiel: x= 0x2FFF wird dieser Wert in der Hauptschleife inkrementiert, so geschieht dies in zwei Schritten: x=0x2F00 x=0x3000 wird dies durch den IRQ zwischendurch unterbrochen, so ist x im Interrupt 0x2F00. Also einen Wert, den man nicht erwarten würde.
Ich hatte mal den Fall, dass ein LCD ala HD44780 partou bei einem Relaisschaltereignis das Licht ausging. Der angeschlossene AVR lief problemlos. Filtern und schirmen zeigten keine Wirkung. Was tun? Ich hab es sekündlich neu initialisiert, fällt nicht auf, man überschreibt ja alles. Aber der hinweis ist schon richtig, es kann die Hardware mit EMV Problemen sein. Also einfach mal die Relais deutlich öfter schalten lassen. Vielleicht erwischt man den Fehler dann nach Minuten oder Stunden, anstatt Monaten. MFG Falk
@ Fabian (Gast) >Solche Fehler sind dann typisch, wenn Variablen > 8 Bit also (u)int16 >oder (u)int32 im Hauptprogramm und in einem Interupt verwendet werden. Hatten wir schon mehrfach erwähnt. Ist auch im Link erklärt. Beitrag "Re: Controller hängt sich nach sehr langer Zeit auf Ursache?"
Falk Brunner schrieb: > Hatten wir schon mehrfach erwähnt. Ist auch im Link erklärt. Sorry, hatte ich übersehen
@Sebastian Gibt es einen Systemzustand, bei dem man schadlos absichtlich den Watchdog auslösen kann? Das System sollte sich dadurch wieder einfangen, der "Monatstimer" auf Null gesetzt werden. Das gibt einem die Zeit, nach dem wirklichen Problem zu forschen. MfG Klaus
>Es ist ja nicht nur das Display sondern auch die Lasten sind >ausgeschaltet. >-> das ganze klingt für mich wie Brown out mit für Display und Prozessor >unterschiedlichen Schaltschwellen bzw. unterschiedlichem Timing. Sagen wir einfach mal die Schaltung hat keine ESD Probleme. Ist schon relativ wahrscheinlich weil sie drei Monate durchläuft. Da stell ich mir jetzt einfach einen langsamen Zähler vor der einmal am Tag hochgezählt wird. Jetzt kommt der Zähler an einen Punkt wo er einen zulässigen Wert überschreitet und die Software fängt das nicht ab. Dann läuft evtl. ein Pointer Amok im RAM und alle beschriebenen Symptome können auftreten.
holger schrieb: > Kann man im Moment halt nicht sagen was da passiert ist. ...weshalb ich ja auch nach mehr Details fragte. Aber die muss wohl eher der OP bringen...
Hallo, mal ne Frage: Ist das LCD ein Standard-LCD, das per 4-Bit Modus angesteuert wird? Theorie: Beim 4-Bit Modus könnte es passieren, dass die Synchronität verloren geht und dann irgendwann Low/High-Nibble vertauscht sind. Das könnte die Hieroglyphen erklären und dass das Gerät noch auf Tastendruck reagiert. Ursache könnte ein knappes Timing sein - oder auch ein Interrupt, der einen nicht-atomaren Zugriff unterbricht. Hast du noch Fotos von den Hieroglyphen? Evtl. kann man anhand der Code-Tabelle nachvollziehen, ob diese Theorie zutreffen könnte.
Guten Morgen, So nun habe ich auch wieder Internet und ich Versuche mal mehr Licht ins Dunkle zu bringen. Schonmal vorab vielen Dank für die ganzen Antworten und Lösungsvorschläge. Kurze Beschreibung: Über zwei Pumpen(3-phasig) und Ventile(24VDC) soll in einem Kasten ein Hochvakuum gepumpt werden. Softwarebeschreibung: Die Pumpen und Ventile sind so veriegelt das man keine doofen Zustände erreicht werden können ;). Desweiteren, die Pumpen sind Wassergekühlt - Sollte das Kühlwasser ausfallen, dann erkennt es der µC und schaltet die Pumpen ab und solche Dinge. Ich benutze 2 Timer einen Timer um Tasten einzulesen und einen um diverse Zustände (Kühlwasser, Stellungen der Ventile etc. einzulesen) und LED anzuzeigen. zum Hardware Aufbau: Es gibt einen Zentralen Trafo 24V / 80A aus diesem erzeuge ich mir mit einem DCDC Wandler meine 5V für den µC die Ventile Schalte ich über eine Doppelte galvanische Trennung (Optopkoppler und einem Relais zum durchschalten der 24V zum Relais) Die Pumpen schalte ich über ein Schütz an welches ebenfalls über einen Optopkoppler und einem Relais geschaltet wird. Zu den Fehlermöglichkeiten: Brown Out: Dieser ist auf 2,7 Volt gesetzt - ich habe aber mal probeweise die Versorgungsspannung so runtergedreht das ich bei ca. 2,4V bin. Der µC arbeitet problemlos weiter nur das Display ist nicht mehr lesbar -> da zu wenig Spannung. Wenn ich die Spannung aber wieder hochdrehe kann man das Display auch wieder ablesen. Also man sieht keine Störung. Erst wenn ich unter 2,0 Volt komme scheint der µC sich zu resetten, weil wenn dann die spannungwieder hochgedreht wird dann sieht man das der µC Controller gerade neugestartet hat den ich kann in einem Menupunkt die momentane Programmlaufzeit sehen. Wie ich oben schon geschrieben habe - das ich 2 Timer benutze - Gibt es einen Blöden Fall ich hantiere im Timer 1 mit einem 32 bit wert für die Programmlaufzeit - was passert wenn während dessen der andere Timer auch einen Interrupt auslöst? Stören die sich eventuell gegenseitig? Ein Timer läuft mit 10ms (Taster) und einer mit ca. 150ms (Einlesen der Zustände, Programmlaufzeit, Uhr und sowas) Ich schicke das erstmal ab sonst ist das soviel Text.
Sebastian B. schrieb: > Wie ich oben schon geschrieben habe - das ich 2 Timer benutze - Gibt es > einen Blöden Fall ich hantiere im Timer 1 mit einem 32 bit wert für die > Programmlaufzeit Dieser unverständlich der Satz. Wenn du auf mögliche gleichzeitige Interrupts anspielst: Die werden ggf. nacheinander ausgeführt. Sowas gibt nur Ärger, wenn man - wie manche Leute gerne aber falsch tun - in ISRs längere Warteschleifen einprogrammiert.
> Brown Out: Dieser ist auf 2,7 Volt gesetzt - ich habe aber mal > probeweise die Versorgungsspannung so runtergedreht das ich bei ca. 2,4V > bin. Der µC arbeitet problemlos weiter Wie kann das sein bzw. macht dich das nicht stutzig? Hast du vielleicht nur den Level gesetzt (BODLEVEL) und vergessen den Brownout zu enablen (BODEN)?
@Sebastian B. (sebastian86) >Kurze Beschreibung: Über zwei Pumpen(3-phasig) und Ventile(24VDC) soll >in einem Kasten ein Hochvakuum gepumpt werden. Klingt eher einfach. >Ich benutze 2 Timer einen Timer um Tasten einzulesen und einen um >diverse Zustände (Kühlwasser, Stellungen der Ventile etc. einzulesen) >und LED anzuzeigen. Klingt eher Overkill. >zum Hardware Aufbau: Es gibt einen Zentralen Trafo 24V / 80A aus diesem 80A? Sauber! >erzeuge ich mir mit einem DCDC Wandler meine 5V für den µC die Ventile >Schalte ich über eine Doppelte galvanische Trennung (Optopkoppler und >einem Relais zum durchschalten der 24V zum Relais) Käse. Die Relais reichen. Und die Störungen kommen am Ende sowieso anders in den uC als du denkst. Snubber an den Relaiskontakten? >Die Pumpen schalte ich über ein Schütz an welches ebenfalls über einen >Optopkoppler und einem Relais geschaltet wird. >Brown Out: Dieser ist auf 2,7 Volt gesetzt - ich habe aber mal >probeweise die Versorgungsspannung so runtergedreht das ich bei ca. 2,4V >bin. Der µC arbeitet problemlos weiter nur das Display ist nicht mehr Dann ist der brown out nicht aktiv. >Wie ich oben schon geschrieben habe - das ich 2 Timer benutze - Gibt es >einen Blöden Fall ich hantiere im Timer 1 mit einem 32 bit wert für die >Programmlaufzeit - was passert wenn während dessen der andere Timer auch >einen Interrupt auslöst? Wenn man es richtig macht, gar nichts. >Stören die sich eventuell gegenseitig? Ein >Timer läuft mit 10ms (Taster) und einer mit ca. 150ms (Einlesen der >Zustände, Programmlaufzeit, Uhr und sowas) Gähn, der arme Mikrocontroller langweilt sich zu tode. Das kann man spielend mit einem Timer machen, der halt mit 10ms läuft. Dann verringet sich auch die Gefahr von Race Conditions. MFG Falk
Mit dem BOD Sorry da habe ich mich falsch ausgedrückt bzw was vergessen. WENN! der Brown Out aktiviert ist und die Schwelle auf 2,7V gesetzt ist dann reagiert dieser natürlich. Aber da ich mir da nicht so sicher war und ich einfach wissen wollte wie weit die Spannung zusammen brechen darf habe den BO einfach mal deaktiviert und die Spannung runter gedreht. so sind diese Werte entstanden. Der Brown Out funktioniert also korrekt. Zu den Timern: Dort habe ich keine Warteschleifen Programmiert. der 10ms Timer braucht laut Simulation 7,33µs für einen Durchlauf und der ~150ms Timer braucht 72µs. @ Falk. Trafo Jo 80A sind 2 Redundante Systeme 2 Trafos á 80A sollte einer Ausfallen kommt sofort der nächste zum tragen "ohne" verlust der Versorgungspannung Ja an den Relais sind Snubber verbaut. Natürlich es ist keine Hochkomplexe Aufgabe. Es muss nur auf ein paar Zustände geachtet werden und dann darf erst geschaltet werden. Es gibt einen Manuellen Modus (Alles muss von Hand bedient werden) und einen Automatik - Modus -> Der Pumpstand versucht eigenständig ein Hochvakuum hinzubekommen und alles läuft automatisch ab bzw ist es auch Möglich das der Pumpstand Automatisch kontrolliert vom Hochvakuum wieder auf Atmosphäre-Druck kommt
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.