Hallo,
Ich verwende einen 1K EEPROM zum Speichern von diversen Einstellungen.
Seit kurzem habe ich ein merkwürdiges Phänomen beobachtet: Nach dem
Ausschalten und erneutem Einschalten veränderten sich in zwei bestimmten
Speicheradressen die Werte. In einem stand plötzlich 0 statt 30, in
einem anderen 256 statt 308. Ich verwende zahlreiche Speicheradressen
des EEPROM-Chips, begonnen bei den unteren Adressen, also 0,4,8,..
jeweils 4 bytes für einen Speichereintrag als Zahl(uint32_t). Die beiden
betroffenen Speicheradressen liegen nicht nebeneinander (die eine ist
32, die andere 608).
Ich habe durch zig-Maliges Aus- und wieder Einschalten versucht, den
Vorgang zu simulieren bzw. auf irgend einen Zusammenhang zu kommen, was
mir nicht gelang. Das Problem tritt nicht bei jedem Aus- und
Einschalt-Vorgang auf, nur ganz selten, weshalb es auch so schwierig
ist, etwaige Ursachen zu finden. Wenn diese Verhalten auftritt, dann
werden immer genau die selben beiden Einstellungen auf die besagten
Werte 0 und 256 geändert. Aus meiner Sicht wird während des Aus- und
Einschalt-Vorganges nichts in den EEPROM geschrieben, weshalb ich auch
nicht an einen Programmierfehler glaube.
Die betroffenen Speicherzellen wurden bei weitem nicht so oft neu
beschrieben wie ihre typische Lebensdauer.
Meine Konkrete Frage: Kann so ein Verhalten hardware-bedingt sein? D.h.
ein Speicherfehler, der manchmal auftritt und dann aber immer den
gleichen falschen Wert liefert? Und das an zwei unterschiedlichen
Speicher-Adressen? Klingt relativ unwahrscheinlich, aber die
Alternative, dass es doch programmtechnischer Natur ist, ist auch nicht
wahrscheinlicher, da der Fehler manchmal auch auftritt, wenn die
Anwendung gar nichts getan hat, außer Aus- und wieder Einschalten. Ich
bin natürlich dran, mein Programm nach Fehlern zu durchsuchen, habe aber
nach zig Stunden nichts bedenkliches gefunden, weshalb ich mal
vorsichtig anfragen wollte, ob solch ein Verhalten in irgendeiner Weise
durch einen Hardwarefehler erklärbar sein kann. Is es denkbar, dass ein
Speicherfehler noch sporadisch auftritt, oder müsste der dann immer nach
Aus-und Einschalten auftreten? Gibt es eine Erklärung, weshalb immer die
gleichen zwei getrennten Speicherplätze gleichzeitig betroffen sind?
Nachdem ich software-seitig nichts finden konnte, sehe ich ansonsten nur
zwei Möglichkeiten: Einige Programmteile neu programmieren, evtl. mit
anderen Speicherplätzen, um zu sehen, ob der Fehler dann immer noch
(oder vielleicht an anderen Adressen) auftritt, andere Möglichkeit wäre
Austauschen des EEPROMs. Vorab würde ich aber gerne um Einschätzung
bitten, wie so ein Verhalten möglicherweise am ehesten zu erklären ist.
Ich möchte vermeiden, dass ich (mit viel Aufwand) beispielsweise
umprogrammiere, aber ohne Garantie, ob der Fehler dann nicht erst recht
wieder auftritt, wenn er doch hardware-seitig bedingt war. Umgekehrt
bringt der Hardware-Tausch auch nichts, wenn es doch die Software war.
Wie ist eure Einschätzung?
Ich weiß, dass ich mich sehr allgemein ausgedrückt habe.
Den Programmcode kann ich nicht veröffentlichen, weil es ein
kommerzielles Produkt ist, und weil es auch nicht wirklich zumutbar ist,
dass sich jemand die 100 Textseiten durchschaut. Ich möchte einfach nur
wissen, ob es theoretisch möglich ist, dass ein EEPROM-Speicher solche
Anomalien zeigt, oder ob das auf jeden Fall ein Software-Problem sein
muss, weil es eben ausgeschlossen ist, dass sich ein EEPROM so
verhält...
Paul schrieb:> Ich verwende einen 1K EEPROM zum Speichern von diversen Einstellungen.
Gibt ja nur drölfzig EEPROM-Hersteller und EEPROM-Typen und
EEPROM-Interfaces. Vermutlich hast du genau den Chip eingebaut, bei dem
im Datenblatt als Feature "Random content every 10k reads" steht. Kann
schon mal passieren, wenn man das Datenblatt nicht liest.
> Aus meiner Sicht wird während des Aus- und Einschalt-Vorganges> nichts in den EEPROM geschrieben, weshalb ich auch nicht an einen> Programmierfehler glaube.
Du solltest erstmal an ein Oszilloskop oder einen Logicanalyzer glauben.
Das schafft Erleuchtung.
Hallo,
ist das EEPROM Bestandteil eines Microcontrollers? Wenn ja, dann wäre
mein Verdacht eine unvollständige bzw. nicht vorhandene
Brownout-Schaltung, die den Controller bei Unterschreiten der minimal
zulässigen Versorgungsspannung sofort anhält.
Selbiges wäre auch der Fall, wenn das EEPROM ein externer I2C- oder
SPI-Typ ist.
Außerdem wäre (mit Oszi) zu prüfen, ob die Versorgungsspannung beim Ein-
und Auschalten wilde Haken schlägt. So was hab ich schon bei einfachen
Netzteilen mit primärseitigem Schalter, Trafo, Gleichrichter,
Spannungsregler und zugehörigen Elkos gesehen.
MfG Wuff_W
Hm
Kein Hersteller, Kein Typ (I2C, SPI, 8Bit parallel(so wie früher) ).
Und eine Speicherstelle mit 308 habe ich noch nie erlebt, weil die
Eeproms meist Byte orientiert sind. Da muss woanders ein Problem sein.
Entweder gibt es noch Fakten, oder das war ein Beichtstuhlposting, um
das Gewissen zu befrieden. Dann bekommst du jetzt Absolution von mir.
Achja: und die 100 Seiten Text: meine EEprom (24AA01-EMC) Routine für
den STM-32 ARM hat 420 Zeilen.
Paul schrieb:> Umgekehrt bringt der Hardware-Tausch auch nichts, wenn es> doch die Software war.
Aber der Hardware-Tausch (des EEPROMs) ist wahrscheinlich deutlich
weniger Aufwand als Du bisher schon in die Suche nach dem Fehler
gesteckt hast.
Wenn danach das Fehlerbild lange genug nicht mehr auftritt, dann kannst
Du mit hoher Wahrscheinlichkeit davon ausgehen, daß es ein
Hardwaredefekt war; bzw. umgekehrt, sollte sich nach dem EEPROM-Tausch
irgendwann ein identes Fehlerbild zeigen, dann weißt Du, daß es an der
Software liegen muß.
Außerdem kannst Du, sofern diese beiden Werte an den konkreten Adressen
normalerweise nie auftreten können, automatisch beim Programmstart
überprüfen, ob der Fehler aufgetreten ist.
Brownout wurde schon genannt, ansonsten auch mal einen Zugriffszähler
(Write Counter) mit in den Datensatz einbauen. Dann kann man sehen, ob
wirklich nur zu den beabsichtigten Zeitpunkten geschrieben wird. Und
wenn man es ordentlich machen will: Datensatz mit CRC doppelt ablegen,
z.B. in untere und obere EEPROM Hälfte. Beim Startup stets prüfen, ob
beide Datensätze okay und ggf. korrigieren, dabei nur den defekten
Datensatz anfassen. Vorher nichts anderes machen. Beim Schreiben im
normalen Programm streng nacheinander schreiben.
Kann man auch im Nachhinein einbauen, davon wird das Hauptprogramm nicht
beeinflusst werden.
Falls Du das mit dem doppelten Datensatz so baust führe bitte neben dem
Write Counter noch einen Zähler ein, wie oft der Datensatz gerettet
werden musste.
Übrigens gibt es unzählige dilettantische Produkte, bei denen das EEPROM
Handling nicht sauber implementiert wurde und der Kunde dann durch
gelegentliche Ausfälle das Nachsehen hat (z.B. meine Jalousiemotoren von
Elero)
Baue bitte nicht noch eins.
Georg A. schrieb:> Gibt ja nur drölfzig EEPROM-Hersteller und EEPROM-Typen und> EEPROM-Interfaces.
Genau.
Ein Link auf das Datenblatt oder die vollständige Bezeichnung wäre das
absolut mindeste.
Wir sind hier ja nicht bei den Kaffeesatzlesern.
Paul schrieb:> Ich verwende zahlreiche Speicheradressen> des EEPROM-Chips, begonnen bei den unteren Adressen, also 0,4,8,..> jeweils 4 bytes für einen Speichereintrag als Zahl(uint32_t).
Hi,
und ohne "atomic" Schreibroutine? Haut noch ein Interrupt dazwischen?
https://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
ciao
gustav
Hier kann kaum gesagt werden, was die Ursache dieses Verhalten ist.
Insofern kann auch mein Beitrag nur ein Denkanstoß sein, denn das
gleiche Problem hatte ich auch einmal. Es ging um ein
Batteriebetriebenes Gerät und beim Einlegen der Batterie prellte die
Versorgungsspannung zwangläufig mehrmals und der Controller startete
daher auch mehrmals. In der Anfangssequenz wurde auch das EEPROM
„gelesen“. Diese Lesevorgänge brachen durch das Prellen natürlich ab.
Das EEPROM blieb aber wegen der Pufferung (ausreichend) an Spannung und
dann konnte es passieren, dass sich ein erneuter READ Zugriff zu einem
WRITE Zugriff verwandelte, da das EEPROM noch Daten im Empfangspuffer
hatte. Als die Ursache klar war, konnte man geeignete Gegenmaßnahmen
ergreifen.
Viel Erfolg
Vielen Dank für eure Antworten, da waren wirklich gute Tipps dabei.
Vielleicht noch etwas zur Hardware:
Der EEPROM, von dem ich spreche, befindet sich an Bord eines NEXTION
HMI:
https://nextion.tech/enhanced-series-introduction/
Das Beschreiben selbst übernimmt die (closed Source) Firmware des
NEXTION.
Im NEXTION ist folgender EEPROM verbaut:
http://ww1.microchip.com/downloads/en/devicedoc/doc0180.pdf
Leider habe ich kein Oszilloskop zur Verfügung. Ich werde mal das
NEXTION tauschen und sehen, ob der Fehler dann immer noch (oder
womöglich in einer anderen Speicher-page?) auftritt. Es bleibt aber ein
Unsicherheitsfaktor, da der Fehler eben nur sporadisch auftritt.
Eigentlich hätte ich schon gerne Gewissheit, wo die Ursache liegt...
Michael schrieb:> dann konnte es passieren, dass sich ein erneuter READ Zugriff zu einem> WRITE Zugriff verwandelte,
Gibt es zu dem Phänomen irgendetwas an Lesestoff? Davon habe ich noch
nie gehört.
Wolfgang W. schrieb:> Außerdem wäre (mit Oszi) zu prüfen, ob die Versorgungsspannung beim Ein-> und Auschalten wilde Haken schlägt.
Wenn die zB. über einen Hohlstecker oä. läuft, bräucht's evtl. nen
dickeren Elko vom Regler!?
Paul Kaiser schrieb:> Es bleibt aber ein> Unsicherheitsfaktor, da der Fehler eben nur sporadisch auftritt.
Ganz klar. Sporadische Fehler sind die Pest. Hier scheint mir der Tausch
auch erst mal der beste Ansatz. Da muß man halt hoffen, das sich etwas
verwertbares zeigt. Parallel dazu könnte man versuchen, das EEprom mit
einer Testsoftware separat zu quälen. "Einschalten" und "Ausschalten"
wären im Hinblick auf ein EEprom vielleicht noch gesondert zu
untersuchen. Außerdem sollte bestimmt dieser Zugriffszähler rein.
Ungewollte Zugriffe auf das EEprom müssen natürlich auch sicher
ausgeschlossen werden. Ansonsten kannst du ja die Konsistenz des ganzen
Datensatzes überhaupt nicht garantieren. Ich bin gespannt!
Gruß Rainer
Mal angenommen, der Speicherfehler hat was mit Spannungsspitzen zu tun:
Ist es tatsächlich denkbar, dass der Fehler immer an der selben Adresse
und dem gleichen "falschen" Wert auftritt?
Teo schrieb:> Wenn die zB. über einen Hohlstecker oä. läuft, bräucht's evtl. nen> dickeren Elko vom Regler!?
Soweit ich das jetzt überblicken kann, wird das schwierig. Ich habe nur
über eine Funktion Zugriff auf das von mir gewollte EEPROM Lesen und
Schreiben. Was genau das NEXTION während dem "Setup" macht, entzieht
sich meiner Kenntnis. Ich weiß nicht, ob es viel Sinn macht, wenn ich
bei den Chinesen anfrage, wie bzw. ob sie das EEPROM Lesen und schreiben
handlen...
Rainer V. schrieb:> Außerdem sollte bestimmt dieser Zugriffszähler rein.> Ungewollte Zugriffe auf das EEprom müssen natürlich auch sicher> ausgeschlossen werden. Ansonsten kannst du ja die Konsistenz des ganzen> Datensatzes überhaupt nicht garantieren. Ich bin gespannt!> Gruß Rainer
I2C-EEPROM sind sehr sicher. Sie benötigen eine Sequenz von 5 Aktionen,
damit ein Schreiben erfolgt (Start, Deviceadresse, Memoryadresse, 1.
Datenbyte, Stop).
Es liegt daher mit Sicherheit ein Problem in der CPU oder Firmware vor.
Es kann sein, daß die CPU kein ordentliches Power-On-Reset macht, z.B.
in den Konfigurationsbits keine oder eine zu kleine
Unterspannungsschwelle enabled ist.
Notfalls muß man einen externen Supervisor-IC an den Resetpin der CPU
hängen, um ein sauberes Reset zu erzwingen.
Danke peda für deine Einschätzung. Aber was genau passiert im
EEPROM,wenn das Power-On_Reset nicht korrekt ausgeführt wird? Wie kann
es sein, dass immer genau an der gleichen Stelle der Fehler auftritt?
Müsste dann nicht viel eher ein "allgemeines" Datenchaos herrschen?
Peter D. schrieb:> I2C-EEPROM sind sehr sicher. Sie benötigen eine Sequenz von 5 Aktionen,> damit ein Schreiben erfolgt (Start, Deviceadresse, Memoryadresse, 1.> Datenbyte, Stop).> Es liegt daher mit Sicherheit ein Problem in der CPU oder Firmware vor.> Es kann sein, daß die CPU kein ordentliches Power-On-Reset macht, z.B.> in den Konfigurationsbits keine oder eine zu kleine> Unterspannungsschwelle enabled ist.> Notfalls muß man einen externen Supervisor-IC an den Resetpin der CPU> hängen, um ein sauberes Reset zu erzwingen.
Paul Kaiser schrieb:> Mal angenommen, der Speicherfehler hat was mit Spannungsspitzen zu tun:> Ist es tatsächlich denkbar, dass der Fehler immer an der selben Adresse> und dem gleichen "falschen" Wert auftritt?>> Teo schrieb:>> Wenn die zB. über einen Hohlstecker oä. läuft, bräucht's evtl. nen>> dickeren Elko vom Regler!?
Eigentlich garnicht, wäre rein zufällig.
Nur wenn der Brownout der Auslöser für diesen Schreibzykluses wäre.
Paul Kaiser schrieb:> Ich weiß nicht, ob es viel Sinn macht, wenn ich> bei den Chinesen anfrage, wie bzw. ob sie das EEPROM Lesen und schreiben> handlen...
Na, dann solltest du es aber herausfinden. Wenn du quasi überhaupt
keinen Zugang zum System hast außer einer Schreib- und Lesefunktion,
dann ist es doch unmöglich mehr zu machen, als den Datenfehler
festzustellen! Ich würde mir da jetzt Gedanken machen, wie ich die
Fehler "wasserdicht" dokumentieren könnte. Und wenn dann auch für deinen
Chef zweifelsfrei feststeht, dass es Fehler gibt, wird man die weitere
Vorgehensweise festlegen müssen. Das sieht alles nach unendlichem Ärger
aus! Bin weiter gespannt...
Gruß Rainer
Paul Kaiser schrieb:> Wie kann> es sein, dass immer genau an der gleichen Stelle der Fehler auftritt?
Das würde für mich sehr stark für einen Firmwarefehler sprechen.
Ein fehlendes Unterspannungsreset kann dazu führen, daß mit Absinken der
VCC die CPU nicht mehr richtig arbeitet, an eine falsche Adresse springt
und schnell noch einen Schreibbefehl an das EEPROM schickt.
Wie oft muß denn der EEPROM geändert werden?
Man könnte über einen Jumper oder Schalter den WP-Pin auf Read-only
(VCC) setzen.
Du meinst, dies tritt auf, wenn ein gewollter Schreibbefehl während dem
Herunterfahren der Spannung erfolgt und durch den Spannungsabfall falsch
geschrieben wird? Oder entsteht dieser Schreibbefehl durch den
Spannungsabfall? Das wäre ja eher unwahrscheinlich bei dem, was du über
das Protokoll dieser EEPROMs gesagt hast, richtig?
Soweit ich das beobachtet habe, habe ich während des Ausschaltens keinen
Schreibbefehl erteilt, als der Fehler das letzte Mal auftrat.
So wie ich mir das vorstelle, passiert der Fehler auf jeden Fall immer
im gleichen Ablauf und Timing, da es sonst ja praktisch ausgeschlossen
ist, dass an der gleichen Speicheradresse falsch geschrieben wird. Wie
ist das eigentlich mit dem I2C- Schreib-Protokoll? Ich nehme an, nur
eine "elektrische Störung", also eben ein Spannungsabfall etc. kann zu
so einem Schreibfehler führen, oder? Oder anders formuliert: Ein
softwareseitiges Falsch-behandeln, indem ich z.B. einen neuen
Schreib-Befehl sende, bevor der alte abgeschlossen ist, ist nicht
denkbar, oder? Ich nehme an, der EEPROM würde den neuen Schreibbefehl
erst ausführen, wenn der erste abgeschlossen ist, oder?
Das mit dem WP-Pin ist natürlich eine super Idee, aber der
Endverbraucher soll jederzeit Einstellungen ändern können, ohne einen
Jumper oder Schalter zu betätigen. Super wäre natürlich, wenn mein uC
Zugriff auf den WP hätte, das NEXTION Display ist aber leider nur über
die Serielle Schnittstelle mit dem uC verbunden, da geht also nichts :-(
Peter D. schrieb:> Ein fehlendes Unterspannungsreset kann dazu führen, daß mit Absinken der> VCC die CPU nicht mehr richtig arbeitet, an eine falsche Adresse springt> und schnell noch einen Schreibbefehl an das EEPROM schickt.>> Wie oft muß denn der EEPROM geändert werden?> Man könnte über einen Jumper oder Schalter den WP-Pin auf Read-only> (VCC) setzen.
