[t4313] EEPROM verliert Inhalt?

[J. W. (jw-lighting)]

Hallo,

ich hatte zunächst gedacht, mein Fehler hängt mit dem Bug in einigen AVR 
zusammen, dass EEPROM-Adresse 0 fehlerhaft ist.
Nach einem Blick ins Listing scheint das aber nicht der Fall zu sein.

Ich habe eine Variable (chip_erase_check) im EEPROM (verwende die 
avr-libc Funktionen) die auf einen bestimmten Wert geprüft wird. Ist 
dieser Wert nicht vorhanden, werden alle EEPROM-Variablen mit ihren 
Default-Werten beschrieben und der erwartete Wert in die Check-Variable 
geschrieben:

/// EEPROM variables
uint8_t    chip_erase_check EEMEM,
      prog_speed_eemem EEMEM = 170,
      prog_wait_eemem EEMEM = 170;
uint16_t  powerleda_on_eemem EEMEM = 1023,
      powerledb_on_eemem EEMEM = 1023;


// ...


void check_eemem(void){
  
  uint8_t temp;
  temp = eeprom_read_byte(&chip_erase_check);
  
  #define CHECK_NEGATIVE 0xAA
  if(temp == CHECK_NEGATIVE){
    return;
  }
  
  PROG_ACTIVE_PORT |= (1<<PROG_ACTIVE); // indicate EEPROM default writing
  
  eeprom_write_byte(&prog_speed_eemem, 175);
  eeprom_write_byte(&prog_wait_eemem, 175);
  eeprom_write_word(&powerleda_on_eemem, POWERLED_ON);
  eeprom_write_word(&powerledb_on_eemem, POWERLED_ON);
  
  eeprom_write_byte(&chip_erase_check, CHECK_NEGATIVE);
  
}

Das hat anfangs alles wunderbar funktioniert. Seit neustem wird der 
EEPROM aber bei jedes mal, nachdem die Spannung weg war, neu 
beschrieben, der Wert der Variable ist also verloren gegangen. Woran 
kann das liegen? Was tuen?
Es gibt sonst keine Stellen im Programm, die diese Variable beschreiben, 
da bin ich sicher ;)

LG :)

PS: Sind die EEPROM-Funktionen der avr-libc eigentlich schon gegen 
Unterbrechung durch Interrupts gesichert, oder muss ich das selber 
machen? Die Interrupts werden aber erst nach Aufruf von check_eemem() 
aktiviert.

[Oliver (Gast)]

Die klassische Antwort zu dem Problem lautet brown-out.

(eigentlich lautet sie RTFM)

Oliver

[J. W. (jw-lighting)]

Hallo Oliver,

vielen Dank für deine Hilfe. Das scheint echt was gebracht zu haben. 
Trotzdem spinnt der Controller nach dem Einschalten jetzt manchmal und 
macht Sachen, die er nicht tuen soll. Nach ca. 10 Tests scheint der 
EEPROM jetzt aber zu arbeiten, wie er soll.
Ich habe den BOD auf 4,3V eingestellt.

Da ich den µC am Netzteil und mit recht dicken Elkos betreibe hatte ich 
nicht mit einem Problem durch die Versorgungsspannung gerechnet. Dazu 
kommt, dass ich nur in Erinnerung hatte, es könne Probleme beim 
Schreiben durch zu niedrige Spannung geben. Und da ich nicht schreibe, 
während die Spannung instabil ist (das ist sie nur kurz nach einschalten 
und beim Entladen nach dem Ausschalten, habs mit dem Oszi nachgemessen) 
hatte ich das ausgeschlossen.

LG :)

[Uwe (de0508)]

Wie hoch ist der Takt?

mir kam noch eine Idee die sich mal auf den attiny861 bezog, dort war 
bei 10MHz schluss, um das eeprom geschreiben zu können.

[pompete (Gast)]

J. W. schrieb:
> Seit neustem wird der
> EEPROM aber bei jedes mal, nachdem die Spannung weg war, neu
> beschrieben, der Wert der Variable ist also verloren gegangen. Woran
> kann das liegen? Was tuen?

