Lese- und Schreibfehler der EEPROM am Programmiergerät

Bevor ein Modul diagnostiziert oder kodiert werden kann, muss es gelesen werden, und danach oft auch beschrieben. Beide Schritte scheitern auf charakteristische Weise. Diese Seite ordnet jeden Fehler seiner Ursache und der Einstellung oder dem Verfahren zu, das ihn behebt, vom Modul, das überhaupt nicht erkannt wird, bis zum Schreibvorgang, der „gelingt“ und still wieder verschwindet.

Modul nicht erkannt

Prüfung	Warum
Sitz und Aufnahme	das Modul muss im Steckverbinder vollständig einrasten; den Adapter für den jeweiligen Formfaktor verwenden – ein SFP in einer QSFP-Aufnahme wird nicht erkannt
Hochlaufzeit	Module brauchen nach dem Einsetzen bis zu ~2 s (SFP) oder länger (CMIS), bevor der Zweidraht-Bus antwortet
Modul-Präsenzsignal	MOD_ABS/ModPrsL muss aktiv werden; ein verbogener Pin oder ein Modul ohne dieses Signal wirkt wie nicht vorhanden
Low-Power-Zustand (CMIS)	die Identität ist in LowPwr lesbar, aber manche Hosts/Programmiergeräte erwarten für vollen Zugriff Ready
Busgeschwindigkeit	mit 100 kHz oder niedriger beginnen; manche Module quittieren bei 400 kHz mit NACK
totes Modul	kein DDM, keine Identität bei irgendeiner Geschwindigkeit – vor dem endgültigen Urteil an einer zweiten Platine bestätigen

Lesevorgänge liefern FFh, 00h oder Datenmüll

Symptom	Ursache	Abhilfe
Durchgehend FFh	I²C-NACK: kein Gerät an dieser Adresse, oder Seite nicht vorhanden	die Adresse prüfen (A0h-Identität vs. A2h-Diagnose bei SFP; einzelnes A0h mit Paging bei QSFP/CMIS)
Durchgehend 00h	Modul nicht mit Strom versorgt/im Reset gehalten; oder tatsächlich leeres EEPROM	Stromversorgung der Aufnahme prüfen, Modul vorhanden; leere Module existieren (unkodierte Ware)
richtige Länge, falscher Inhalt	eine andere als die beabsichtigte Seite wird gelesen	das Page-Select-Byte (127) schreiben und erneut lesen; bei CMIS zusätzlich Bank-Select (126)
verstümmelte/verschobene Bytes	Bus zu schnell, langes Kabel, Konflikt mit einem Host	auf ≤ 100 kHz heruntergehen; kurze Leitungen verwenden; auf der Werkbank lesen, nicht im laufenden Switch
A2h-Lesevorgänge schlagen fehl, A0h in Ordnung	Modul ohne Diagnose, oder geschützter Diagnoseblock	A0h Byte 92 Bit 6 prüfen (DDM implementiert); manche schreibgeschützten Typen antworten nur auf A0h
Werte ändern sich zwischen Lesevorgängen	Live-Monitore – normal; oder data not ready	DDM-Bytes sollen sich ändern; das Data-Ready-Bit prüfen, bevor eine Momentaufnahme als verlässlich gilt

Schreibvorgang schlägt vollständig fehl

WRITE FAIL, NACK bei den Daten, oder das Byte liest sich beim erneuten Lesen unverändert zurück:

Ursache	Erkennungsmerkmal	Maßnahme
Passwort erforderlich (Firmware-Controller)	Schreiben wird verweigert, bis der richtige Wert an der Passwortadresse steht (SFP A2h 0x7B–0x7E, QSFP 123–126, CMIS 122–125)	das Passwort des Moduls in Geschützter Speicher und Passwörter eingeben; bekannte Herstellerpasswörter werden aus der Datenbank angewendet
Hardware-Schreibschutz	schreibgeschützt unabhängig vom Passwort, übersteht Stromzyklen	der WP-Pin muss von der Programmiergerät-Platine angesteuert werden – Software allein kann das nicht; siehe Schreibschutzarten
Timing	sporadische Fehler, teilweise beschriebene Seiten	den Takt verlangsamen (für zuverlässige EEPROM-Schreibvorgänge sind oft ~1 kHz nötig), die Schreibzykluszeit (5–10 ms) zwischen Bytes/Seiten einhalten, Verzögerungen zwischen Blöcken einfügen
Reiner Lesebereich	bestimmte Bytes ändern sich nie (Prüfsummen, bei manchen Bauteilen Schwellwerte, Herstellerbereich)	das EEPROM hat konstruktionsbedingt einen geschützten Bereich; nur die vom Modul erlaubten Felder beschreiben
Falscher Zustand	CMIS-Module verlangen vor dem Beschreiben mitunter LowPwr oder einen deaktivierten Datenpfad	das Modul zunächst in den erforderlichen Zustand versetzen
Seite nicht ausgewählt	der richtige Offset wurde auf der falschen Seite beschrieben	vor dem Schreiben Byte 127 (und 126) setzen und durch Rücklesen des Page-Select-Bytes prüfen

