Hallo, auf Sensoren sollen 24LC32A dazu dienen, Auslieferungs-Parameter des Sensors festzuhalten. Dazu werden bestimmte Speicherbereiche beschrieben. Es scheint nach längerer Nutzungszeit (anscheinend ohne Probleme) so zu sein, daß dieses Beschreiben nicht mehr sicher funktioniert. Der nette Mensch, der proprietäre Software (VEE) genutzt hat, ist nicht mehr zu erreichen. Ein Programmierer meint, es könne am Inhalt der frisch bestückten EEPROMs liegen. Wie sind die 24LC32A von Microchip im Auslieferungszustand beschrieben? Ich habe im Datenblatt keinen Hinweis gefunden - oder kann ich nur nicht richtig sehen? Wenn es nicht im Datenblatt steht, ist also jeder Inhalt im Auslieferungszustand des EEPROMs möglich? Ist es wahrscheinlich, daß die Fehler durch z.B. zu schnelle Schreibzugriffe entstehen? Doch dann müßte sich ja etwas am 24LC32A geändert haben.
:
Bearbeitet durch User
Matthias K. schrieb: > Ein Programmierer meint, es könne am Inhalt der frisch bestückten > EEPROMs liegen. Aha. Meinte er das. Soso. > Wie sind die 24LC32A von Microchip im Auslieferungszustand beschrieben? Sie werden gelöscht sein. Weiteres wird im Datenblatt stehen. Wenn es Probleme mit dem Beschreiben gibt, macht man das entweder zu oft (EEPROMs halten nur eine im Datenblatt spezifizierte Anzahl von Schreibzugriffen aus) oder man macht etwas falsch. Hardwareproblem (Störungen aus Signal- oder Versorgungsspannungsleitungen) oder Softwareproblem. Macht man alles richtig, funktionieren EEPROMs in zig Millionen Anwendungen auf diesem Planeten, seit Jahrzehnten.
EEPROMs sind in der Regel leer, also alles 0xFF. Ob das garantiert ist weiß ich nicht, aber wenn der Programmierer kein absoluter Volldepp ist, ist es egal was vorher drinsteht. Die Firmware erkennt, das es kein gültiger Datensatz ist und geht auf Defaults. Wenn es ein gültiger Datensatz ist, ist der Rest (oder was vorher vielleicht mal war) egal. Wenn Schreiben irgendwann ncht mehr geht (warum schreibt man Kalibrierdaten öfter als einmal?), ist der Speicher evtl. totgeschrieben? Oder hat jemand "write without verify" implementiert? Am Ende sogar "write and forget" ohne Verifikationsmöglichkeit? Kann man ja einfach ausprobieren: Chip tauschen, wenn es dann wieder geht: anderen Programmierer suchen und den die Firmware neu machen lassen. Evtl. ist auch der Hardwaredesigner ein Idiot, wenn im Buch steht das 100 Millionen Schreibzugriffe zu erwarten sind hat er den falschen Chip verbaut. Oder der BWLer, der dem Einkauf gesagt hat das Broker durchaus günstige Teile liefern. Oder: du baust endlos lebensfähiges MRAM oder FRAM ein, das kann man nicht totschreiben.
Matthias K. schrieb: > Es scheint nach längerer Nutzungszeit (anscheinend ohne Probleme) so zu > sein, daß dieses Beschreiben nicht mehr sicher funktioniert. Was heißt das genau? Scheitert das korrekte Rücklesen der neu geschriebenen Daten, aka Verify? > Der nette Mensch, der proprietäre Software (VEE) genutzt hat, ist nicht > mehr zu erreichen. Tja . . . > Ein Programmierer meint, es könne am Inhalt der frisch bestückten > EEPROMs liegen. Unfug. Wenn man einen EEPROM beschreibt, wird der erst gelöscht und dann neu beschrieben. > Wie sind die 24LC32A von Microchip im Auslieferungszustand beschrieben? Vollkommen egal. > Ist es wahrscheinlich, daß die Fehler durch z.B. zu schnelle > Schreibzugriffe entstehen? Jain. Man kann schon auf Software- und Hardwareebene einiges falsch machen. > Doch dann müßte sich ja etwas am 24LC32A > geändert haben. Unwahrscheinlich. Das Problem liegt eher bei euch und eurem selbstgemachten Murks incl. undokumentierter Programmierung.
Harald K. schrieb: > funktionieren EEPROMs in zig Millionen > Anwendungen auf diesem Planeten, Da gehören noch einige Nullen dran.
Nun gibt es doch etwas Erklärungsbedarf: Mit längere Nutzungszeit meinte ich die für das Programm zum Eintragen der Daten. Es werden die Auslieferungs-Parameter des Sensors geschrieben. Das erfolgt in der Regel einmalig, manchmal nacheinander in unterschiedliche Bereiche, aber nicht oft. Falk B. schrieb: > Scheitert das korrekte Rücklesen der neu > geschriebenen Daten, aka Verify? ja. Wenn z.B. eine Identifikations-Nummer mit Hilfe der VEE-Software eingetragen wurde, dann befindet die sich in letzter Zeit nicht sicher auf dem EEPROM. An der Hard- und Software hat es meines Wissens nach keine Änderungen gegeben. > … Wenn man einen EEPROM beschreibt, wird der erst gelöscht und dann > neu beschrieben. guter Hinweis. Vielleicht wurde im VEE-Programm auf das Löschen vor dem Beschreiben verzichtet? >> Wie sind die 24LC32A von Microchip im Auslieferungszustand beschrieben? > Vollkommen egal. bei dem Problem eventuell nicht. Dann muß sich also jemand mit dem VEE-Programm befassen - das will zwar niemand, aber da kommen wir wohl nicht drumrum.
Harald K. schrieb: > Hardwareproblem (Störungen aus Signal- oder > Versorgungsspannungsleitungen) oder Softwareproblem. EMV-Störungen kann ich nicht ausschließen. Mal sehen, ob ich da was finden kann.
Matthias K. schrieb: > Wenn z.B. eine Identifikations-Nummer mit Hilfe der VEE-Software > eingetragen wurde, dann befindet die sich in letzter Zeit nicht sicher > auf dem EEPROM. An der Hard- und Software hat es meines Wissens nach > keine Änderungen gegeben. > >> … Wenn man einen EEPROM beschreibt, wird der erst gelöscht und dann >> neu beschrieben. > guter Hinweis. Vielleicht wurde im VEE-Programm auf das Löschen vor dem > Beschreiben verzichtet? Kann es nicht, denn das macht der EEPROM allein. Aber man kann beim Page Write Mode Unsinn machen, wenn man glaubt, über die Grenze einer Page schreiben zu können. Aber das wäre ein reproduzierbarer Fehler, der nicht erst jetzt auftaucht. >>> Wie sind die 24LC32A von Microchip im Auslieferungszustand beschrieben? > >> Vollkommen egal. > bei dem Problem eventuell nicht. Doch. Denn euer Programm muss ja Datensätze ggf. mit CRC reinschreiben und deren Korrektheit prüfen. Was vorher drin stand, ist vollkommen egal. Wenn das Programm aber ne Macke hat und den "Resetzustand" von einigen Daten aufbaut, ist das natürlich ein Fehler. > Dann muß sich also jemand mit dem VEE-Programm befassen - das will zwar > niemand, aber da kommen wir wohl nicht drumrum.
Matthias K. schrieb: > Harald K. schrieb: >> Hardwareproblem (Störungen aus Signal- oder >> Versorgungsspannungsleitungen) oder Softwareproblem. > > EMV-Störungen kann ich nicht ausschließen. Mal sehen, ob ich da was > finden kann. Ich hatte vor Jahren mal ein Problem mit EEPROMs in einem gemischten 3,3V/5V System. Der Fehler lag aber nicht im EEPROM selber, sondern im Pegelwandler mit galvanischer Trennung. Bei Temperaturen nahe 0° und darunter fing er an zu spinnen.
Jens M. schrieb: > Evtl. ist auch der Hardwaredesigner ein Idiot, wenn im Buch steht das > 100 Millionen Schreibzugriffe zu erwarten sind hat er den falschen Chip > verbaut. > Oder der BWLer, der dem Einkauf gesagt hat das Broker durchaus günstige > Teile liefern. naja, um häufige Schreibzugriffe geht es nicht. Wir haben schonmal Leiterplatten erhalten, die mit gefälschten ICs bestückt waren. Die Aufdrucke auf den ICs waren in Ordnung, nur der Ruhestrom war deutlich zu hoch - tückisch, wenn die Versorgung aus einer kleinen Batterie kommt. Ich vermute, daß da der billigere Typ mit höherem Ruhestrom umgelabelt worden ist. Das wird sich für den Anbieter gelohnt haben. Den Schaden hatte die Bestückungs-Firma. Doch das dürfte hier nicht das Problem sein.
Matthias K. schrieb: > EMV-Störungen Elektromagnetische Verträglichkeit ist ein erstrebenswerter Zustand. Ein Störungsvariante gibt es davon nicht. Das wäre elektromagnetische Unverträglichkeit und dann kann es entweder am Störer oder an einer unzureichend gegen Störungen geschützten Baugruppe liegen. Was für Störungen sollen das sein, die erst nach längerer Nutzungszeit auftreten?
Rainer W. schrieb: > Matthias K. schrieb: >> EMV-Störungen > > Elektromagnetische Verträglichkeit ist ein erstrebenswerter Zustand. > Ein Störungsvariante gibt es davon nicht. Das wäre elektromagnetische > Unverträglichkeit und dann kann es entweder am Störer oder an einer > unzureichend gegen Störungen geschützten Baugruppe liegen. Störungen die die elektromagnetischen Verträglichkeit betreffen. > Was für Störungen sollen das sein, die erst nach längerer Nutzungszeit > auftreten? Vielleicht gibt es jetzt in der Umgebung eine Störungsquelle, die auf unzureichend geschützte Hardware wirkt.
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.