| Autor |
|
Atmel EEProm fehlerhaft beschrieben |
|
|
|
|
BID = 103224
RaPe
Gelegenheitsposter
Beiträge: 56
Wohnort: Radebeul
|
|
Vor einer Weile, hab ich ein Programm geschrieben, um einen Motor zu steuern. Dabei war es auch notwendig, das Daten in den internen EEPROM geschrieben werden musstem. Wärend der Entwicklung der Schaltung verwendete ich einen relbaren Trafo und es gab nie Probleme! Bei der fertigen Schaltung wird jetzt aber ein Schaltnetzteil verwendet. Beim Ausschalten der Betriebspannung fällt sie nur langsam ab und zm Schluss gibt es nochmal einen kurzen Spannungsanstieg.
Nach langer Suche hab ich herausgefunden, das der µP kurz vorm ausgehen durch die niedrige Spannung (oder so) unkontrolliert durchs Prog. rennt. Dadurch hat er auch fast immer den Schreibbefehl vom EEPROM gefunden und ausgeführt. Dabei hat er wichtige Daten mit Müll (meist 0) überschrieben!
Ich hatte irgendwann die Idee, SLEEP-befehle dort einzufügen. Vor jedem Schreibzyklus, wird der deaktiviert und danach gleich wieder aktiviert.
Nicht lachen, auch wenns lustig aussieht!!!
EEPROM:
SBIS EECR,0
SBIC EECR,1 ;Auf EEProm warten
RJMP EEPROM
SLEEP
OUT EEARL,Temp1 ;Adresse angeben
OUT EEDR,Temp2 ;Daten
SLEEP
SBI EECR,2 ;MasterWriteEnable bit setzen
SLEEP
SBI EECR,1 ;WriteEnable bit setzen --> schreiben
SLEEP
LDI Temp3,0b00110000 ;EEPROM schützen
OUT MCUCR,Temp3
RET
Es funktionierte auch soweit. Ich konnte damit die Fehlerwarscheinlichkeit auf etwa 5% senken!!! 
Jetzt zu meiner Frage:
Hat schon mal jemand anders solche Probleme gehabt und hat jemand noch andere Ideen, um Sicherzustellen das kein unkontrolliertes Schreiben möglich ist! Am meisten interessieren mich Softwaremäßige Vorschläge da ich die Hardware nur sehr schlecht änderen kann aber auch über sie würd ich mich freun.
Es handelt sich um einen AT90S8515. Wird mit 8MHz betrieben. Interrupte werden im Prog. nicht verwendet. |
|
BID = 103232
Benedikt
Inventar
Beiträge: 6241
|
|
Dieses Verhalten ist normal, stehat auch im Datenblatt. Bei Atmel gibt es auch einige Application Notes zu dem Thema.
Softwaremäßig lässt sich wenig machen, außer direkt vor jedem Schreibbefehl irgendeine Überprüfung die nur dann weiterkommt, wenn das Schreiben gewollt ist.
Ansonsten ein TL7705 an den Reset Pin hängen... |
|
BID = 103257
Magni
Gelegenheitsposter
Beiträge: 91
Wohnort: Edewecht
|  
Oder einen Elko an die Versorgung des µC ranlöten, sodass der µC erst Strom bekommt wenn sich der Elko aufgeladen hat. Das würde den Vorteil haben, dass die Spannungsspitze zum Schluss verschwinden würde.
gr
Adrian
|
BID = 103264
Benedikt
Inventar
Beiträge: 6241
|
Zitat :
Magni hat am 18 Sep 2004 15:53 geschrieben :
|
Oder einen Elko an die Versorgung des µC ranlöten, sodass der µC erst Strom bekommt wenn sich der Elko aufgeladen hat. Das würde den Vorteil haben, dass die Spannungsspitze zum Schluss verschwinden würde.
gr
Adrian
|
Das bringt nichts, denn das Problem tritt beim Abschalten auf. Je langsam die Spannung sinkt, desto größer die Gefahr.
|
BID = 103280
RaPe
Gelegenheitsposter
Beiträge: 56
Wohnort: Radebeul
|
Zitat :
Benedikt hat am 18 Sep 2004 14:51 geschrieben :
|
Dieses Verhalten ist normal, stehat auch im Datenblatt. Bei Atmel gibt es auch einige Application Notes zu dem Thema.
Softwaremäßig lässt sich wenig machen, außer direkt vor jedem Schreibbefehl irgendeine Überprüfung die nur dann weiterkommt, wenn das Schreiben gewollt ist.
Ansonsten ein TL7705 an den Reset Pin hängen...
|
Dann mach mal bitte einen Vorschlag! Ich wüsste nicht was, da er sowieso quer durchs Programm rennt, ist dem irgendeine Überprüfung (scheiß) egal und der wird die einfach übergehn!!!
|
BID = 103284
Benedikt
Inventar
Beiträge: 6241
|
Zitat :
RaPe hat am 18 Sep 2004 16:24 geschrieben :
|
Dann mach mal bitte einen Vorschlag!
|
Hab ich doch !
Zitat :
Benedikt hat am 18 Sep 2004 14:51 geschrieben :
|
Bei Atmel gibt es auch einige Application Notes zu dem Thema.
Softwaremäßig lässt sich wenig machen, außer direkt vor jedem Schreibbefehl irgendeine Überprüfung die nur dann weiterkommt, wenn das Schreiben gewollt ist.
Ansonsten ein TL7705 an den Reset Pin hängen...
|
|
BID = 103287
RaPe
Gelegenheitsposter
Beiträge: 56
Wohnort: Radebeul
|
Ich meine damit, ob du eine softwaremäßige Überprüfung mir vorschlagen kannst (aus dem Ärmal zaubern), die Zuverlässig genug ist, um die Fehlerquote zu senken.
Sind die Application Notes direkt bei Atmel zu finden, oder gibt's da eine spezielle Adresse?
|
BID = 103292
Benedikt
Inventar
Beiträge: 6241
|
Ich würde den TL7705 nehmen, ist die einzige wirklich gute Lösung.
Du könntest eine Variable mit einem Testmuster (sowas wie 0xAA, was 10101010 entspricht) vergleichen. Vor dem Schreiben rufst du ein Unterprogramm auf, dass 0xAA in die Variable schreibt, ansonsten beschreibst du überall im restlichen Programm die Variable mit anderen Werten.
Die Warscheinlichkeit, dass erst das Unterprogramm mit 0xAA aufgerufen wird, und direkt danach das Schreibprogramm ist ziemlich unwarscheinlich.
Bist du dir sicher, dass mit deinen Routinen das EEPROM neu beschrieben wird ? Viel warscheinlicher ist, dass der Controller Mist baut und so versehentlich das EEPROM beschreibt.
Machs nicht so kompliziert, bau ein TL7705 ein...
|
BID = 103399
RaPe
Gelegenheitsposter
Beiträge: 56
Wohnort: Radebeul
|
Zitat :
Benedikt hat am 18 Sep 2004 16:54 geschrieben :
|
Ich würde den TL7705 nehmen, ist die einzige wirklich gute Lösung.
Du könntest eine Variable mit einem Testmuster (sowas wie 0xAA, was 10101010 entspricht) vergleichen. Vor dem Schreiben rufst du ein Unterprogramm auf, dass 0xAA in die Variable schreibt, ansonsten beschreibst du überall im restlichen Programm die Variable mit anderen Werten.
Die Warscheinlichkeit, dass erst das Unterprogramm mit 0xAA aufgerufen wird, und direkt danach das Schreibprogramm ist ziemlich unwarscheinlich.
Bist du dir sicher, dass mit deinen Routinen das EEPROM neu beschrieben wird ? Viel warscheinlicher ist, dass der Controller Mist baut und so versehentlich das EEPROM beschreibt.
Machs nicht so kompliziert, bau ein TL7705 ein...
|
Bin ich mir zu 99,9999999999999% sicher. In der Schaltung befinden sich 2 µC. Beide sind AT90S8515 und ähnlich vom Programm aufgebaut. Weiterhin holen beide Daten aus dem EEPROM. Aber nur der, der den Schreibbefehl im Programm hat, macht Mist. Beim anderen ist noch nie ein Fehler aufgetreten. Die µC hab ich auch untereinander schon gewechselt und sie hängen auch von der Spannungsversorgung direkt zusammen uund nutzen auch den gleichen Quarz....
Ich denke (auch wenn man das den Pferden überlassen sollte, die ham ja nen größeren Kopf) auch mit so einem Vergleich, wird das nicht zu 100% sicher sein, weil der den Vergleich bestimmt auch mal überrennen wird. Aber versuchen kann man es mal... 
|
BID = 103740
ERDI-Soft
Stammposter
Beiträge: 200
Wohnort: Offenburg
| 
Bau doch am Programmstart ein Delay ein, das länger geht, als der Puls lang sein kann. Dadurch hast du zwar ne elend lange Verzögerung des Programmstartes, aber er springt dir nicht im Programm rum.
_________________
Wie immer gilt: Erst googeln, dann fragen!
(Für ICQ bitte erst Anfrage per PM, da alles andere nicht angenommen wird.)
|
BID = 103746
Jornbyte
Moderator
Beiträge: 7320
|
Das Problem beim ausschalten ist bekannt. Der EEProm kommt ins "Schwimmen". Dein NT ist etwas überdimensioniert. Da haste verschiedene Möglichkeiten.
1. ein kleineres NT verwenden (Leistung)
2. mit einem Relais den µC von der Spannung trennen (ist nicht so gut, Kontaktprellen)
3. einen Lastwiderstand einbauen (ist nicht so gut, Wärme)
4. mit einen Komparator die Spannung (< 4,8 Volt) für den µC abschalten (beste möglichkeit)
_________________
mfg Jornbyte
Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.
|
