Hallo zusammen, ich bin am verzweifeln. Ich hab eine Zeitschaltuhr gebaut. Und die Zeiten, wann ein- und wann ausgeschaltet werden soll speichere ich im EEPROM, habe dafür aber auch eine Kopie im RAM liegen, mit der ich arbeite. Bei mir im Keller lief das Teil einen Monat ohne Probleme. Jetzt habe ich das bei einem Freund eingebaut und das Problem, dass er regelmäßig die Einstellungen im RAM löscht, die Einstellungen verliert. Ich vermute EMV-Probleme, aber alles andere (Uhr, Einstellungen im EEPROM, etc. ) funktioniert einwandfrei. Auch bei einem anderen Freund läuft das seit über drei Monaten ohne Probleme. Hat jemand schonmal ähnliche Erfahrungen gemacht und kann mir Helfen, wo ich bei der Fehlersuche anfangen soll. Gruß Karlheinz
Hallo Otto, ja, Brown-Out ist aktiviert. Und ich lese nach dem Start sofort das CPU-Register aus und speichere die Werte auch im RAM. So kann ich feststellen, wann zum letzten mal ein Reset gemacht wurde und warum. Seltsamerweise sind diese Werte auch noch da, obwohl sie auch im RAM liegen. Dadurch habe ich auch festgestellt, dass der Prozessor keinen Reset macht, die Einstellungen aber trotzdem aus dem RAM verschwunden sind. Gruß Karlheinz
Hallo Tom, den Code habe ich selbst geschrieben. Ist im Keller sauber 4 Wochen gelaufen. So wie es war ausgeschaltet, abgebaut, bei einem Freund wieder aufgebaut, eingeschaltet, alles erst mal wunderbar. Dann aber die Überraschung dass zur angegebenen Zeit nichts eingeschaltet wird (durch die Zeitschaltuhr), denn die Definition dafür ist weg. Gruß Karlheinz
a) ist die Schaltung bei dir im Keller auch mit Reallasten gelaufen? b) Was ist im Keller deines Freundes anders?
Hallo Otto, bei mir im Keller ist sie nicht mit Reallasten gelaufen. Dieses Thema hatte ich auch schon im Verdacht. Aber bei meinem Freund wurden die Lasten zwei bis drei mal ein- und wieder ausgeschaltet, alles kein Problem. Wir haben es beobachtet, die Einstellungen waren auch nach dem Ausschalten der Last noch da. Aber irgenwann zwischendurch, wenn keine Schaltvorgänge vorliegen, verschwinden die Einstellungen. Gruß Karlheinz
Betreibe die Schaltung im Keller des Freundes mal ohne Reallasten. Wie unterscheiden sich diese zu den Lasten des Freundes, bei welchem die Schaltung funktioniert?
Hallo Otto, ich glaube nicht, dass es an den Lasten liegt. Es sind zwar Relais, die 230 V schalten, aber nur wenige mA zum Schalten von größeren Schützen, die aber räumlich weit weg sind. µC schaltet MOSFETS, diese schalten die Relais mit Freilaufdiode. Die MOSFETs haben Schutzbeschaltung mit Zenerdioden. Der Schaltstrom für ein Relais liegt bei ca. 25 mA, 12V. Also alles relativ unkritisch. Und wie gesagt, direkt nach dem Schalten sind die Einstellungen ja noch da. Wenn diese direkt nach dem Schalten weg wären, wüsste ich ja, wo ich suchen muss. Ich habe auch schon Handy und Schnurlostelefon auf das Gehäuse gelegt und Angerufen bzw. telefoniert. Alles kein Problem. Gruß Karlheinz
Sehr ungewöhnlich... Meist liegt der Fehler aber da wo man ihn nicht vermutet. Poste doch mal den Code! Ingo
Hallo Karlheinz, eventuell wird das RAM auch durch Störungen gelöscht, welche von einem anderen Verbraucher (z. B. Leuchtstoffröhren oder Aufzugmotor)erzeugt werden. Es stellt sich auch die Frage, ob elektrische oder magnetisch eingekoppelte Störungen die Löschung bewirken. Ohne alle Zusammenhänge zu kennen, ist es sowieso schwierig sinnvolle Tipps zu geben...... Gruß Otto
Hallo Ingo, ich denke auch, dass der Fehler da liegt, wo man es nicht vermutet, deshalb bin ich mit meinem Latein ja auch am Ende. Was den Code angeht: ich glaube nicht, dass du 4500 Zeilen Assemblercode (mit Kommentarzeilen) analysieren willst. Der generelle Ablauf ist wie folgt: beim Reset werden die Werte aus dem EEPROM gelesen und im RAM abgelegt. Auf das RAM wird danach nur noch lesend zugegriffen. Jede Minute, um festzustellen, ob etwas ein- oder ausgeschaltet werden muss. Und wenn etwas eingeschaltet werden muss, die Definition dazu. Wie gesagt, genau dieser Code läuft anderswo monatelang ohne Probleme. Anderswo aber nur einen Tag oder sogar nur einen halben. Gruß Karlheinz
Hallo Otto, ja, EMV-Probleme vermute ich auch. Mich würde aber interessieren, wie die in den Prozessor einstreuen und genau diesen Bereich des RAMs löschen. Ok, das ist einer der meistgelesenen Teile des RAM, aber dann müsste aus einer Lese- eine Schreiboperation werden. Ich werde dem Prozessor jetzt mal eine Kupferhaube verpassen und schauen, ob sich was verbessert. Gruß Karlheinz
An deiner Stelle würde ich ein Relais nehmen und so verschalten, dass sein Öffner die Spule unterbricht. Dieses betreibst du versuchsweise an der unstabilisierten Versorgung. Wird das RAM nun gelöscht, gelangen die Störungen elektrisch in die Schsaltung. Wird das RAM so nicht gelöscht, bilde aus der Zuleitung zum Relais eine Leiterschleife mit einigen Windungen und führe diese Schleife über die Schaltung. Wird das RAM nun gelöscht, wird die Störung magnetisch eingestreut.
Also wo schon in Assembler programmiert hast, nehme ich an, dass Dein Code auch die Resetquelle abfragt und danach entscheidet, ob das RAM gelöscht wird (nach POR) oder nicht (nach BOR). Bleibt die Frage, ob Deine Hardware die Vcc bei einem Brown-Out noch zuverlässig puffert, damit sie nicht "zufällig" gleich auf Power-Down-Niveau absinken kann. In dieser Hinsicht ist es schon interessant, etwas mehr über Deine Hardware zu erfahren, z.B. den konkreten AVR, die benutzte Brown-Out-Schwelle, und die Schaltung, mit der Du die Vcc erzeugst. Gruß Johannes
Hallo Otto, danke für die Tipps, ich werds ausprobieren (aber heute nicht mehr...). Gruß Karlheinz
Wird das komplette RAM gelöscht oder nur die Werte für die Zeiten an bestimmten Speicherstellen? Wie stellst du fest, dass das RAM gelöscht wurde Wenn alle Stricke reißen, dann prüfe regelmäßig, ob die Inhalte im RAM konsistent sind und wenn dies nicht der Fall sein sollte, lade sie aus dem EEPROM nach (Aber erst mal mit allen Mitteln versuchen, den eigentlichen Fehler zu eleminieren)
Hi >Ich werde dem Prozessor jetzt mal eine Kupferhaube verpassen und >schauen, ob sich was verbessert. Blödsinn. RAM wird nicht so einfach gelöscht. Dein Gerät mag zwar bei dir im Keller 4 Wochen gelaufen sein. Das heißt aber nicht, das deine Software fehlerfrei ist. >Und ich lese nach dem Start sofort das CPU-Register aus und speichere >die Werte auch im RAM. So kann ich feststellen, wann zum letzten mal ein >Reset gemacht wurde und warum. Seltsamerweise sind diese Werte auch noch >da, obwohl sie auch im RAM liegen. Das sollte dir zu denken geben. Gott sei dank gibt es immer noch die böse EMV auf die man alles schieben kann. MfG Spess
Hallo Johannes, beim µC handelt es sich um einen ATmega8535L im PLCC 44 Gehäuse in einem dazu passenden Sockel. Die Spannung kommt aus einem 12V Schaltnetzteil, mit dem dann auch die Relais betrieben werden (Befindet sich in einem Schaltschrank, einen halben Meter entfernt). Auf der Platine ist dann ein 5V Spannungsregler für den Rest der Schaltung. Dann habe ich große Kondensatoren verbaut, nach Abschalten der des Schaltnetzteils läuft die Schaltung noch ca. 2 Sekunden weiter. Die Resetlogik ist immer gleich, egal warum der µC neu gestartet ist. Es wird immer alles initialisiert und die Einstellungen aus dem EEPROM ins RAM übertragen. Also gelöscht werden die Einstellunge im RAM nie, höchstens mit den Werten aus dem EEPROM überschrieben. Und das BOD Level sind 4 V. Gruß Karlheinz
spess53 schrieb: > Hi > >>Ich werde dem Prozessor jetzt mal eine Kupferhaube verpassen und >>schauen, ob sich was verbessert. > > Blödsinn. RAM wird nicht so einfach gelöscht. Dein Gerät mag zwar bei > dir im Keller 4 Wochen gelaufen sein. Das heißt aber nicht, das deine > Software fehlerfrei ist. > Und was ist mit der Installation, die bei einem anderen Freund seit ca. 4 Monaten einwandfrei läuft? >>Und ich lese nach dem Start sofort das CPU-Register aus und speichere >>die Werte auch im RAM. So kann ich feststellen, wann zum letzten mal ein >>Reset gemacht wurde und warum. Seltsamerweise sind diese Werte auch noch >>da, obwohl sie auch im RAM liegen. > > Das sollte dir zu denken geben. > Was denn bitte? > Gott sei dank gibt es immer noch die böse EMV auf die man alles schieben > kann. > Eine andere Erklärung habe ich nicht. > MfG Spess Gruß Karlheinz
Hallo Christian, es werden nur die Zeiten gelöscht, andere Teile des Memory sind einwandfrei. Das mit dem regelmäßigen übertragen der Daten vom EEPROM ins RAM habe ich mir auch schon überlegt aber wie du richtig sagst will ich die Ursache für das Problem herausfinden. Dieser Teil des RAMS wird jede Minute gelesen, um zu prüfen ob ein Ausgang geschaltet werden muss. Eine meiner Vermutungen ist, dass irgend ein Einfluss von außen den Prozessor veranlasst, aus dieser Leseoperation eine Schreiboperation zu machen... Gruß Karlheinz
Na, das ist alles recht merkwürden und irgendwas stinkt da zu Himmel. Ich komm nur heute nicht mehr drauf, was. Nur so viel: Einfach nur EMV ist es nicht... So gezielt schlägt die nicht zu... Morgen Abend weiter, falls Du bis dahin keine Lösung hast Johannes
Karlheinz F. schrieb: > es werden nur die Zeiten gelöscht, andere Teile des Memory sind > einwandfrei. Dann ist es sicher nicht EMV, sondern ein spezieler Zustand, der in deinem Programm noch nicht berücksichtigt ist.
Hi >Und was ist mit der Installation, die bei einem anderen Freund seit ca. >4 Monaten einwandfrei läuft? Hast du z.B. alle möglichen Zeiteinstellungen getestet? Ich habe Geräte, da läuft ein AVR <15cm neben einer 5kW PWM-Endstufe. Und der vergisst nichts. Dagegen sind dein Handy und Schnurlostelefon Waisenknaben. > Was den Code angeht: >ich glaube nicht, dass du 4500 Zeilen Assemblercode (mit >Kommentarzeilen) analysieren willst. Damit habe habe ich ein GPS mit Kartenanzeige programmiert. MfG Spess
Oder mit anderen Worten: Her mit dem Code ;-) PS: Warum ausgerechnet ASM? Hast du mal versucht alles, was nicht notwendig ist, zu streichen, um den eigentlichen Fehler so eingrenzen zu können. Ich glaube auch, dass der Fehler im Code zu suchen ist.
Hallo Karlheinz, > Hat jemand schonmal ähnliche Erfahrungen gemacht und kann mir Helfen, wo > ich bei der Fehlersuche anfangen soll. nach der bisherigen Diskussion würde ich zuerst auf einen Softwarefehler tippen (grad in Assembler, einmal ein falscher Sprung, oder sonst was). Aber sicherheitshalber: - RAM Testprogramm schreiben (Zelle beschreiben, löschen, überprüfen) - RAM Stresstest (dann kannst den Speicher ausschließen). - sonst den Controller tauschen - ein Weißblech Gehäuse um die Elektronik versuchen Stützkondensatoren an der Elektronik sind vorhanden? Sonst hier im Forum Hard- und Software veröffentlichen, Michael
Karlheinz F. schrieb: >> Blödsinn. RAM wird nicht so einfach gelöscht. Dein Gerät mag zwar bei >> dir im Keller 4 Wochen gelaufen sein. Das heißt aber nicht, das deine >> Software fehlerfrei ist. >> > Und was ist mit der Installation, die bei einem anderen Freund seit ca. > 4 Monaten einwandfrei läuft? Ist da vielleicht irgendwas am Umfeld oder Konfiguration anders, so daß bei ihm irgendein Codepfad nie oder nur sehr selten durchlaufen wird, bei dem anderen Freund aber oft? Wenn dann gerade dort ein Fehler ist, kann sich das auf die beobachtete Art bemerkbar machen. Übrigens: Ist es auch wirklich exakt das selbe Programm, das auf allen µCs läuft? Dieselbe Konfiguration? Alles exakt gleich? >> Das sollte dir zu denken geben. >> > Was denn bitte? Daß nur ganz bestimmte Variablen selektiv verschwinden und andere nicht. Das müßte schon eine recht intelligente EMV sein, die sowas reproduzierbar macht. Was heißt eigentlich, daß die Konfiguration "gelöscht" ist? Was steht nachher im RAM und wie hast du das erkannt?
Rolf Magnus schrieb: > Daß nur ganz bestimmte Variablen selektiv verschwinden und andere nicht. > Das müßte schon eine recht intelligente EMV sein, die sowas > reproduzierbar macht. Da stimme ich zu. Der SRAM ist so ziemlich das letzte was abkackt, ist ja kein GB-DRAM aus winzigen Kondensatoren, die refresht werden müssen. Da ist irgendwas in Deiner Software faul. Beliebte Kandidaten sind ungenutzte Pins, die mit ausgewertet werden (vergessen, zu maskieren). Oder schlechte Entprellroutinen, die Geistertastendrücke erzeugen. Oder simple Stackfehler (push/pop, jump/ret). Karlheinz F. schrieb: > ich glaube nicht, dass du 4500 Zeilen Assemblercode (mit > Kommentarzeilen) analysieren willst. Soviel für ein einfaches Programm, das riecht verdächtig nach Spaghetticode. Copy&Paste-Monster sind der Hauptfeind des Programmierers. Du solltest Funktionen, Schleifen und Arrays verwenden für sich wiederholende Sachen. Peter
Hallo zusammen, dank eurem Ideen glaube ich, den Fehler gefunden zu haben: Es ist eine Zeitschaltuhr, natürlich mit einer Funkuhr. Dazu habe ich einen handelsüblichen DCF77-Empfänger im Einsatz, der das Signal für einen µC aufbereitet ausgiebt. Da der Ausgang als Open-Collector gestaltet ist, habe ich im Eingangspin den Pullup-Wiederstand aktiviert. So weit, so gut. Jetzt kommen Sachen, mit denen ich nicht gerechnet habe: 1. Die Empfangsroutine für das DCF77-Signal rechnet nicht mit mehr als 64 Bits, was im Normalfall ja auch völlig ausreicht. 2. Um Strom zu sparen schalte ich den DCF77-Empfänger nur jede Stunde ein, um die Uhrzeit zu aktualisieren. Das bedeutet: 58 Minuten in jeder Stunde ist der DCF77-Empfänger ausgeschaltet und der Eingang am µC offen. Er hängt aber nicht in der Luft, denn ich habe ja den Pullup-Wiederstand aktiviert. Dachte ich... So wie es aussieht wird über diesen Port, trotz ausgeschaltetem DCF77-Empfänger, irgendein Datenmüll - über EMV, was sonst - eingekoppelt, der die DCF77 Empfangsroutine munter Daten im RAM ablegen lässt. Und da diese keine Begrenzung hat, weil sie ja nur von 64 Bit ausgeht, überschreibt sie Speicherbereiche, was nicht vorgesehen war. Hier hab ich also einen klassischen Bufferüberlauf. Und eine Abhängigkeit von der Umgebung, ob Energie auf den Port eingekoppelt wird, der ihn weiterarbeiten lässt, oder nicht. Jetzt weiß ich, wo ich ansetzen kann, dass lässt sich alles per Software lösen. Nochmal vielen Dank. Gruß Karlheinz
Karlheinz F. schrieb: > 2. Um Strom zu sparen schalte ich den DCF77-Empfänger nur jede Stunde > ein, um die Uhrzeit zu aktualisieren. Das bedeutet: 58 Minuten in jeder > Stunde ist der DCF77-Empfänger ausgeschaltet und der Eingang am µC Du hast fette Schuetze im Schaltschrank, die allein mehrere Watt brauchen (mal deren geschaltete Last vernachlaessigt) und machst solchen Unfug bei einem netzbetriebenen Geraet? Kopfschuettel! fonsana
Den DCF77 würde ich nur bei Batteriebetrieb abschalten, wenn der AVR im Power-Down ist. Im Normalbetrieb braucht der AVR einige mA, da fallen die 100µA des DCF77 nicht auf. Und der 7805 Spannungsregler braucht ja selber schon ~5mA. Strom sparen nur dann, wenn es auch einen Effekt hat. Niemand schaltet die Glimmlampe an der 2kW Kochplatte ab, um "Strom zu sparen". Peter
@Karlheinz F. Wofür braucht dein Kumpel im Keller eine Zeitschaltuhr ? Hanfanbau ? ;-)
Das vordergründige Problem ist wohl jetzt lokalisiert: das ohne weitere Maßnahmen abgeschaltete DCF77-Modul. Warum ich das so schreibe, ist, weil Peter mit seinem Vorschlag, das DCF77-Modul dauerhaft eingeschaltet zu lassen, letztlich auch nur einen Workaround anbietet. Der in diesem Fall zwar ok ist - 100uA mehr oder weniger auf den 5V sind bei einem netzbetriebenen Gerät nun wirklich kein Thema -, nur seiner Einleitung > Den DCF77 würde ich nur bei Batteriebetrieb abschalten, wenn der AVR im > Power-Down ist. kann ich einfach nicht zustimmen. Denn auch ein Open-Collector- oder besser Open-Drain-Ausgang einer modernen CMOS-Schaltung ist letztlich nicht wirklich open, sondern weist parasitäre, d.h. dem Fertigungsprozess verschuldete Dioden nach Vcc und Gnd auf, die vor allem dazu gut sind, den Open-Drain-Transistor vor schädlichen Überspannungen zu bewahren. Was wiederum heißt, dass das abgeschaltete DCF77-Modul einen eingeschalteten controller-internen Pullup auf irgendeine Spannung unterhalb der Vcc herunter zieht - was extra Versorgungsströme weit über den Power-Down-Strom des Controllers zur Folge hat, oder, wenn der Controller noch soweit wach ist, unbeabsichtigte "Zappelei" an empfindlichen Eingängen verursachen kann. Will sagen: Wenn schon das externe (DCF77-)Modul abgeschaltet wird, dann sollte danach auch immer der zugehörige Eingang aktiv und ohne Pullup auf Low gezogen werden. Im übrigen würde ich die DCF77-Zeit nie kürzer als wenigstens 3 Minuten sampeln. Ich mein, nach nur zwei Minuten kann ich bei Mismatch nicht sicher sein, welche Zeit nun stimmt... Johannes
Die Abschaltung des Empfängers hat natürlich nichts mit dem Fehler zu tun, sie ist nur Aufwand ohne Nutzen. Der Fehler wurde ja erkannt. Er bestand darin, daß nicht mit einem gestörten Empfang gerechnet wurde. DCF7 ist Langwelle und damit sehr leicht zu stören. Bei Gewitter kann man nunmal kein Langwellenradio hören. Mit EMV hat das nichts zu tun. Warscheinlich wurde sogar der externe Interrupt genommen, damit ja kein Störimpuls ungezählt bleibt. Eine Abtastung z.B. mit 10ms Timerinterrupt unterdrückt schonmal einige Störungen und macht die Auswertung obendrein deutlich einfacher. Peter
Hallo zusammen, ich habe meinen Code nochmal in Ruhe genau analysiert. Wenn bei abgeschaltetem DCF77-Empfänger etwas eingestreut wurde, dann wurde das ignoriert. Es war also nur möglich, wenn bei eingeschaltetem DCF77-Empfänger dieser falsche Daten liefert, möglicherweise weil er selbst gestört wird. Wie dem auch sei, ich habe den Speicherüberlauf jetzt abgestellt. So kann maximal Schrott im RAM stehen, wo die DCF77-Empangsdaten liegen. Den Rest des RAM und damit auch die Einstellungen sollte jetzt ein DCF77-Empfangsfehler nicht mehr stören. Weiterhin habe ich beim Ausschalten des DCF77-Empfängers jetzt auch den Interrupt am Signaleingang ausgeschaltet. Somit belasten mögliche Signale die CPU auch nicht mehr unnützerweise. Nochmals Danke für eure rege Beteiligung an diesem Problem. Gruß Karlheinz
Hi >Weiterhin habe ich beim Ausschalten des DCF77-Empfängers jetzt auch den >Interrupt am Signaleingang ausgeschaltet. >Warscheinlich wurde sogar der externe Interrupt genommen, damit ja kein >Störimpuls ungezählt bleibt. Da hast du ins Schwarze getroffen. MfG Spess
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.