....programm nochmals prüfen, irgendwo läuft dein programm am anfang 
entweder amok (interruptproblem?) oder verirrt sich sonstwie in deine 
eeprom-routine.
von alleine beschreibt sich das teil nicht.....ich würde z.b. die 
eeprom-routine in einem kleinen testprogramm isolieren und etwas in den 
eeprom schreiben lassen, ohne interrupts und den ganzen kladeradatsch.
wenn nun nach dem einschalten nix verloren geht, nacheinander 
komponenten hinzufügen.....manchmal ist der umständliche weg der 
schnellste.....

[Michael (Gast)]

J. W. schrieb:
> Da ich den µC am Netzteil und mit recht dicken Elkos betreibe hatte ich
> nicht mit einem Problem durch die Versorgungsspannung gerechnet.

Wo hast du die "recht dicken Elkos", am Eingang oder/und Ausgang deinen 
Spannungsreglers (welcher?)? Und hast du die VCC direkt am µC mit 100 nF 
abgeblock? Ein dicker Elko bringt nichts gegen kurze Strombedarsspitzen.

[J. W. (jw-lighting)]

Hallo,

dank für die weiteren Antworten ! ;)

Uwe S. schrieb:
> Wie hoch ist der Takt?

8MHz vom Quarz ohne Teilung durch acht (CKDIV8 unprogrammed)

pompete schrieb:
> ....programm nochmals prüfen, irgendwo läuft dein programm am anfang
> entweder amok (interruptproblem?) oder verirrt sich sonstwie in deine
> eeprom-routine.
> von alleine beschreibt sich das teil nicht.....

Bisher gabs keine Probleme mit dem EEPROM mehr, seitdem die BOD 
aufpasst.
Andernfalls werde ich dem dann aber sicherlich nachgehen.
Interrupts sind aber, wie gesagt nicht aktiviert während die 
check_eemem-Funktion ausgeführt wird. Die kommt nur einmal vor der 
Hauptschleife und vor sei() vor.
Kann ich den davon ausgehen, dass die EEPROM-Funktionen der avr-libc 
atomar sind? Oder muss ich mich da selbst drum kümmern?

Michael schrieb:
> Wo hast du die "recht dicken Elkos", am Eingang oder/und Ausgang deinen
> Spannungsreglers (welcher?)? Und hast du die VCC direkt am µC mit 100 nF
> abgeblock? Ein dicker Elko bringt nichts gegen kurze Strombedarsspitzen.

Ich habe 470µ direkt beim µC, sowie die obligatorischen 100n. Am 
Schaltnetzteil (Meanwell S-40-5, direkt 5V, daher kein Stabi in der 
Schaltung) habe ich zudem nochmal 6.800µ. Die dienen aber ehr dazu, die 
ungleichmäßige Belastung durch PWM (f=1kHz) auf zwei 5W-LEDs ein wenig 
auszugleichen.
Das Schaltnetzteil kommt damit aber gut zurecht, wie gesagt, habe mit 
dem Oszi nachgemessen.
Der BOD spricht darauf auch nicht an.

LG :)

[Peter D. (peda)]

J. W. schrieb:
> Da ich den µC am Netzteil und mit recht dicken Elkos betreibe hatte ich
> nicht mit einem Problem durch die Versorgungsspannung gerechnet.

Gerade dadurch kann die VCC langsam absinken. Irgendwann kann dann bei 
der Programmausführung ein Fehler passieren und die CPU springt in den 
Wald, vielleicht zufällig zur EEPROM-Schreibroutine.
Das BOR hält bei Unterspannung die CPU in Reset und damit kann sie 
keinen Code falsch ausführen.


Peter

[pompete (Gast)]

Peter Dannegger schrieb:
> Gerade dadurch kann die VCC langsam absinken. Irgendwann kann dann bei
> der Programmausführung ein Fehler passieren und die CPU springt in den
> Wald, vielleicht zufällig zur EEPROM-Schreibroutine.
> Das BOR hält bei Unterspannung die CPU in Reset und damit kann sie
> keinen Code falsch ausführen.

....das klingt sinnig und würde die sache mit dem verbesserten verhalten 
bei eingeschaltetem BOD erklären....

[J. W. (jw-lighting)]

Hey,

danke Peter, so langsam leuchtet das ein, ja. ;)
Das erklärt auch, warum der Fehler nur beim erneuten Einschalten 
aufgetreten ist.

LG :)