Hallo, ich habe ein Problem. Ich habe mit dem ATMega16 eine simple Schaltung aufgebaut, mit der ich 8 Eingänge überwache. Die Geber am Eingang sind Druckwächter, welche druckabhängig eine Ausgangsspannung von ca. 1-4 Volt bringen. Die Eingänge der ADCs gehen also direkt drauf. 8 Ausgänge signalisieren über LEDs die Zustände. 2 Eingänge dienen zum Programmieren der Zustände und 2 Ausgänge schalten eine S7. Die Spannung wird von 24 Volt auf 5 Volt mit einem 7805 runter geregell. Abblockkondensatoren und Stützkondensatoren habe ich genug vorgesehen. Fast schon zu viel. Nun löuft die Schaltung Wochen einwandfrei. Trotzdem kommt es vor, dass der µC Teile des Programms vergisst. Einige Funktionen funktionieren noch, andere nicht. Wenn ich das Programm wieder aufspiele, funktioniert das Ganze wieder. Hat jemand dafür eine Erklärung? Ich verstehe es nicht. MfG LotharK
Lothar Kriegerow schrieb: > Einige Funktionen funktionieren noch, andere nicht. Dann lies ihn doch mal zurück und versuche zu erkennen, was sich verändert hat.
Lothar Kriegerow schrieb: > Nun löuft die Schaltung Wochen einwandfrei. Trotzdem kommt es vor, dass > der µC Teile des Programms vergisst. Wie hast du das festgestellt? Hast du den Flash mal ausgelesen? > Hat jemand dafür eine Erklärung? Ich verstehe es nicht. Hast du BrownOut aktiviert?
Lothar Kriegerow schrieb: > Die Geber am Eingang sind > Druckwächter, welche druckabhängig eine Ausgangsspannung von ca. 1-4 > Volt bringen. Was MCs garnicht mögen, wenn an IO-Pins Spannung von außen kommen kann, bevor die VCC anliegt. VCC muß immer zuerst bzw. beim Ausschalten zuletzt anliegen. Lothar Kriegerow schrieb: > Die Eingänge der ADCs gehen also direkt drauf. Ich würde nie Pins des MC direkt auf lange Leitungen zur Außenwelt geben. Schutzwiderstände 10k in Reihe zu allen Eingängen.
Hallo Peter, (ich habe mal 3 Bilder der 3 Ebenen angehängt. Ich weiß, sieht nicht so toll aus - ist der erste Betatest.) Von Außen kommt nichts. Die Drucksensoren sind direkt auf der 1.LP und werden auf die 2. gesteckt. Das Ganze befindet sich in einem geschirmten Gehäuse. Heraus gehen nur die 2, über Transistoren gesteuerten Ausgänge. MfG LotharK
@Jörg, Ja, das wäre eine Idee. Leider habe ich ihn schon neu beschrieben. @Magnus Das mit dem BrownOut wäre eine Möglichkeit. Habe ich aber noch nie gemacht. Da werde ich mich wohl erst belesen müssen. Das Problem ist, die Schaltung muss in das Gehäuse. Durch den großen ATMega16 ist kaum Platz. Den ATMega16 als SMD kann ich nicht löten und auch keine LP herstellen. Jedenfalls nicht ohne erheblichen Aufwand. Von den Druckwächtern benötige ich nur 4 Stück. Für eine Serie also zu wenig. Das Komische ist, dass der µC nach neu Programmieren wieder perfekt funktioniert. Die Spannung wird über einen 1W SMD-Vorwiderstand auf ca 10 Volt runter geregelt und mit Elko stabilisiert. Danach kommt der LM78L05. Die 5 Volt sind also konstant. Die Stromaufnahme liegt bei 30 mA (LowCurrent-LEDs) MfG LotharK
Hallo Magnus, schneller kann ich nicht antworten. (Mittag) :-) VG LotharK
LotharK schrieb: > @Jörg, > > Ja, das wäre eine Idee. Und so naheliegend! > Leider habe ich ihn schon neu beschrieben. scheinbar nicht für dich :-( Verwendest du das EEPROM um irgendwelche Grenzwerte/Schaltschwellen zu speichern?
Peter Dannegger schrieb: > Was MCs garnicht mögen, wenn an IO-Pins Spannung von außen kommen kann, > bevor die VCC anliegt. > VCC muß immer zuerst bzw. beim Ausschalten zuletzt anliegen Wo steht das denn bitte im Datenblatt zum AVR ? Deiner Ausage nach dürftes es dann sowas wie (externe) PullUPs nicht geben.
Hallo Karl Heinz, Ja, Am Anfang hole ich den Wert der Schaltschwelle aus dem EEProm. Danach wird diese üner die LEDs für 2 Sekunden angezeigt. Danach testet sich jeder ADC-Eingang und zeigt dieses über die LEDs an. Erst dann springt das Programm in die Hauptschleife. Diese wird auch durchlaufen. Wenn ich nämlich Ta1 drücke, komme ich in die Programmierung. Dort kann ich aber die Druckstufe nicht einstellen. Normaler Weise ändert sich die Anzahl der leuchtenden LEDs. Das funktioniert nicht. Mit Ta2 komme ich aber wieder zurück ins Hauptprogramm. Dieses überwacht aber die ADCs nicht mehr. < scheinbar nicht für dich :-( Verstehe ich jetzt nicht. MfG LotharK
>Wo steht das denn bitte im Datenblatt zum AVR ? DC Characteristics: Input High Voltage: max vcc+0,5V >Deiner Ausage nach dürftes es dann sowas wie (externe) PullUPs >nicht geben Die werden an die gleiche Spannung wie die Versorgung angeschlossen. -> kein Problem
LotharK schrieb: > Ja, Am Anfang hole ich den Wert der Schaltschwelle aus dem EEProm. ATmega16-Datenblatt: "EEPROM data corruption can easily be avoided by following this design recommendation: Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can be done by enabling the internal Brown-out Detector (BOD)"
Lothar Kriegerow schrieb: > Nun löuft die Schaltung Wochen einwandfrei. Trotzdem kommt es vor, dass > der µC Teile des Programms vergisst. > Einige Funktionen funktionieren noch, andere nicht. Wenn ich das > Programm wieder aufspiele, funktioniert das Ganze wieder. Hat jemand > dafür eine Erklärung? Ich verstehe es nicht. Nur um es klar zu stellen, der Fehler tritt auch auf, nachdem Du den µC/Schaltung (komplett) spannungslos gemacht hast und ist erst nach einem Neu-Aufspielen weg. Woher weisst Du, das einige Teile funktionieren, andere nicht (welche? Kann man des evetuell auf eine Peripherie zurückführen?) Wie spielst Du das Programm auf, per Boot-Loader oder ISP? Könnte es sein, dass zufällig in den Bootloader gesprungen wird?
Ok, danke für Eure Antworten. Ich werde erst mal die erhaltenen Tipps umsetzen und mich ggf. noch mal melden. Ich denke auch, dass es an einer ungenügenden Spannung liegt. Warum auch immer. Dass dadurch aber ein Programm im Speicher zerstört wird, war mir neu. Danke LotharK
LotharK schrieb: > Das Problem ist, die Schaltung muss in das Gehäuse. Durch den großen > ATMega16 ist kaum Platz. Den ATMega16 als SMD kann ich nicht löten und > auch keine LP herstellen. Jedenfalls nicht ohne erheblichen Aufwand. Mal ehrlich: ein TQFP mit 0,8 mm Pinabstand lasse ich noch problemlos meinen Sohn löten, und die Platinen dazu stellt man auch in der heimischen Waschküche her. Das Durchführen eines Leiterzugs zwischen zwei Lötaugen mit 2,54 mm Pinabstand bei DIL ist deutlich fummeliger, sowohl was das Löten betrifft als auch die Herstellung. Die Platzersparnis des TQFP44 gegenüber dem DIL40 ist erheblich. LotharK schrieb: > Dass dadurch aber ein Programm im Speicher zerstört wird, war mir neu. Das ist auch in der Tat ungewöhnlich. Zwar läuft die Hardware dann in eine Art "undefined behaviour", aber gerade bei zu geringer Betriebsspannung dürfte es schwierig sein, dass die interne Ladungspumpe noch in der Lage ist, die zum Löschen oder Umprogrammieren des Flash notwendige Programmierspannung zu erzeugen (da dürften so um die 12 V dazu nötig sein). Aber da du den Flash-Inhalt nicht zurückgelesen hast, ist es bis jetzt ja auch nur eine bloße Annahme, dass sich dieser verändert haben könnte.
Anders gefragt: Ist das Fehlverhalten mit komischen Werten im EEPROM erklärbar? Der Zusammenhang zwischen EEPROM Zugriffen und Unterspannung wurde hier ja schon genannt...
Noch ein paar Tips: 1. CRC über das Flash berechnen und zyklisch prüfen. Dann siehst Du, ob es wirklich das Flash ist, daß sich ändert. 2. Wenn es das nächste mal auftritt: Nur das EEPROM neu beschreiben, nicht das Programm-Flash.
Oh Jeh, @Jörg - Ja, vor 40 Jahren hätte ich das auch noch gelötet. Geht nicht mehr, trotz Lupe - ich kann es nicht schön reden. @Horst - Der EEProm wird noch korrekt gelesen. Dort wird nur eine Simple 1,2,3,4 oder 5 abgelegt. Mehr brauche ich nicht. Diese wurde über die LEDs auch korrekt angezeigt. @Micha - ja, den µC habe ich ausgebaut und mit dem STK500 analysiert. Woher ich weiß was funktioniert habe ich oben beschrieben. Den µC programmiere ich über ISP. LotharK
LotharK schrieb: > @Micha - ja, den µC habe ich ausgebaut und mit dem STK500 analysiert. Und? Was sagt Verify zum Programmspeicherinhalt? Oliver
Lothar Kriegerow schrieb: > Nun löuft die Schaltung Wochen einwandfrei. Trotzdem kommt es vor, dass > der µC Teile des Programms vergisst. Kann es sein, daß auf Grund eines Fehlers im Programm bestimmte Programmteile einfach nicht mehr ausgeführt werden? 42m
Hallo Michael, das ist unwarscheinlich. Habe ich aber schon geschrieben. Erst nach erneutem Einspielen funktionierte es wieder. Selbst von der Spannung nehmen war erfolglos.
LotharK schrieb: > Hallo Michael, > das ist unwarscheinlich. Ganz und gar nicht. > Habe ich aber schon geschrieben. > Erst nach erneutem Einspielen funktionierte es wieder. Wenn dein 'erneutes Einspielen' ein Neuprogrammieren des EEPROMS beinhaltet, dann hast du da ganz zwanglos eine Erklärung, warum die Vergleichswerte sich scheinbar selbst wieder in den funktionsfähigen Zustand versetzen. > Selbst von der > Spannung nehmen war erfolglos. Das löscht ja auch nicht die falschen Werte im EEPROM. Es ist eher unwahrscheinlich, dass das Flash seinen Inhalt so mir nichts dir nichts verändert, als das es das EEPROM tut. Und wenn das Ganze dann so programmiert ist, dass ein 0xFF Zustand des EEPROMS alles durcheinander bringt, dann hast du deine Erklärung für das Verhalten. Aber: Ohne Schaltung, ohne Programm, ohne Kontrollauslesen des Flash ist das alles nur geraten und auf die häufigsten und wahrscheinlichsten Fälle runtergebrochen.
Karl Heinz Buchegger schrieb: > Es ist eher unwahrscheinlich, dass das Flash seinen Inhalt so mir nichts > dir nichts verändert, Ich würde sagen "höchst unwahrscheinlich" bis "nahezu unmöglich", wenn es wiederholt auftritt. Typische Fehler im Programm sind Zugriff auf nicht initialisierte Variablen (speziell lokal in Funktionen) oder Stack-Überlauf.
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.