EEPROM - ausgelesener Wert ist ungenau

[hardware.bas]

Ich hatte mal ein Problem mit einem AVR, wollte mit der Zuweisung EEPROMVARIABLE = WERT abspeicher. Da musste ich
feststellen, dass die erste EEPROM-Zelle warscheinlich nicht funktioniert. Nachdem ich eine EEPROM-Dummyfunktion im
Quelltext davor reingeschrieben habe, lief es.
VG Micha

[oberallgeier]

.. musste ich feststellen, dass die erste EEPROM-Zelle warscheinlich nicht funktioniert. Nachdem ich eine EEPROM-Dummyfunktion ..

Es ist sicher fünf Jahre her, da hatte ich dasselbe Problem festgestellt und etliche Hinweise auf ne Dummyfunktion gefunden. Seit der Zeit definiere*) ich wie folgt und habe keine Probleme:

// ###>>> Byte-Array, das erste Byte des EEPROMS gilt als nicht vertrauenswürdig
  uint8_t   firstByteDummy      EEMEM; 
  uint8_t   eeDUMMYbytes [100]  EEMEM;  // Dummies
  uint8_t   eeBytes [12]        EEMEM;  // ?? Allzweckbytes ??
  uint16_t  eeSrvoff[12]        EEMEM;  // Servo-Position - Offset
  u8    SVT[12][11]             EEMEM;  // Servotexte

*) vgl. Kernighan-Ritchie, Vorwort zur deutschen Ausgabe
Definition: Eigenschaft und Speicherplatz
Deklaration: nur Eigenschaft

[shedepe]

Dass es einzelne Zellen defekt sind, kann passieren. Jedoch konnte ich keine Hinweise finden, dass Zelle 0 per se kaputt ist.

fas EEPROM.put() bzw. EEPROM.get() auch int oder float akzeptieren

Stimmt. Da Arduino C++ ist, kann man die Funktionen natürlich entsprechend überladen.

Ein Dummy Read Write auf den EEPROM ist eine gute Idee.
Ein weiterer Punkt auf den das Datenblatt hinweist, ist dass der EEPROM Inhalt korrumpiert werden kann, wenn man versucht bei zu geringer Versorgungsspannung zu lesen oder zu schreiben. Das ist in diesem Fall aber denke ich auszuschließen. (Nur der Vollständigkeit halber erwähnt)

[oberallgeier]

.. Ein Dummy Read Write auf den EEPROM ist eine gute Idee ..

Danke. So weit ich mich erinnern kann stammt die Idee aus diesem Forum (oder aus mikrocontroller.net).

.. Ein weiterer Punkt auf den das Datenblatt hinweist, ist dass der EEPROM Inhalt korrumpiert werden kann ..

Genau das hatte ich vorhin vergessen zu erwähnen und wollte es eben nachtragen. Auf dem Arduino Pro Mini dürfte ja ein mega328p drauf sein, zu dem schreib t das Datenblatt :

..
12.4.2. Preventing EEPROM Corruption
During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is too low for
the CPU and the EEPROM to operate properly. These issues are the same as for board level systems
using EEPROM, and the same design solutions should be applied.
An EEPROM data corruption can be caused by two situations when the voltage is too low. First, a regular
write sequence to the EEPROM requires a minimum voltage to operate correctly. Secondly, the CPU itself
can execute instructions incorrectly, if the supply voltage is too low.
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). If the detection level of the internal BOD does not
match the needed detection level, an external low VCC reset Protection circuit can be used. If a reset
occurs while a write operation is in progress, the write operation will be completed provided that the
power supply voltage is sufficient.
..

Insgesamt lohnt es sich alle Abschnitte des Datenblatts zum EEPROM-schreiben-und-lesen wenigstens einmal ordentlich durchzulesen.

Ich komme auch wirklich nicht klar wie Du Deine Umrechnung ".. ich speichere z.B. den Wert 8820, was 88,20 MHz .." machst und in welchem Format die erfolgt. Kannst Du uns bitte darüber auch aufklären?

[HaWe]

Mit Ungenauigkeit meinte ich, ich speichere z.B. den Wert 8820, was 88,20 MHz bedeutet. Bei Neustart tuned der chip aber z.B. auf 8800, also 88,0 MHz. Diese Abweichung ist nicht konstant! Manchmal stimmt der Wert auch.

