CodingBox Documentation

Write-protection types & programming

Form factor tells you where a module's fields live. A second, independent axis decides whether you can change them: how the module protects its memory against writes. Manufacturers use five approaches, and each needs a different programming method. Recognising the type first saves hours of failed write attempts.

The five protection types

#TypeHow it is recognisedHow it is programmed
1UnprotectedAccepts writes immediatelyDirect write — but at a slow clock
2Hardware write-protect pinRead-only however you try; no password helpsControl the WP line during the write
3Password (firmware controller)WRITE FAIL until a password is enteredEnter the password at 0x7B first
4Temporary storage + save commandWrites "succeed" but revert after power cycleSend the vendor's save sequence
5CombinedNeeds a vendor-specific I/O sequence to unlockVendor programming algorithm (scripts)

1. Unprotected

The EEPROM has no write restriction. The practical catch is timing: reliable programming typically needs a two-wire clock around 1 kHz — about ten times slower than the normal read speed. At standard speed, writes fail intermittently and leave partially written pages. A related tell-tale: on some simple modules only A0h reads cleanly while A2h returns errors.

2. Hardware write-protect pin

The EEPROM's WP pin is tied to the supply through a resistor, so the chip powers up locked. Unlocking means pulling the WP line towards ground through a lower-impedance path while the write is in progress — something only a programmer board with control over that line can do. Software alone cannot get past this type: the module stays read-only through power cycles and password attempts.

3. Password-protected (firmware controller)

Per SFF-8472, the A2h block reserves a 7-byte password area starting at offset 0x7B; most modules use a 4-byte password. A controller in the module compares what is written there with its stored value and only then unlocks EEPROM writes. Without the password every write returns WRITE FAIL.

  • Enter the correct password, then write.
  • If it is unknown: a dictionary search of known vendor passwords (see

EEPROM recoding for common values) or the manufacturer.

  • These controllers are sensitive to clock speed and to the gaps between blocks

another reason to program slowly.

4. Temporary storage with a save command

Writes land in volatile memory. Everything looks fine — until the module is power cycled and the old code returns. The vendor's firmware needs an explicit save command (a proprietary byte sequence) to commit the temporary image to permanent storage. No standard defines it; each vendor's sequence is different and is captured as a script.

5. Combined protection

The newest modules stack several mechanisms: hardware WP and a password and a save command and operational preconditions — for example the module must be placed in low-power mode before it accepts writes. This is typical of modules on recent SFF-8472 revisions that expose 256+ pages above A2h offset 0x80, and of CMIS modules. Programming requires the manufacturer's algorithm, usually shared with bulk-purchase customers.

How to identify the type

  1. Try a plain read: does A2h read cleanly? (Type 1 often fails here.)
  2. Try a single-byte write to an unprotected field. Immediate success → type 1. `WRITE

FAIL` → type 3 (or 5). Silent success that reverts after power cycle → type 4.

  1. Enter known passwords. Still read-only → type 2 (hardware) or type 5 (combined).
  2. Check the form factor and spec revision — CMIS and late-revision SFF-8472 modules

are usually type 5.

In CodingBox

  • Password settings — table address, password address (0x7B) and value are set in

Protected memory & passwords; known passwords are applied from the database.

  • Scripts — CodingBox's programming scripts carry vendor save sequences and unlock

algorithms for types 4 and 5.

  • Byte-by-byte writing and slow clocking for modules that fail at standard speed.
  • Hardware WP is handled by the programmer board, not by software.
  • Every read is saved to the code database before you

write, so a failed attempt is always recoverable.

Source

  • SFPTotal — Types of transceivers by write-protection type and how to program them