ATMega328P EEPROM hat geänderte Werte ohne das geschrieben wurde

[PICture]

Dann müsste die Ursache der Veränderungen gefunden werden um sie beseitigen zu können. Ich würde gegen statische Aufladung die µCs mit an GND angeschlossener Alufolie umwickeln um sie davor zu schützen versuchen, usw.

[sast]

Die Controller befinden sich bereits separat in Alugehäusen. Allerdings ist eine Ableitung nicht möglich, da sich das Gerät auf einem Plastikrohr bewegt.

[PICture]

Vielleicht könnte man auf dem Rohr geerdete Metallrige (z.B. aus Draht) plazieren, weil es nicht permanenter Kontakt nötig ist, sondern nur die schon vorhandene Ladung ab und zu ableiten.

[Klebwax]

Das Flash soll laut Datenblatt für zehntausend Zyklen und das EEPROM für hunderttausend gut sein. Und die Daten sollen sogar bei 85° noch 20 Jahre halten, bei 25° sogar 100. Das da ein generelles Problem vorliegt und das dann nicht in einem Erata dokumentiert ist, kann ich nicht glauben. Eine typische Amerkanische Schadensersatzklage z.B. von einem großen Autohersteller hätte Atmel sonst schon längst in den Ausguß gespült.

ESD direkt wird es auch nicht sein, da kippt das RAM schneller und der Rechner stürzt ab. Um ein EEPROM Byte zu ändern braucht man schon etwas Energie, deswegen dauerts ja auch länger als das Schreiben ins RAM. Aber ein Absturz könnte es schon sein, ein Interrupt zum falschen Zeitpunkt, der Watchdog oder ähnliches. Und wenn man bei mehreren Controlern gleiche Codeteile verwendet, erklärt das auch das gehäufte Auftreten.

MfG Klebwax

[sast]

Hi Klebwax, das mit dem Interrupt versteh ich noch nicht so ganz. Meinst du, dass während des Schreibens auf den EEPROM eine Unterbrechung stattfindet? Das Brennen selbst kann dann wohl auch durch den Interrupt gestört werden?

Geschrieben wird grundsätzlich nur wenn das Gerät steht. Da könnte ich theoretisch auch die Interrupts deaktivieren, solange die write Routine auf das EEPROM schreibt.
Im Normalfall lese ich beim Start des Controllers nur den EEPROM aus und danach wird da nichts mehr dran gemacht. Schreiben geschieht nur, wenn etwas drin steht, was ich nicht erwarte, oder wenn ich etwas ändere über die Schnittstelle.
Das macht aber beim Einsatz des Gerätes niemand. Und schon gar nicht wird die ID verändert ohne Zugriff über UART. Das bereitet mir Kopfzerbrechen.

PICture das Gerät fährt auf jedem Rohr nur einmal. Da macht es keinen Sinn etwas aufs Rohr zu machen.

[damfino]

Hi,
im Datenblatt steht dass man Interrupts ausschalten soll wenn man ins EEPROM schreibt.Ob das die Lib selber macht ist mir unklar, einmal steht es wird automatisch erledigt, an anderer Stelle dass man selbst die Interrupts ausschalten muss.
Ebenso werden bei Unterspannung und gleichzeitigem Schreiben ins EEPROM die Daten verändert.

LG!

[sast]

Hier mal einen Codeausschnitt

#define EEPROM_VNULL            230

uint8_t get_eeprom(uint8_t *eeprombuf, uint16_t eepromaddr, uint8_t buflength)
{
    eeprom_read_block((void*)eeprombuf, (const void*)eepromaddr, buflength);
    return strlen((char*)eeprombuf);
}

uint8_t set_eeprom(uint8_t *eeprombuf, uint16_t eepromaddr, uint8_t buflength)
{
    eeprom_write_block((const void*)eeprombuf, (void*)eepromaddr, buflength);
    return get_eeprom(eeprombuf, eepromaddr, buflength);
}

for(i = 0; i<11; i++) hilfstext[i] = 0;
    get_eeprom((unsigned char*)hilfstext, EEPROM_VNULL, 10);
    if((atoi(hilfstext) > 5000) || (hilfstext[0] == 0xFF))
    {
        for(i = 0; i<11; i++) hilfstext[i] = 0;
        hilfstext[0] = '2';
        hilfstext[1] = '7';
        hilfstext[2] = '6';
        hilfstext[3] = '5';
        set_eeprom((unsigned char*)hilfstext, EEPROM_VNULL, 10);
        for(i = 0; i<11; i++) hilfstext[i] = 0;
        get_eeprom((unsigned char*)hilfstext, EEPROM_VNULL, 10);
    }
    SERVO_NULL = atoi(hilfstext);

Wenn der EEPROM einmal geschrieben wurde, sollte eigentlich bei jedem Controller Neustart nur noch gelesen werden.

Konkret stand beim Auslesen des EEPROMs vor Ort 0x322C3635 im EEPROM statt des erwarteten 0x32373635. Es war also auch nur ein Byte verändert.
Das Gerät ist aber bereits seit November im Einsatz und hatte bis dahin keine Schwierigkeiten.

Habe ich eventuell ein grundlegend falsches Konzept bei der Verwendung des EEPROMs? Wo liegt mein Denkfehler?

Danke
sast

[oberallgeier]

... Habe ich eventuell ein grundlegend falsches Konzept bei der Verwendung des EEPROMs? Wo liegt mein Denkfehler? ...

Gute Fragen, die musste ich mir nicht nur bei EEPROMS häufig stellen - auch wiederholt.

Das Datenblatt ATmega48A/PA/88A/PA/168A/PA/328/P 8271G–AVR–02/2013 gibt im Beispielcode Seite 14 an, dass vor dem Schreiben das Interruptregister gesichert wird, danach werden Interrupts verboten, EEPROM schreiben, Interruptregister zurücklesen.

Auf Seite 19, Punkt 8.4.1 wird auch über mögliche Fehlerursachen diskutiert...

Ich selbst kenne aktuell keine EEPROM-Probleme obwohl bei meinen Controllern immer wieder mal z.B. zulässige Grenzwerte geändert, im EEPROM gespeichert und im Programmablauf auch wieder ausgelesen werden.

[sast]

Hallo oberallgeier, mal davon abgesehen, dass ich das Interruptabschalten mal noch in meine Betrachtung aufnehmen muss, wurde ja seit November nichts neues mehr an diese EEPROM Stelle geschrieben. Der Wert wurde ja bereits beim ersten Start gesetzt und lief bis letzte Woche ohne Probleme. Speziell diesen EEPROM Speicherbereich habe ich im aktuellen Code noch nicht einmal per UART änderbar gemacht. Genau diese Änderung gibt mir am meisten zu denken.