tbh, ich habe den vagen Verdacht, dass der "Abrundungsfehler" nicht durch Datenkorruption zu erklären ist, denn 8820 und 8800 liegen nicht um 1 (gelöschtes) Low-Byte auseinander.
8800 dez = 00100010 01100000 bin
8820 dez = 00100010 01110100 bin

wäre es der Datenverlust bei LSB, ergäbe sich dezimal
00100010 00000000 bin = 8704 dez

Ich vermute daher den Fehler woanders, z.B. in einem Rundungsfehler in Soft- oder Firmware (z.B. Division Integer durch Integer).
Auch sonst müsste man bei zufälliger Datenkorruption "veränderte" Werte finden können, die nicht durch glattes Abrunden der letzten beiden Dezimalstellen, sondern eher auch durch randomisierte Vergößerung/Verkleinerung der Ausgangswerte auffallen, dazu wären auch mal einige (10-20) andere solcher beobachteter "Datenveränderungen" interessant zu sehen.

[basteluwe]

Ich denke, ich bin inzwischen etwas weiter:
Ich frage die Frequenz nach jedem Scan-Durchlauf ab und schreibe sie in den EEPROM. Das Problem liegt nun offensichtlich nicht in der EEPROM-Routine sondern im Wert, den der Radio-Chip auf den Befehl "radio.getFrequency()" zurück gibt. Der stimmt nämlich nicht in jedem Fall mit der aktuellen Frequenz überein. Ich lasse im Moment das Terminal mitlaufen und sehe daher die Abweichung zwischen der neu eingestellten Frequenz und dem nach dem Scan gemeldeten und gespeicherten Wert. Warum das so ist, weiß ich allerdings noch nicht.

Gruß Uwe

[oberallgeier]

.. bin inzwischen etwas weiter: Ich frage die Frequenz nach jedem Scan-Durchlauf ab und schreibe sie in den EEPROM. Das Problem liegt nun offensichtlich nicht in der EEPROM-Routine ..

Hallo Uwe,
prima dass Du die Lösung gefunden hast. Du denkst aber (auch) schon an das Datenblatt ? ? ?

..
• High Endurance Non-volatile Memory Segments
. . .
– Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
..

Na ja, jede Stunde ein Scandurchlauf (mal un?sinnigerweise 24/7) ergibt knapp 9000. Bis 100000 sinds dann zehn Jahre . . . ok, das kann passen. Aber evtl. ist ein durchtickern des Adressraums bei den Schreib-/Lesevorgängen trotzdem sinnvoll (und seis nur deswegen, damit man das mal gemacht hat *gg*)?

[basteluwe]

Ich denke so geht es jetzt:
Die EPROM-Bibliothek hat den update-Befehl, der nur in die Adresse schreibt, wenn der Inhalt abweicht. Allerdings geht das tatsächlich nur mit byte, nicht integer! Daher hab ich nun eine Umrechnung eingebaut. Die möglichen Frequenzwerte sind ja begrenzt und lassen das zum Glück zu. Ich habe diese Routine nun in der Hauptschleife drin, nicht mehr nach dem einzelnen Scannen. Alle 5 Sekunden läuft das und bisher hat er bei jedem Neustart (egal ob kalt oder Reset) die vorherige Frequenz exakt geladen.

if (millis() - previousMillis > 5000)
    {
    previousMillis = millis();
    frequency = (radio.getFrequency());       // Frequenz aus Radio auslesen  
    storeFreq = (frequency/10)-825;           // Frequenz in Speicherwert für EEPROM (byte) umrechnen
    EEPROM.update(0, storeFreq);              // falls neuer Speicherwert abweicht, dann update EEPROM
    }

Gruß Uwe

- - - Aktualisiert - - -

Hallo Uwe,
prima dass Du die Lösung gefunden hast. Du denkst aber (auch) schon an das Datenblatt ? ? ?
Na ja, jede Stunde ein Scandurchlauf (mal un?sinnigerweise 24/7) ergibt knapp 9000. Bis 100000 sinds dann zehn Jahre . . . ok, das kann passen. Aber evtl. ist ein durchtickern des Adressraums bei den Schreib-/Lesevorgängen trotzdem sinnvoll (und seis nur deswegen, damit man das mal gemacht hat *gg*)?

Ja das mit den 100.000 Durchgängen ist mir bewust. Das ist aber nicht wirklich ein Problem, denke ich. So oft, wird der Sender nicht gewechselt und täglich benutzt wird das Ding sicher nicht (schon gar nicht 24/7). Trotzdem Danke für den Hinweis

Uwe