Le contrôleur et son firmware : DDM, APC, mémoire, protection

Chaque transceiver géré contient un petit ordinateur. Le microcontrôleur (MCU) mesure, régule, rend compte et — ce qui compte le plus du point de vue du programmeur — est la mémoire que vous lisez et écrivez. Qu’un module ait un simple EEPROM ou un MCU qui en imite un détermine comment il peut être codé, pourquoi certaines écritures disparaissent après un cycle d’alimentation, et pourquoi les mots de passe existent tout court. Cette page décrit ce que fait le contrôleur et comment sa conception se manifeste sur le banc.

Ce que fait le MCU

Tâche	Détails	Visible sous forme de
Mesure	échantillonne la température (thermistance ou capteur intégré), le Vcc, la polarisation du laser, le courant de la PD de surveillance (Tx) et le photocourant du récepteur (Rx) via un ADC 10–12 bits plusieurs fois par seconde ; applique l’étalonnage usine	valeurs DDM — Paramètres
APC — régulation automatique de puissance	compare le courant de la PD de surveillance à la cible usine et ajuste le DAC de polarisation du pilote	puissance Tx constante, polarisation en hausse — Polarisation Tx et vieillissement
Compensation en température	des tables de correspondance ajustent le courant de modulation et, en PAM4, les réglages DSP selon la température	taux d’extinction stable
Contrôle du TEC	boucle PID maintenant la température du laser sur les modules refroidis ; rétroaction du verrouilleur de longueur d’onde en DWDM	surveillance de la température du laser et du courant du TEC
Seuils et drapeaux	compare chaque mesure aux seuils d’alarme/d’avertissement, positionne des drapeaux verrouillés, pilote IntL	Seuils et alarmes
Broches basse vitesse	lit TX_DISABLE, RS0/RS1, LPMode, ResetL ; pilote TX_FAULT, RX_LOS (ou commande les signaux matériels)	comportement des broches
Esclave deux fils	répond en A0h/A2h (SFP) ou en A0h avec pages/banques (QSFP, CMIS)	la cartographie mémoire — Interface deux fils
Machines à états	états du module et du chemin de données CMIS ; sélection d’application ; squelch	CMIS
Protection et fonctions fournisseur	mots de passe, zones protégées en écriture, commandes de sauvegarde, déverrouillage fournisseur, signatures d’authentification	Types de protection en écriture
CDB / mise à jour du firmware	sur les modules CMIS, reçoit et flashe de nouvelles images de firmware	octets de version du firmware

Composants typiques : des MCU 8 bits (classe 8051) avec quelques ko de flash dans les SFP/SFP+ bon marché ; des MCU 32 bits classe Cortex-M dans les modules 100G+ et CMIS ; certains fournisseurs utilisent un ASIC contrôleur de transceiver dédié qui intègre les ADC, les DAC et l’esclave deux fils.

Deux façons de construire la mémoire

Conception	Stockage de la carte mémoire	Conséquences pour la programmation
EEPROM discret (par exemple classe AT24C02) pour A0h, MCU pour A2h	l’identité en A0h est un véritable EEPROM série avec lequel l’hôte et le programmateur dialoguent directement ; le MCU ne gère que le diagnostic	les écritures en A0h sont de simples écritures EEPROM — respectez t_WR et la taille de page ; une broche WP matérielle peut les bloquer (Types de protection en écriture 1 à 3)
Cartographie émulée par le MCU	le MCU répond à chaque requête deux fils depuis la RAM et reporte les changements dans sa flash/EEPROM interne — ou pas	les écritures vont là où le firmware décide : acceptées, ignorées, verrouillées par mot de passe, stockées seulement après une commande de sauvegarde, ou écrasées par la propre copie du firmware au prochain démarrage (types 4 et 5)
Hybride	EEPROM pour le bloc fournisseur, MCU pour les pages et les mots de passe	règles mixtes selon la plage d’octets

Une cartographie émulée explique la plupart des mystères observés sur le banc : du FFh renvoyé par une page que le firmware n’implémente pas, des écritures qui « réussissent » puis reviennent en arrière, des octets en lecture seule dans une plage et libres dans la suivante, un étirement d’horloge pendant que le MCU est occupé à échantillonner (Erreurs de lecture et d’écriture EEPROM).

Démarrage et la fenêtre t_init

À la mise sous tension, le MCU charge l’étalonnage et l’identité depuis sa mémoire non volatile, démarre l’ADC, exécute l’APC jusqu’à sa cible, et c’est seulement ensuite qu’il active l’esclave deux fils et efface data-not-ready. C’est le délai de 300 ms (SFP) à 2 s (QSFP/CMIS) que les spécifications autorisent avant qu’un hôte puisse attendre des réponses, et la raison pour laquelle une lecture immédiatement après l’insertion renvoie des données aberrantes (Ce que fait l’hôte).

