EEPROM (Hashboard)

EEPROM (Electrically Erasable Programmable Read-Only Memory), in the hashboard context, is the small non-volatile memory chip on each Antminer hashboard that stores the board's identity and per-board calibration data. When the control board boots and initializes a hashboard, reading this EEPROM is one of its first acts. The data it finds — board serial number, model and chip configuration, voltage trim values, and frequency calibration tables — tells the firmware how to drive that specific board safely. Get that read wrong, or find garbage there, and a physically perfect board can refuse to hash at all.

Why per-board calibration exists

No two hashboards are electrically identical: silicon quality varies die to die, and each board's chips settle at slightly different optimal operating points. During factory test, every board is characterized and its individual parameters written to its EEPROM, letting one firmware image drive boards of varying silicon without the user tuning anything. Physically, the EEPROM hangs off the board's I2C bus — the same two-wire SDA/SCL pair that carries the temperature sensors, brought to the control board through the standard 18-pin data cable — and answers at an address in the 0x50 range, which is why a quick i2cget probe from the control board's shell can confirm whether the chip responds at all. Board designators vary by model (U5 on the S19, U10 on the S19 Pro, U6 on the S21 family). On some models a PIC microcontroller holds this data in its internal EEPROM instead of a discrete part — the S21 generation, notably, dropped the PIC entirely and keeps a discrete EEPROM.

What goes wrong

EEPROM failures produce some of the most misleading symptoms on the bench, because the chips that do the hashing are innocent. Corrupted data typically means the control board refuses to recognize the board — zero chips detected, or an explicit EEPROM error in the kernel log — even though every hash chip is healthy. Mismatched data is subtler: hashboards mixed from different miners can carry inconsistent EEPROM configurations, and a machine may refuse to run the mismatched set until all three boards are synchronized to consistent data. A stuck I2C bus (SDA or SCL shorted low) can take out EEPROM and temperature sensors together, mimicking multiple simultaneous failures. The diagnostic habit that saves hours: when a board reports zero chips, rule out identity and communication — EEPROM, PIC, I2C — before touching a single hash chip.

Repair and reprogramming

The fix is usually data, not soldering. With an EEPROM programmer or code-editor tool (a CH341A-class programmer covers the generic case), a technician reads a dump from a known-good board of the same model and revision, adjusts board-specific fields, and writes it to the failed board; a genuinely dead EEPROM IC gets replaced and then programmed. Two cautions: always save the original dump before writing anything, and never blind-flash a dump from a different model or board revision — the calibration values are board-specific, and wrong data can mis-tune voltage and frequency rather than merely fail. After reprogramming, verify on a test fixture before returning the board to a chassis. A note on scope: EEPROM work is data-level repair, one of the few hashboard fixes needing no hot air and carrying little physical risk — the skill lies in knowing which dump is correct for the exact board revision, which is why repair communities maintain dump libraries for common models. If a board in your fleet shows these symptoms and the bench work is beyond your tooling, our repair service handles EEPROM-level diagnostics routinely.