Programmer returns WRITE FAIL on an SFP+ that dumps cleanly: dead EEPROM or something blocking writes?
We recode a small batch of modules for customer hosts most months, nothing exotic: read the original page, write the vendor string the host wants, put the module in the switch and move on. One module out of the current batch refuses every write while reading back perfectly, and before I bin it I would like to know whether there is anything left to try.
Bench:
- CH341-class USB programmer with an SFP breakout board
- SFP+ module, diagnostics capable, reads fine cold and after a power cycle
- the same rig wrote three other modules from the same tray an hour earlier
What the tool prints the moment I hit write:
WRITE FAILRe-reading straight after that gives me the original page back byte for byte, so nothing landed at all, not even partially.
What I tried:
- reseated the module and swapped the breakout board for a spare
- wrote a single byte in a region I do not care about instead of the full page, same result
- confirmed the read is stable across several power cycles, so the wiring is not marginal
Is a module that reads clean but never accepts a write simply worn out, or is there something in the module itself that can refuse writes on purpose?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Reads clean, writes refused, original page intact afterwards. That is not how a worn out EEPROM normally behaves. Dead cells give you a bad read-back or a page that took half the write, not a tidy refusal with everything untouched.
And since even that single byte outside the vendor area bounced, this is not a bad region on the chip, it is the part turning writes away wholesale. Two things worth pinning down before you decide anything. First, who actually built the module: go by the vendor string in the page you already dumped, not by whatever the tray was labelled. Second, whether a write lands if you fire it the moment power comes up, before anything else on the bus has talked to the module. The likely explanation differs depending on those answers, and one of them is not a fault at all.
That reads like password protection rather than damage. SFF-8472 allows a diagnostics-capable module to require a 4-byte password before it will accept any write. Send nothing, or send the wrong one, and the module answers the write with an error while reads stay wide open, which is exactly your WRITE FAIL with the page coming back unchanged. It is a feature of the part, not a symptom of a dying one.
What that means for your bench: a programmer that knows about this lets you enter a manufacturer or host password, and the better ones will brute force an unknown one and recalculate the checksums for you after the write. A CH341-class rig has no checksum automation at all, so even after you get past the password you have to fix the checksums yourself, otherwise you end up with a module whose page looks right to you and that the host still refuses.
Usual caveat: I have hit this on a handful of modules and the password route worked there, so try it on your own part before you write off anything.
To add to that: for some vendors the passwords are not really secret. There are shared collections of Ubiquiti transceiver passwords in circulation with entries like 0x00001011 and plain strings such as SFPX and QSFP, so if the module came out of that ecosystem it costs you five minutes to try the known ones before you go anywhere near brute force.
And if you want a tool that already knows the whole flow rather than fighting a generic programmer, the UACC-SFP-WIZARD is the cheap option people reach for. It is not a lab instrument, but it handles the module side properly.
Related, from recoding modules for Huawei S5731 and S6730 hosts and an old HP 6120XG. When the cage or the breakout is the weak link rather than the module, people solder directly to pins 4 and 7 on the module, which are the I2C SDA and SCL lines, and drive the EEPROM with the cage completely out of the picture. Ugly, and you only do it on parts you are prepared to lose, but it removes a whole class of contact problems.
Parts that have gone through that here: Finisar FTLX8571D3BCV and FTLX8574D3BCV, Intel SFP+ LR and SR modules, SNR-SFP+W73-3 and SNR-SFP+W37-3, plus an HP J9150A.
In your case the read is already rock solid across power cycles, so contct is not your issue. Chase the password angle first.
Password is the likely answer, but do not leave it at "type the password and you are done", because two things bite people right after that.
First, on some parts the entry is required again after the module has been powered down, so a script that writes several pages in squence has to be prepared to re-enter it rather than assuming one unlock covers the session.
Second, the checksums. With a CH341-class programmer you recalculate them by hand. Leave them stale and the module still reads fine, your tool reports success, and the host quietly refuses the module anyway, at which point everyone goes back to blaming the hardware. Read the page back and verify the sums before that module goes into a customer switch.