Hallo.
Ich wundere mich über scheinbar zufällige EEPROM-Einträge beim
ATmega168PA-PU. An zwei Stellen tauchen nach einiger Zeit Betrieb wie
zufällig Einträge auf.
An diese EEPROM-Stellen schreibe ich aber nicht aktiv bzw. nicht
gewollt. Das ganze habe ich in AtmelStudio 7.0.1188 in C geschrieben.
Hier die Schreibfunktion:
// Abwarten, bis anstehende Schreibvorgänge abgearbeitet sind
7
while(EECR&(1<<EEPE))
8
;
9
10
// EEPROM-Adresse festlegen
11
EEAR=address;
12
13
// EEPROM-Daten festlegen
14
EEDR=data;
15
16
// Logische 1 schreiben
17
EECR|=(1<<EEMPE);
18
19
//EEPROM-Schreibvorgang starten
20
EECR|=(1<<EEPE);
21
}
Nun die Frage: Kann es sein, dass irgendwo im Programmcode durch
schlampige Programmierung der EEPROM beeinflusst wird, auch wenn genau
an der Stelle der schlampigen Programmierung gar keine EEPROM-Zugriffe
vorgesehen sind? Gibt's sowas?
Oder liegt es einzig und alleine nur daran, dass an die
EEPROM-Schreib-Funktion falsche Adressen übergeben werden?
Woran kann es liegen? Damit ich weiß, wo ich mit Suchen anfangen soll...
Danke!
SilbergrauerAdler schrieb:> Woran kann es liegen?
Du hast die Abblock-Kondensatoren vergessen bzw. deine
Stromversorgung ist schlampig ausgeführt.
Daran kann es liegen.
SilbergrauerAdler schrieb:> An zwei Stellen tauchen nach einiger Zeit Betrieb wie zufällig Einträge> auf.
Immer nur dort an diesen beiden Stellen?
> Hier die Schreibfunktion:
Mach doch dort mal eine LED an, wenn diese Funktion mit einer der beiden
Adressen aufgerufen wird. Denn dann könnte das ein amoklaufender Pointer
sein (aka. "zu kurz definiertes Array").
Wie schon indirekt erwähnt - immer wenn es an der selben Stelle
passiert, dann ist zu 99,9999% deine eigene Software Schuld.
Und wir sehen hier leider nur deine Schreibfunktion.
Lothar M. schrieb:> SilbergrauerAdler schrieb:>> An zwei Stellen tauchen nach einiger Zeit Betrieb wie zufällig Einträge>> auf.> Immer nur dort an diesen beiden Stellen?
Kann ich nicht genau sagen, das müsste ich genauer analysieren. Aber
gefühlt ja, immer an denselben Stellen.
>> Hier die Schreibfunktion:> Mach doch dort mal eine LED an, wenn diese Funktion mit einer der beiden> Adressen aufgerufen wird. Denn dann könnte das ein amoklaufender Pointer> sein (aka. "zu kurz definiertes Array").
DAS ist eine gute Idee. Werde ich mal probieren. Danke!
Die Led kann aber den Spannungsabfall noch verstärken. Ich wurde direkt
vor dem 100nF Kerko den du direkt zw. VCC und GND haben solltest noch
nen kleinen Elko mit 10uF setzen das könnte etwas helfen falls die
Stromversorgung schlecht geroutet ist und kein generelles Problem
darstellt.
Die Led könnte man aber nach einem Brown Out aktivieren falls man das
mit deinem uC auswerten kann.
Hallo,
ich habe bei einem anderen ATMEGA vor Jahren auch mal ein ähnliches
Problem gehabt. Dort lag es damals auch am nicht aktivierten BrownOut.
Immer beim Runterfahren des Systems kam es sporadisch zu diesen Fehlern
im EEPROM. Zuerst hatte ich in der "main" Routine grundsätzlich die
EEPROM Adresse auf einen unbenutzen Wert vorbelegt. Das hatte schon mal
geholfen. Erst mit dem Aktivieren des BrownOuts war das Problem dann
gänzlich behoben.
Was auch noch passieren kann ist, dass Du in der Schreibroutine zwar den
Programmiervorgang startest, dann jedoch nicht mehr auf das Ende des
Vorgangs wartest. Damit beendest Du die Schreibroutine und kehrst ins
HP? zurück. Wenn dort jetzt zu einem ungünstigen Zeitpunkt (also noch
während des Schreibvorgangs) der EEPROM-ADR Eintrag geändert wird, kann
es auch zum unvorhergesehenen Crash kommen (das ist mir mal bei einem
PIC passiert).
Daher mein Vorschlag, dass Du die Abfrage
>while (EECR & (1<<EEPE));
vom Anfang der Routine ans Ende der Routine verschiebst (und auch
prüfst, ob in einer ISR der EEPROM-ADR Wert geändert wird, denn dann
solltest Du noch die Interrupts während des Schreibvorgangs abschalten)
Gruß
TK
Wenn du die avr-libc benutzt, kann es auch sinnvoll sein, einfach die
Routinen dieser zu benutzen, anstatt das selber nach zu coden. Die
Routinen sind auch so gemacht, das auf jeden Fall das nötige Timing für
den EEPROM eingehalten wird, z.B.
Apropos Stromversorgung: Diese habe ich mal als Anhang hochgeladen.
Vielleicht findet ja jemand Auffälligkeiten? Versorgt wird das ganze mit
12 Volt. Als Abblockkondensatoren verwende ich 100 nF Keramik direkt
neben den IC-Beinchen.
Ursprünglich hatte ich für die EEPROM-Zugriffe auch die AVR-libs
genutzt, aber dann durch die eigene Programmierung ersetzt, weil ich
dachte, der Fehler kommt daher...
Interrupts während der Schreibvorgänge abschalten wäre auch noch eine
Fehlerquelle und eine gute Idee, da gibt es Timer, USART-Ereignisse,
ADC-Conversion-Interrupts und einige mehr bei mir im Programm.
Die Aktivierung der Brown-Out-Fuse könnte wirklich auch ein hilfreicher
Tipp sein.
Ich teste das ebenfalls mal und danke für die Vorschläge :-)
Also auf die Schnelle sehe ich da einen 47K Widerstand ohne
Kondensator, das könnte in dem störenden Umfeld (das ich
nicht kenne) eine ernste Gefahr werden.
Widerstand um mindestens eine Zehnerpotenz kleiner und 100nF
dazupacken ....
Eventuell auch im realen Betrieb die ISP Leitung zu Reset
unterbrechen da Einstreu-Gefahr von Störungen.
Wozu ist R3,R26,R2 gut?
An R26 (9.1Ohm) faellt je nach Belastung mal mehr mal weniger ab.
R3 (169 Ohm) bringt gar nichts und verhindert die Funktion der Z-Diode
zuverlaessig. Das gleich mit R2 (169 Ohm).
Ja, die R2,R3 und R26 gehören hier nicht rein. Dafür sind die Z-Dioden
dann durch TVS-Dioden zu ersetzen.
C1 ist von der Spannungsfestigkeit zu klein, wenn die TVS-Diode mit 30V
angesetzt ist.
Zum Regler gehören auch immer noch die kleinen MLCCs (also vorne und
hinten noch die 100nF).
>Widerstand um mindestens eine Zehnerpotenz kleiner und 100nF>dazupacken
FullAck
Gruß
TK
TK schrieb:> Zum Regler gehören auch immer noch die kleinen MLCCs (also vorne und> hinten noch die 100nF).
Nicht beim LM2937 (siehe Datenblatt). Das ist schon ok mit den 10µF am
Ausgang, wenn man die schöne regulierte Spannung nicht mit R26 wieder
aushebeln würde :-P
Anscheinend ist deine Eingangsspannung so hoch, daß du einen normalen
Spannungsregler anstelle des Low-Drop Reglers verwenden kannst.
Normale SPannungsregler sind allgemein weniger zickig als Low-Drop
Regler.
Zeige Finger Heber schrieb:> Also auf die Schnelle sehe ich da einen 47K Widerstand ohne> Kondensator, das könnte in dem störenden Umfeld (das ich> nicht kenne) eine ernste Gefahr werden.>> Widerstand um mindestens eine Zehnerpotenz kleiner und 100nF> dazupacken ....
Danke, ist auch einen Versuch wert. Den 100nF parallel zum Widerstand?
Habe ich das recht in Erinnerung, dass Atmel in den Datenblättern einen
Wert von etwa 47k empfiehlt?
Helmut L. schrieb:> Wozu ist R3,R26,R2 gut?>> An R26 (9.1Ohm) faellt je nach Belastung mal mehr mal weniger ab.> R3 (169 Ohm) bringt gar nichts und verhindert die Funktion der Z-Diode> zuverlaessig. Das gleich mit R2 (169 Ohm).
Okay, das habe ich dann wohl am Experimentierboard "falsch" getestet.
Hier stieg die Spannung mit dieser Dioden-Widerstands-Kombination knapp
über 5 Volt nicht mehr weiter an. Werde ich dann entfernen die
Widerstände.
Matthias S. schrieb:> TK schrieb:>> Zum Regler gehören auch immer noch die kleinen MLCCs (also vorne und>> hinten noch die 100nF).>> Nicht beim LM2937 (siehe Datenblatt). Das ist schon ok mit den 10µF am> Ausgang, wenn man die schöne regulierte Spannung nicht mit R26 wieder> aushebeln würde :-P
Wird entfernt ;-) Danke.
Zeige Finger Heber schrieb:> "Verdächtig" finde ich noch die Leitung die vom Prozessor-Vcc> nach irgendwo hinführt. Was da wohl noch an Strom gezogen wird> und noch alles passiert?
Frag ich mich auch gerade. Das Signal geht als Spannungsversorgung zu
einem Hallsensor.
SilbergrauerAdler schrieb:> dass Atmel in den Datenblättern einen> Wert von etwa 47k empfiehlt?Zeige Finger Heber schrieb:> das könnte in dem störenden Umfeld (das ich> nicht kenne) eine ernste Gefahr werden.SilbergrauerAdler schrieb:> Den 100nF parallel zum Widerstand?
Ist zwar fast wurscht, aber normalerweise setzt man R-C-Glieder
mit dem Kondensator nach Masse.
Auf jeden Fall ein Segen für die "Entstörung".
Thread beobachten
Seitenaufteilung abschalten