L’étalonnage se trouve ici

Les valeurs brutes de l’ADC ne signifient rien sans les constantes mesurées en usine sur un banc de test : courant de la PD de surveillance en fonction de la puissance de lancement réelle, photocourant du récepteur en fonction de la puissance d’entrée à la longueur d’onde du module, courbe de la thermistance, échelle du DAC de polarisation. Sur les modules à étalonnage interne, le firmware les applique et indique des unités physiques ; sur les modules à étalonnage externe, les constantes sont écrites en A2h 56–91 pour que l’hôte les applique (Étalonnage). Écraser la zone fournisseur où certains firmwares conservent ces constantes produit un DDM absurde ou une boucle APC morte — la façon classique dont une écriture imprudente « brique » un module (Fabrication et test).

Comment la protection est implémentée

Mechanism	Implementation	Bench view
Mot de passe	le firmware compare les 4 octets écrits dans la zone de mot de passe (SFP A2h 123–126, QSFP 123–126, CMIS 122–125) à une valeur stockée ; déverrouille les écritures pour la session	`WRITE FAIL` jusqu’à ce que la bonne valeur soit saisie — Mots de passe
Zones protégées en écriture	le firmware ignore les écritures vers les plages qu’il considère en lecture seule (sommes de contrôle, seuils, étalonnage, zone fournisseur)	les octets relus restent inchangés, pas d’erreur
Broche WP matérielle sur un EEPROM discret	la broche est tirée au niveau haut à l’intérieur du module ou pilotée par le MCU	nécessite que la carte du programmateur la pilote
Commande de sauvegarde	les écritures atterrissent en RAM ; une séquence propre au fournisseur les valide en flash	revient en arrière après un cycle d’alimentation sauf si la séquence est envoyée
Miroir du firmware	au démarrage, le firmware réécrit la cartographie à partir de sa propre image	les changements disparaissent à chaque cycle d’alimentation — seul l’outil du fournisseur peut modifier l’image
Authentification	le firmware calcule une signature (hachage du numéro de série, des données fournisseur et d’un secret) dans les octets fournisseur ; l’hôte la vérifie	les modifications d’identité passent les sommes de contrôle mais l’hôte les rejette quand même — Verrouillage constructeur

Comment chaque type est reconnu et programmé : Types de protection en écriture, Recodage de l’EEPROM.

Mises à jour du firmware

Les modules CMIS peuvent recevoir du firmware sur le bus deux fils via des commandes CDB (démarrer le téléchargement, écrire les blocs, terminer, exécuter, valider), souvent avec deux banques d’image pour qu’une mise à jour ratée revienne en arrière. Les modules SFF-8472/8636 n’ont pas de mécanisme standard ; les fournisseurs utilisent des séquences propriétaires via les octets fournisseur. Les correctifs de firmware sont la façon dont les fournisseurs résolvent les problèmes d’interopérabilité CMIS (Problèmes CMIS), et les octets de version du firmware (CMIS page basse 39–40, page 01h 128–129) méritent d’être enregistrés avec l’identité.

Modes de défaillance du contrôleur

Symptôme	Cause probable
Module invisible sur le bus, optique par ailleurs correcte	MCU qui ne démarre pas : firmware corrompu, micro-coupure d’alimentation, quartz endommagé
Valeurs DDM figées ou absurdes	corruption de l’ADC ou de l’étalonnage ; blocage du firmware
Puissance Tx qui dérive alors que l’APC devrait la maintenir	défaut de la PD de surveillance ou de l’ADC, APC désactivée
NACK aléatoires, lectures lentes	MCU surchargé (échantillonnage), limites d’étirement d’horloge dépassées par un programmateur rapide
Fonctionne, mais chaque écriture revient en arrière	miroir du firmware voulu par conception — ce n’est pas un défaut
Module mort après une écriture	zone de configuration ou d’étalonnage du firmware écrasée

Dans CodingBox

CodingBox traite le module tel que le firmware le présente : il détecte le type de cartographie, applique les mots de passe connus et les scripts de programmation pour les conceptions à commande de sauvegarde et à miroir, recalcule les sommes de contrôle, conserve une sauvegarde avant chaque écriture et vous permet de la restaurer depuis la code database si un contrôleur réagit mal. L’EEPROM editor marque les plages que la spécification définit comme en lecture seule ou spécifiques au fournisseur, pour que vous sachiez quand vous écrivez dans le territoire privé du firmware.

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