Schreibvorgang „gelingt“, bleibt aber nicht erhalten

Setzt sich nach einem Stromzyklus zurück – das Modul speichert Schreibvorgänge im temporären Speicher und benötigt den herstellerspezifischen Save-Befehl; ohne ihn kehrt das alte Abbild zurück. Wird durch ein Programmierskript erledigt (Schreibschutzart 4).
Setzt sich sofort zurück – der Mikrocontroller spiegelt das EEPROM aus seinem eigenen Speicher und überschreibt die eigenen Bytes; erfordert den Algorithmus des Herstellers (Art 5).
Manche Bytes bleiben, andere nicht – eine teilweise geschützte Belegung; feldweise schreiben und jedes einzeln überprüfen.

Host lehnt das Modul nach erfolgreichem Schreiben ab

Ursache	Abhilfe
Prüfsummen veraltet: CC_BASE (Byte 63), CC_EXT (95), CC_DMI (A2h 95), QSFP 191/223	neu berechnen; CodingBox macht das beim Schreiben automatisch (Speicherbelegung)
Identität jetzt widersprüchlich, z. B. Hersteller geändert, aber Compliance-Codes oder Wellenlänge deuten auf andere Hardware	die Identität konsistent mit der realen Optik halten (Geschwindigkeit und Rate, Physikalische Fehlanpassungen)
in die Belegung des falschen Modultyps geschrieben	ein XFP wurde wie ein SFP beschrieben, oder eine QSFP-Seitenverwechslung – aus der Sicherung wiederherstellen

Modul nach einem Schreibvorgang tot

Werden Kalibrierkonstanten, Schwellwerte oder der herstellerspezifische Bereich (wo manche Controller ihre Konfiguration ablegen) mit Datenmüll überschrieben, kann ein Modul unbrauchbar werden. Weg zur Wiederherstellung: die Sicherung zurückspielen, die CodingBox vor dem Schreiben in der code database angelegt hat, und dann nur die beabsichtigten Felder schreiben.

Goldene Regeln

Erst lesen und sichern – jedem Schreibvorgang sollte ein vollständiger Lesevorgang vorausgehen, der in der Datenbank landet.
Die Schutzart bestimmen, bevor der erste Schreibversuch erfolgt (Schreibschutzarten).
Langsam vorgehen – Takt und Timing zwischen den Bytes lösen die meisten „zufälligen“ Fehler.
Nur das Beabsichtigte schreiben – Felder, keine ganzen Seiten, außer bei der Wiederherstellung eines Abbilds.
Durch erneutes Lesen nach einem Stromzyklus verifizieren.

In CodingBox

CodingBox liest Module mit der richtigen Adresse und dem richtigen Paging je Formfaktor, zeigt Roh- und dekodierte Bytes im EEPROM editor, berechnet Prüfsummen beim Schreiben neu, legt automatisch eine Sicherung an und unterstützt Passworteingabe sowie Programmierskripte für geschützte Module und solche mit Save-Befehl (Ein Modul beschreiben). Wird ein Fehler auf Platinenebene vermutet, siehe die Produkt- Fehlerbehebung.

Die Busmechanik hinter diesen Fehlern: Adressen, Page-Select, Schreibzykluszeit, Clock Stretching in Zweidraht-Schnittstelle.

Warum ein Modul so antwortet, wie es antwortet: MCU-emulierter Speicher, Boot-Fenster, Clock Stretching, geschützte Bereiche in Controller und Firmware.

Wenn Sie in diesem Artikel eine Ungenauigkeit oder einen Fehler finden, markieren Sie die betreffende Stelle und drücken Sie Ctrl+Enter, um .