EEPROM read & write errors on the programmer

Before a module can be diagnosed or coded it has to be read — and then, often, written. Both steps fail in characteristic ways. This page maps each failure to its cause and to the setting or procedure that fixes it, from the module not being seen at all to a write that "succeeds" and quietly disappears.

Module not detected

Check	Why
Seating and cradle	the module must bottom out in the connector; use the adapter for its form factor — an SFP in a QSFP cradle will not be seen
Power-up time	modules need up to ~2 s (SFP) or longer (CMIS) after insertion before the two-wire bus answers
Module present signal	MOD_ABS / ModPrsL must assert; a bent pin or a module without the signal looks absent
Low-power state (CMIS)	identity is readable in LowPwr, but some hosts/programmers expect Ready for full access
Bus speed	start at 100 kHz or lower; some modules NACK at 400 kHz
Dead module	no DDM, no identity at any speed — confirm on a second board before condemning it

Reads return FFh, 00h or garbage

Symptom	Cause	Fix
All FFh	I²C NACK — no device at that address, or page not present	check the address (A0h identity vs A2h diagnostics on SFP; single A0h with paging on QSFP/CMIS)
All 00h	module not powered / held in reset; or genuinely blank EEPROM	check power to the cradle, module present; blank modules exist (uncoded stock)
Right length, wrong content	reading a different page than intended	write the page-select byte (127) and re-read; on CMIS also bank select (126)
Garbled / shifted bytes	bus too fast, long cable, contention with a host	drop to ≤ 100 kHz; use short leads; read on the bench, not in a live switch
A2h reads fail, A0h fine	module without diagnostics, or protected diagnostics block	check A0h byte 92 bit 6 (DDM implemented); some write-protected types answer A0h only
Values change between reads	live monitors — normal; or data not ready	DDM bytes are supposed to change; check the data-ready bit before trusting a snapshot

Write fails outright

WRITE FAIL, NACK on data, or the byte reads back unchanged:

Cause	How to recognise	What to do
Password required (firmware controller)	write refused until the correct value is placed at the password address (SFP A2h 0x7B–0x7E, QSFP 123–126, CMIS 122–125)	enter the module's password in Protected memory & passwords; known vendor passwords are applied from the database
Hardware write protect	read-only regardless of password, survives power cycles	the WP pin must be driven by the programmer board — software alone cannot; see Write-protection types
Timing	intermittent failures, partial pages written	slow the clock (~1 kHz is often needed for reliable EEPROM writes), respect write-cycle time (5–10 ms) between bytes/pages, add inter-block delays
Read-only region	specific bytes never change (checksums, thresholds on some parts, vendor area)	the EEPROM has a protected region by design; write only the fields the module allows
Wrong state	CMIS modules may require LowPwr, or a data-path deactivated, before accepting writes	put the module in the required state first
Page not selected	you wrote the right offset on the wrong page	set byte 127 (and 126) before the write and verify by reading back the page-select byte

Write "succeeds" but does not stick

Reverts after power cycle — the module stores writes in temporary memory and needs the vendor's save command; without it the old image returns. Handled by a programming script (Write-protection type 4).
Reverts immediately — the microcontroller mirrors the EEPROM from its own store and overwrites your bytes; requires the manufacturer's algorithm (type 5).
Some bytes stick, others not — a partially protected map; write field by field and verify each.

Host rejects the module after a successful write

Cause	Fix
Checksums stale — CC_BASE (byte 63), CC_EXT (95), CC_DMI (A2h 95), QSFP 191/223	recalculate; CodingBox does this automatically on write (Memory map)
Identity now inconsistent — e.g. vendor changed but compliance codes or wavelength imply different hardware	keep identity consistent with the real optics (Speed & rate, Physical mismatches)
Wrote to the wrong module type's layout	an XFP written as an SFP, or a QSFP page confusion — restore from backup

Module dead after a write

Writing garbage over calibration constants, thresholds or the vendor-specific area (where some controllers keep their configuration) can brick a module. Recovery path: restore the backup CodingBox took before the write from the code database, then write only the intended fields.

Golden rules

Read and save first — every write should be preceded by a full read that lands in the database.
Identify the protection type before the first write attempt (Write-protection types).
Go slow — clock and inter-byte timing solve most "random" failures.
Write only what you mean — fields, not whole pages, unless restoring an image.
Verify by re-reading after a power cycle.

In CodingBox

CodingBox reads modules with the correct address and paging per form factor, shows raw and decoded bytes in the EEPROM editor, recalculates checksums on write, stores a backup automatically, and supports password entry and programming scripts for protected and save-command modules (Writing a module). If a board-level fault is suspected, see the product Troubleshooting.

The bus mechanics behind these failures — addresses, page select, write cycle time, clock stretching: Two-wire interface.