Erreurs de lecture et d’écriture EEPROM sur le programmateur

Avant de pouvoir diagnostiquer ou coder un module, il faut le lire — puis, souvent, l’écrire. Les deux étapes échouent de façons caractéristiques. Cette page relie chaque échec à sa cause et au réglage ou à la procédure qui le corrige, depuis le module qui n’est pas vu du tout jusqu’à une écriture qui « réussit » et disparaît discrètement.

Module non détecté

Vérification	Pourquoi
Insertion et berceau	le module doit aller jusqu’au fond du connecteur ; utilisez l’adaptateur correspondant à son facteur de forme — un SFP dans un berceau QSFP ne sera pas vu
Temps de mise sous tension	les modules ont besoin de jusqu’à ~2 s (SFP) ou plus (CMIS) après insertion avant que le bus à deux fils ne réponde
Signal de présence du module	MOD_ABS / ModPrsL doit s’activer ; une broche pliée ou un module sans ce signal paraît absent
État basse consommation (CMIS)	l’identité est lisible en LowPwr, mais certains hôtes/programmateurs attendent l’état Ready pour un accès complet
Vitesse de bus	démarrez à 100 kHz ou moins ; certains modules répondent NACK à 400 kHz
Module mort	pas de DDM, pas d’identité à aucune vitesse — confirmez sur une deuxième carte avant de le condamner

Les lectures renvoient FFh, 00h ou des données aberrantes

Symptôme	Cause	Correction
Tout en FFh	NACK I²C — aucun périphérique à cette adresse, ou page absente	vérifiez l’adresse (identité A0h vs diagnostic A2h sur SFP ; A0h unique avec pagination sur QSFP/CMIS)
Tout en 00h	module non alimenté / maintenu en reset ; ou EEPROM réellement vierge	vérifiez l’alimentation du berceau, la présence du module ; des modules vierges existent (stock non codé)
Bonne longueur, contenu erroné	lecture d’une page différente de celle prévue	écrivez l’octet de sélection de page (127) et relisez ; sur CMIS, aussi la sélection de banque (126)
Octets brouillés / décalés	bus trop rapide, câble long, contention avec un hôte	descendez à ≤ 100 kHz ; utilisez des fils courts ; lisez sur banc, pas dans un commutateur en service
Lectures A2h en échec, A0h correct	module sans diagnostic, ou bloc de diagnostic protégé	vérifiez l’octet 92 bit 6 de A0h (DDM implémenté) ; certains types protégés en écriture ne répondent qu’en A0h
Les valeurs changent entre deux lectures	mesures en direct — normal ; ou data not ready	les octets DDM sont censés changer ; vérifiez le bit data-ready avant de faire confiance à un instantané

L’écriture échoue franchement

WRITE FAIL, NACK sur les données, ou l’octet relu reste inchangé :

Cause	Comment le reconnaître	Que faire
Mot de passe requis (contrôleur firmware)	écriture refusée tant que la bonne valeur n’est pas placée à l’adresse du mot de passe (SFP A2h 0x7B–0x7E, QSFP 123–126, CMIS 122–125)	saisissez le mot de passe du module dans Mémoire protégée et mots de passe ; les mots de passe constructeur connus sont appliqués depuis la base
Protection en écriture matérielle	lecture seule quel que soit le mot de passe, survit aux cycles d’alimentation	la broche WP doit être pilotée par la carte du programmateur — le logiciel seul ne peut pas ; voir Types de protection en écriture
Timing	échecs intermittents, pages partiellement écrites	ralentissez l’horloge (~1 kHz est souvent nécessaire pour des écritures EEPROM fiables), respectez le temps de cycle d’écriture (5–10 ms) entre octets/pages, ajoutez des délais entre blocs
Zone en lecture seule	certains octets ne changent jamais (sommes de contrôle, seuils sur certains modèles, zone constructeur)	l’EEPROM a une région protégée par conception ; n’écrivez que les champs que le module autorise
Mauvais état	les modules CMIS peuvent exiger LowPwr, ou un chemin de données désactivé, avant d’accepter les écritures	mettez d’abord le module dans l’état requis
Page non sélectionnée	vous avez écrit le bon décalage sur la mauvaise page	réglez l’octet 127 (et 126) avant l’écriture et vérifiez en relisant l’octet de sélection de page

L’écriture « réussit » mais ne tient pas

Revient en arrière après un cycle d’alimentation — le module stocke les écritures en mémoire temporaire et a besoin de la commande de sauvegarde du constructeur ; sans elle, l’ancienne image revient. Géré par un script de programmation (Type de protection en écriture 4).
Revient en arrière immédiatement — le microcontrôleur reflète l’EEPROM depuis son propre stockage et écrase vos octets ; nécessite l’algorithme du fabricant (type 5).
Certains octets tiennent, d’autres pas — une cartographie partiellement protégée ; écrivez champ par champ et vérifiez chacun.

L’hôte rejette le module après une écriture réussie

Cause	Correction
Sommes de contrôle obsolètes — CC_BASE (octet 63), CC_EXT (95), CC_DMI (A2h 95), QSFP 191/223	recalculez-les ; CodingBox le fait automatiquement à l’écriture (carte mémoire)
Identité devenue incohérente — par ex. constructeur changé mais les codes de conformité ou la longueur d’onde impliquent un matériel différent	gardez l’identité cohérente avec l’optique réelle (Vitesse et débit, Incompatibilités physiques)
Écriture dans la disposition du mauvais type de module	un XFP écrit comme un SFP, ou une confusion de page QSFP — restaurez depuis la sauvegarde

Module mort après une écriture

Écrire n’importe quoi par-dessus les constantes d’étalonnage, les seuils ou la zone spécifique au constructeur (où certains contrôleurs conservent leur configuration) peut « briquer » un module. Chemin de récupération : restaurez la sauvegarde que CodingBox a prise avant l’écriture depuis la code database, puis n’écrivez que les champs voulus.

Règles d’or

Lisez et sauvegardez d’abord — chaque écriture doit être précédée d’une lecture complète qui atterrit dans la base.
Identifiez le type de protection avant la première tentative d’écriture (Types de protection en écriture).
Allez lentement — l’horloge et le timing entre octets résolvent la plupart des échecs « aléatoires ».
N’écrivez que ce que vous voulez — des champs, pas des pages entières, sauf en cas de restauration d’image.
Vérifiez en relisant après un cycle d’alimentation.

Dans CodingBox

CodingBox lit les modules avec la bonne adresse et la bonne pagination selon le facteur de forme, affiche les octets bruts et décodés dans l’EEPROM editor, recalcule les sommes de contrôle à l’écriture, enregistre une sauvegarde automatiquement, et prend en charge la saisie de mot de passe et les scripts de programmation pour les modules protégés et à commande de sauvegarde (Écrire un module). En cas de suspicion de défaut au niveau de la carte, consultez le Dépannage du produit.

La mécanique du bus derrière ces échecs — adresses, sélection de page, temps de cycle d’écriture, clock stretching : Interface à deux fils.

Pourquoi un module répond de cette façon — mémoire émulée par MCU, fenêtre de démarrage, clock stretching, régions protégées : Contrôleur et firmware.

Si vous trouvez une inexactitude ou une erreur dans cet article, sélectionnez le passage concerné et appuyez sur Ctrl+Enter pour .