Repository navigation
[dev test] w27e257 — FAIL (7a89fcea856a) #23
Description
| Step | Verdict | Reason |
|---|---|---|
| id | OK | - |
| read | OK | - |
| blank-check | OK | - |
| write | BAD | - |
| verify | BAD | - |
| erase | OK | - |
{
"schema_version": "1.2",
"generated": "2026-08-06T08:32:52Z",
"auto_capture": {
"host_version": "3.0.0b15",
"fw_board_identity": null,
"hw_revision": "Rev 2.0-class, Override HW: Rev 2.3",
"chip": "w27e257",
"protocol": "7",
"chip_id_expected": 55810,
"chip_id_actual": null,
"chip_id_mismatch_reason": null
},
"transport_health": {
"cobs_errors": "not measured",
"crc_failures": "not measured",
"retries": "not measured",
"timeouts": "not measured",
"transport_suspect": false
},
"steps": [
{
"op": "id",
"verdict": "OK",
"reason": "",
"error_code": null,
"fingerprint": null
},
{
"op": "read",
"verdict": "OK",
"reason": "",
"error_code": null,
"fingerprint": null
},
{
"op": "blank-check",
"verdict": "OK",
"reason": "",
"error_code": null,
"fingerprint": null
},
{
"op": "write",
"verdict": "BAD",
"reason": "",
"error_code": null,
"fingerprint": "blank/contact"
},
{
"op": "verify",
"verdict": "BAD",
"reason": "",
"error_code": null,
"fingerprint": "blank/contact"
},
{
"op": "erase",
"verdict": "OK",
"reason": "",
"error_code": null,
"fingerprint": null
}
],
"banner": {
"n_ran": 6,
"m_applicable": 6,
"locked_steps": []
},
"voltage": {
"vpp_before_mv": 12500,
"vpp_after_mv": 12500,
"vpe_before_mv": 14600,
"vpe_after_mv": 14600,
"vpp_mv": "not measured",
"vpe_mv": "not measured"
},
"is_submittable": true,
"dedup_fingerprint": "7a89fcea856a",
"db_diff": {
"current_support_status": "supported",
"proposed_disposition": "suggests: community-fail signal (advisory -- human triage required)",
"ladder_state": "community-fail"
}
}
Activity
henols commentedon Aug 8, 2026
Consolidated reports for w27e257
2
dev testreports describe this EPROM. Folding them here so it is triaged once.7a89fcea856a3870f9b5f6caIssues sharing a fingerprint are the same failure re-reported. A PASS row is evidence (the chip can work — suspect intermittency or a since-fixed path), not grounds to close this issue.
henols commentedon Aug 8, 2026
Datasheet cross-check — W27E257
Datasheet: Winbond W27E257, Revision A3, January 1997 (
datasheets/W27E257.pdf)Failing steps: write BAD, verify BAD (folded #24: blank-check BAD)
DIP28_27256pin_count: 28,0x8000vcc: 5Vchip_id_value: 0xda02pulse_duration: 100 usvpp: 13.5V,vpp_mv: 135000x07, genericeprom.cpppath shared with W27C512 / M27C512The pin map is right and the chip ID is right — this is not a wiring or identification fault.
Two rows do not match, and both sit directly on the failing steps.
vpp: 13.5Vis wrong for programming. The datasheet's program condition is VPP = 12V; 14Vis reserved for erase. 13.5V is below the 14.5V absolute maximum so it is not destructive, but
it is outside the specified program condition in both directions. The report measured
vpp 12500 mV, so the rail did not reach the requested 13.5V either — the requested value andthe delivered value disagree as well.
Program verify wants CE HIGH with VPP still at 12V. This part is unusual:
Program Verifyis CE = VIH, OE = VIL, VPP = VPP (12V). Compare W27C512 on the same protocol
0x07, whoseprogram verify is CE = VIL with OE/VPP dropped to VIL. One generic implementation
cannot satisfy both, and firmware has a single
eprom.cppcovering 0x07/0x08/0x0B with noper-part variation. That is a coherent single explanation for
write BADandverify BADtogether: the bytes may well be programming, and the verify read is then performed under
conditions this device does not answer in.
Note also that W27E257 carries VPP on a dedicated pin 1 with OE separate on pin 22, whereas
protocol
0x07is described as "requires VPP on OE/VPP pin". The pinout key encodes pin 1correctly, so the bus config is right — but the algorithm's assumption is not this part's
topology. Directly relevant to #15 ("Implement protocol-specific EPROM programming algorithms in
firmware").
Most likely cause: the shared
0x07program-verify sequence, withvpp: 13.5Vas a second,independent defect that should be corrected to 12V regardless. The
vppvalue is generated bybuild_db.pyfrom infoic, so the fix belongs in the decode function, not in the JSON.Unchecked: whether erase actually reaches A9 = 13.75–14.25V at the socket (the firmware does have
a
CTRL_VPP_A9_ENABLEpath, but the achieved voltage needs a DMM); the datasheet gives no VPPtolerance for the program condition, only for erase, so how far 13.5V is out of spec is not
quantifiable from this document.
Folded #24 (blank-check BAD, fingerprint
3870f9b5f6ca) into this issue — a distinct failure ofthe same EPROM, kept in the consolidated table above.
AndersBNielsen commentedon Aug 9, 2026
henols commentedon Sep 12, 2026
Hi @AndersBNielsen — resuming the thread from 2026-08-09. You were right: what you flagged as a rig fault got reported back to you as a chip verdict, and the triage argued against you on exactly that point. That argument was wrong.
The limit this tool still has, stated plainly. The fix here is not "the tool can now see an unhooked VPP" — it can't, and it still won't be able to on your next run. The report's status axis only fires for a serial error or a hardware-operation error; a mis-wired VPP doesn't raise either of those, it just produces bad read/write/verify data that still gets treated as an ordinary chip result. So a fresh run today, on the same rig fault, would still show
write BAD, verify BADand would still file under aFAILtitle — not a harness-status title. Re-running with the same VPP wiring will not come back clean.What actually changed. Two things, and neither is "the tool now detects your fault":
vpp_mv/vpe_mvvoltage fields were removed from the report entirely. They read the boost-regulator rail, and a regulator rail reads healthy even when the socket itself isn't wired up — which is exactly the trap you hit.That's the honest version of what those readings can and can't tell you. It would have kept you from reading a healthy rail as a healthy socket connection back in August.
The W27E257 datasheet defect is still open, unfixed, and on the record. The programming voltage this project's own database carries for the W27E257 is
13.5 V; the datasheet gives12 V. That's not retracted, not quietly dropped, and nothing else currently tracks it as fixed. When it's corrected, the fix goes into the database generator's decode function; the generated database file itself is regenerated wholesale from that generator and is never hand-edited. Separately: the W27E257 is an EEPROM, not a UV-EPROM, so none of that recent UV-part harness work touches this chip's family at all.Being precise about what I'm conceding. You mentioned the second run actually passed — I want to be careful here, because I looked, and there's no w27e257 run in the tracker that reads PASS; both w27e257 reports here (this one and the earlier #24) are FAIL. What I'm conceding in full is the general point you made: a rig fault got written up as a chip verdict. I'm not going to imply a passing run exists when the tracker doesn't carry one.
Labels changing on this issue, and why. I'm adding
cause:rigalongside the standingcause:database— the database defect above is real and unfixed, so that label was never wrong, it's just not the whole story. And I'm addingneeds:reportbecause this is now waiting on a fresh run from you.If you want to re-run it. Reports are now at
schema_version2.0, and the deduplication fingerprint was deliberately re-keyed in this same release — a fresh run will not group with this old one, and that's expected, not a new defect on top of the old one. Install the released app version3.0.0b39(pip install --pre -U firestarter— the plain, non---preinstall on PyPI is still a 2.x release, none of this is in it), flash firmware3.0.0b27withfirestarter fw --install, then runfirestarter dev test w27e257again. If your VPP wiring is fixed this time, the report will tell you plainly rather than reading a healthy rail as a healthy connection.This issue stays open — I'm not closing it on my own reading, only on your response.