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.
Gast
#3050528
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
Was hältst du davon die gestellten Fragen zu beantworten? Beitrag "Re: ATMega16 vergisst Programm"
Gast
#3050541
@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
Gast
#3050543
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?
Gast
#3050562
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.
Gast
#3050569
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
Gast
#3050579
>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)"
Gast
#3050592
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?
Gast
#3050600
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.
Gast
#3050637
Anders gefragt: Ist das Fehlverhalten mit komischen Werten im EEPROM erklärbar? Der Zusammenhang zwischen EEPROM Zugriffen und Unterspannung wurde hier ja schon genannt...
Gast
#3050655
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.
Gast
#3050674
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
Gast
#3050784
LotharK schrieb: > @Micha - ja, den µC habe ich ausgebaut und mit dem STK500 analysiert. Und? Was sagt Verify zum Programmspeicherinhalt? Oliver
Gast
#3050936
Hat er doch geschrieben
Gast
#3050976
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
Gast
#3051060
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.
Gast
#3051124
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.


