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?
Paul schrieb: > denkbar ist vieles. Aber überprüfbar, Fakten: Null! Null Komma gar nix. Außer Prosa nix gewesen....
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.