Il controller e il suo firmware: DDM, APC, memoria, protezione
Ogni ricetrasmettitore gestito ha al suo interno un piccolo computer. Il microcontrollore (MCU) misura, regola, riporta e — dal punto di vista di chi programma, la cosa più importante — è la memoria che leggi e scrivi. Il fatto che un modulo abbia una EEPROM vera e propria o un MCU che finge di esserlo decide come può essere programmato, perché alcune scritture svaniscono dopo un ciclo di alimentazione e perché esistono le password. Questa pagina descrive cosa fa il controller e come il suo design si manifesta sul banco.
Cosa fa l’MCU
| Attività | Dettagli | Visibile come |
|---|---|---|
| Misurazione | campiona temperatura (termistore o sensore on-chip), Vcc, bias del laser, corrente del PD di monitor (Tx) e fotocorrente del ricevitore (Rx) tramite un ADC a 10–12 bit più volte al secondo; applica la calibrazione di fabbrica | valori DDM — Parametri |
| APC — controllo automatico di potenza | confronta la corrente del PD di monitor con il target di fabbrica e regola il DAC di bias del driver | potenza Tx costante, bias in aumento — Bias Tx e invecchiamento |
| Compensazione della temperatura | tabelle di lookup regolano la corrente di modulazione e, su PAM4, le impostazioni del DSP al variare della temperatura | rapporto di estinzione stabile |
| Controllo del TEC | loop PID che mantiene la temperatura del laser sui moduli raffreddati; retroazione del wavelength locker su DWDM | monitor di temperatura del laser e di corrente TEC |
| Soglie e flag | confronta ogni monitor con le soglie di allarme/avviso, imposta flag mantenuti (latch), pilota IntL | Soglie e allarmi |
| Pin a bassa velocità | legge TX_DISABLE, RS0/RS1, LPMode, ResetL; pilota TX_FAULT, RX_LOS (oppure controlla i segnali hardware) | comportamento dei pin |
| Slave a due fili | risponde su A0h/A2h (SFP) o su A0h con pagine/banchi (QSFP, CMIS) | la mappa di memoria — Interfaccia a due fili |
| Macchine a stati | stati del modulo e del data-path CMIS; selezione dell’applicazione; squelch | CMIS |
| Protezione e funzioni vendor | password, regioni protette in scrittura, comandi di salvataggio, sblocco vendor, firme di autenticazione | Tipi di protezione in scrittura |
| CDB / aggiornamento firmware | sui moduli CMIS, riceve e scrive nuove immagini firmware | byte di versione firmware |
Componenti tipici: MCU a 8 bit (classe 8051) con qualche kB di flash negli SFP/SFP+ low-cost; classe Cortex-M a 32 bit nei moduli 100G+ e CMIS; alcuni vendor usano un ASIC controller dedicato per ricetrasmettitori che integra ADC, DAC e lo slave a due fili.
Due modi di costruire la memoria
| Design | Come viene memorizzata la mappa | Conseguenze per la programmazione |
|---|---|---|
| EEPROM discreta (es. classe AT24C02) per A0h, MCU per A2h | l’identità A0h è una vera EEPROM seriale con cui host e programmatore parlano direttamente; l’MCU gestisce solo la diagnostica | le scritture A0h sono normali scritture EEPROM — rispetta t_WR e la dimensione di pagina; un pin WP hardware può bloccarle (Tipi di protezione in scrittura 1–3) |
| Mappa emulata dall’MCU | l’MCU risponde a ogni richiesta a due fili dalla RAM e specchia le modifiche sulla sua flash/EEPROM interna — oppure no | le scritture vanno dove decide il firmware: accettate, ignorate, protette da password, memorizzate solo dopo un comando di salvataggio, oppure sovrascritte dalla copia del firmware stesso al boot successivo (tipi 4–5) |
| Ibrido | EEPROM per il blocco vendor, MCU per pagine e password | regole miste per intervallo di byte |
Una mappa emulata spiega la maggior parte dei misteri da banco: FFh da una pagina che il firmware non implementa, scritture che «riescono» e poi si annullano, byte che sono di sola lettura in un intervallo e liberi in quello successivo, clock stretching mentre l’MCU è occupato a campionare (Errori di lettura e scrittura EEPROM).
Boot e la finestra t_init
All’accensione l’MCU carica calibrazione e identità dalla sua memoria non volatile, avvia l’ADC, porta l’APC al suo target e solo allora abilita lo slave a due fili e cancella data-not-ready. Questo è l’intervallo da 300 ms (SFP) a 2 s (QSFP/CMIS) che le specifiche concedono prima che un host possa aspettarsi risposte, ed è il motivo per cui una lettura subito dopo l’inserimento restituisce dati privi di senso (Cosa fa l’host).
La calibrazione vive qui
I conteggi ADC grezzi non significano nulla senza le costanti che la fabbrica ha misurato su una stazione di test: corrente del PD di monitor rispetto alla potenza di trasmissione reale, fotocorrente del ricevitore rispetto alla potenza in ingresso alla lunghezza d’onda del modulo, curva del termistore, scala del DAC di bias. Sui moduli a calibrazione interna il firmware le applica e riporta unità fisiche; sui moduli a calibrazione esterna le costanti sono scritte in A2h 56–91 perché l’host le applichi (Calibrazione). Sovrascrivere l’area vendor dove alcuni firmware conservano queste costanti produce una DDM assurda o un loop APC morto — il classico modo in cui una scrittura incauta «bricka» un modulo (Produzione e collaudo).
Come è implementata la protezione
| Meccanismo | Implementazione | Vista da banco |
|---|---|---|
| Password | il firmware confronta i 4 byte scritti nell’area password (SFP A2h 123–126, QSFP 123–126, CMIS 122–125) con un valore memorizzato; sblocca le scritture per la sessione | WRITE FAIL finché non viene inserito il valore corretto — Passwords |
| Regioni protette in scrittura | il firmware ignora le scritture verso intervalli che considera di sola lettura (checksum, soglie, calibrazione, area vendor) | i byte, riletti, risultano invariati, nessun errore |
| Pin WP hardware su una EEPROM discreta | il pin è tenuto alto dentro il modulo oppure pilotato dall’MCU | richiede che la scheda del programmatore lo piloti |
| Comando di salvataggio | le scritture finiscono in RAM; una sequenza specifica del vendor le rende permanenti in flash | si annulla dopo un ciclo di alimentazione a meno che la sequenza non venga inviata |
| Mirror del firmware | al boot il firmware riscrive la mappa dalla propria immagine | le modifiche svaniscono a ogni ciclo di alimentazione — solo lo strumento del vendor può cambiare l’immagine |
| Autenticazione | il firmware calcola una firma (hash di numero di serie, dati vendor e un segreto) nei byte vendor; l’host la verifica | le modifiche all’identità superano i checksum ma l’host le rifiuta comunque — Blocco del produttore |
Come si riconosce e si programma ciascun tipo: Tipi di protezione in scrittura, Riprogrammazione EEPROM.
Aggiornamenti firmware
I moduli CMIS possono ricevere firmware sul bus a due fili tramite comandi CDB (avvia download, scrivi blocchi, completa, esegui, commit), spesso con due banchi immagine così un aggiornamento fallito torna indietro. I moduli SFF-8472/8636 non hanno un meccanismo standard; i vendor usano sequenze proprietarie tramite byte vendor. Le correzioni firmware sono il modo in cui i vendor risolvono i problemi di interoperabilità CMIS (Problemi CMIS), e vale la pena registrare i byte di versione firmware (CMIS lower page 39–40, pagina 01h 128–129) insieme all’identità.
Modalità di guasto del controller
| Sintomo | Causa probabile |
|---|---|
| Modulo invisibile sul bus, ottica altrimenti a posto | l’MCU non fa il boot: firmware corrotto, brown-out, cristallo danneggiato |
| Valori DDM bloccati o assurdi | corruzione dell’ADC o della calibrazione; blocco del firmware |
| Potenza Tx che deriva anche se l’APC dovrebbe mantenerla | guasto del PD di monitor o dell’ADC, APC disabilitato |
| NACK casuali, letture lente | MCU sovraccarico (campionamento), limiti di clock stretching superati da un programmatore veloce |
| Funziona, ma ogni scrittura si annulla | mirror del firmware per progetto — non è un guasto |
| Modulo morto dopo una scrittura | area di configurazione firmware o di calibrazione sovrascritta |
In CodingBox
CodingBox tratta il modulo così come il firmware lo presenta: rileva il tipo di mappa, applica password note e script di programmazione per i design a comando di salvataggio e a mirror, ricalcola i checksum, mantiene un backup prima di ogni scrittura e ti permette di ripristinarlo dal code database se un controller reagisce male. L’EEPROM editor segna gli intervalli che la specifica definisce di sola lettura o specifici del vendor, così sai quando stai scrivendo nel territorio privato del firmware.