The controller and its firmware: DDM, APC, memory, protection

Every managed transceiver has a small computer inside. The microcontroller (MCU) measures, regulates, reports and — from the programmer's point of view most importantly — is the memory you read and write. Whether a module has a plain EEPROM or an MCU pretending to be one decides how it can be coded, why some writes vanish after a power cycle and why passwords exist at all. This page describes what the controller does and how its design shows up on the bench.

What the MCU does

Task	Details	Visible as
Measurement	samples temperature (thermistor or on-chip sensor), Vcc, laser bias, monitor-PD current (Tx) and receiver photocurrent (Rx) through a 10–12-bit ADC several times per second; applies factory calibration	DDM values — Parameters
APC — automatic power control	compares monitor-PD current with the factory target and adjusts the driver's bias DAC	constant Tx power, rising bias — Tx bias & ageing
Temperature compensation	look-up tables adjust modulation current and, on PAM4, DSP settings across temperature	stable extinction ratio
TEC control	PID loop holding laser temperature on cooled modules; wavelength-locker feedback on DWDM	laser temperature, TEC current monitors
Thresholds and flags	compares every monitor with the alarm/warning thresholds, sets latched flags, drives IntL	Thresholds & alarms
Low-speed pins	reads TX_DISABLE, RS0/RS1, LPMode, ResetL; drives TX_FAULT, RX_LOS (or gates the hardware signals)	pin behaviour
Two-wire slave	answers at A0h/A2h (SFP) or A0h with pages/banks (QSFP, CMIS)	the memory map — Two-wire interface
State machines	CMIS module and data-path states; application selection; squelch	CMIS
Protection and vendor functions	passwords, write-protect regions, save commands, vendor unlock, authentication signatures	Write-protection types
CDB / firmware update	on CMIS modules, receives and flashes new firmware images	firmware version bytes

Typical parts: 8-bit MCUs (8051-class) with a few kB of flash in low-cost SFP/SFP+; 32-bit Cortex-M class in 100G+ and CMIS modules; some vendors use a dedicated transceiver-controller ASIC that integrates ADCs, DACs and the two-wire slave.

Two ways to build the memory

Design	How the map is stored	Consequences for programming
Discrete EEPROM (e.g. AT24C02-class) for A0h, MCU for A2h	A0h identity is a real serial EEPROM the host and programmer talk to directly; the MCU handles diagnostics only	A0h writes are plain EEPROM writes — respect t_WR and page size; a hardware WP pin may block them (Write-protection types 1–3)
MCU-emulated map	the MCU answers every two-wire request from RAM and mirrors changes to its internal flash/EEPROM — or not	writes go where the firmware decides: accepted, ignored, password-gated, stored only after a save command, or overwritten from the firmware's own copy on the next boot (types 4–5)
Hybrid	EEPROM for the vendor block, MCU for pages and passwords	mixed rules per byte range

An emulated map explains most bench mysteries: FFh from a page the firmware does not implement, writes that "succeed" and revert, bytes that are read-only in one range and free in the next, clock stretching while the MCU is busy sampling (EEPROM read & write errors).

Boot and the t_init window

On power-up the MCU loads calibration and identity from its non-volatile store, starts the ADC, runs the APC to its target and only then enables the two-wire slave and clears data-not-ready. That is the 300 ms (SFP) to 2 s (QSFP/CMIS) the specifications allow before a host may expect answers, and the reason a read immediately after insertion returns garbage (What the host does).

Calibration lives here

The raw ADC counts mean nothing without the constants the factory measured on a test station: monitor-PD current vs actual launch power, receiver photocurrent vs input power at the module's wavelength, thermistor curve, bias DAC scale. On internally calibrated modules the firmware applies them and reports physical units; on externally calibrated modules the constants are written to A2h 56–91 for the host to apply (Calibration). Overwriting the vendor area where some firmwares keep these constants produces absurd DDM or a dead APC loop — the classic way a careless write "bricks" a module (Manufacturing & testing).

How protection is implemented

Mechanism	Implementation	Bench view
Password	firmware compares the 4 bytes written to the password area (SFP A2h 123–126, QSFP 123–126, CMIS 122–125) with a stored value; unlocks writes for the session	`WRITE FAIL` until the right value is entered — Passwords
Write-protect regions	firmware ignores writes to ranges it considers read-only (checksums, thresholds, calibration, vendor area)	bytes read back unchanged, no error
Hardware WP pin on a discrete EEPROM	the pin is tied high inside the module or driven by the MCU	needs the programmer board to drive it
Save command	writes land in RAM; a vendor-specific sequence commits them to flash	reverts after power cycle unless the sequence is sent
Firmware mirror	on boot the firmware rewrites the map from its own image	changes vanish at every power cycle — only the vendor's tool can change the image
Authentication	the firmware computes a signature (hash of serial, vendor data and a secret) into vendor bytes; the host verifies	identity edits pass checksums yet the host still rejects — Vendor lock

How each type is recognised and programmed: Write-protection types, EEPROM recoding.

Firmware updates

CMIS modules can receive firmware over the two-wire bus through CDB commands (start download, write blocks, complete, run, commit), often with two image banks so a failed update falls back. SFF-8472/8636 modules have no standard mechanism; vendors use proprietary sequences through vendor bytes. Firmware fixes are how vendors resolve CMIS interoperability problems (CMIS issues), and firmware version bytes (CMIS lower page 39–40, page 01h 128–129) are worth recording with the identity.

Failure modes of the controller

Symptom	Likely cause
Module invisible on the bus, optics otherwise fine	MCU not booting: corrupted firmware, brown-out, damaged crystal
DDM values frozen or absurd	ADC or calibration corruption; firmware hang
Tx power drifting although APC should hold it	monitor-PD or ADC fault, APC disabled
Random NACKs, slow reads	MCU overloaded (sampling), clock-stretch limits exceeded by a fast programmer
Works, but every write reverts	firmware mirror by design — not a fault
Module dead after a write	firmware configuration or calibration area overwritten

In CodingBox

CodingBox treats the module as the firmware presents it: it detects the map type, applies known passwords and programming scripts for save-command and mirrored designs, recalculates checksums, keeps a backup before every write and lets you restore it from the code database if a controller reacts badly. The EEPROM editor marks ranges that the specification defines as read-only or vendor-specific so you know when you are writing into the firmware's private territory.