Antminer Z15 – Hashboard Not Detected

Hard power-cycle at the breaker for 60 seconds, then cold-boot. This is not a soft restart — physically interrupt mains. Clears any wedged driver state from firmware updates and forces a clean chain-enumeration pass. Roughly 10% of Z15 ERR_NO_HASHBOARD tickets resolve at this step alone because the control board had wedged on the previous boot and never walked the I2C chain cleanly.

Verify ambient temperature at the intake grille with an IR thermometer — not room-middle. Target ≤ 30 °C. Z15 thermal headroom is tighter than newer S19-class miners because the BM1580 silicon is older and the chain-temp sensors fail enumeration when intake runs hot. If ambient is above 32 °C, address airflow before anything else: clear the space in front of the miner, redirect exhaust, add intake ducting, or relocate the miner to a cooler shop.

Shop-vac the intake filter, wipe the front grille, and verify nothing within 15 cm of the front blocks airflow. On Z15s running 12+ months without cleaning, accumulated dust is a legitimate enumeration-fail cause — it blocks inlet air, chain temps spike during boot, and the enumeration routine bails. Full chassis blow-out every 90 days is the maintenance floor for a Z15 in residential or garage deployment.

Re-seat the Ethernet cable and reboot. Edge case but documented: a dead network link during the first enumeration pass has caused Z15s to flag ERR_NO_HASHBOARD on otherwise healthy slots in community reports. Takes 30 seconds to rule out — worth trying before opening the chassis. Verify the link LED lights steady green after reconnect.

Check the Bitmain firmware version via SSH (`cat /etc/bmminer.conf`) or the web UI. If you're on a pre-2021 image, flag for a Tier-2 firmware roll-forward after physical fixes are exhausted — but do not blind-flash at this stage. Note the exact version string for the facts file. Some old Z15 builds have stratum / enumeration bugs that a single version bump resolves.

Power off at the breaker. Open the chassis and re-seat every cable on the dead slot: both 6-pin PCIe power connectors and the signal ribbon. Under bright light, inspect every contact for blackening, corrosion, bent pins, or green verdigris. Reconnect firmly — audible click on power connectors. Close the chassis and boot. Roughly 40% of Z15 ERR_NO_HASHBOARD tickets resolve at this single step in D-Central's repair intake — the Z15 chassis inherits the S17-era unlatched friction-fit ribbons that walk loose under thermal cycling.

Label the three hashboard slots 0/1/2 with masking tape. Swap the suspect board into a known-good slot; move a known-good board into the suspect slot. Reboot. If the fault follows the board, it's a board-level fault (Tier 3 onward). If the fault stays in the slot, it's the control-board I2C path, a ribbon, or a slot-specific rail — Tier 4 bench work. This slot-swap test is the single most important branch point in Z15 diagnostics.

Multimeter on DC, probe the dead slot's 6-pin power connector pins while the miner is hashing at full load. Expect 11.8–12.4 V sustained. Below 11.6 V = PSU is tired, the circuit is undersized, or the control-board-side 12 V buck is failing. Record the exact value — it determines whether the next step is a PSU swap or a control-board bench trip. Hands-free clip leads save time here and keep your probe from slipping into the board under load.

Swap the PSU with a known-good APW9 or APW12. Z15s shipped with APW3++, APW9, and APW12 variants depending on revision — any Bitmain 12 V PSU rated ≥ 1800 W works for a swap test. Boot and re-check the chain enumeration. If the missing board now detects, you had a tired PSU and the fix is a PSU replacement. If the board still doesn't detect, the PSU was a red herring — continue to Step 10.

Measure line voltage at the panel under full load. Expect 235–245 V on 240 V split-phase or 202–212 V on 208 V commercial. Low line voltage drives PSU sag and multi-chain enumeration failures — a common late-evening symptom in North American residential feeds when neighbourhood A/C peaks. If line voltage is low, stop and call an electrician; the fix is upstream of the miner.

Visually inspect the dead hashboard under bright light for burnt components, bulged caps, ring-burns on inductors, cracked MLCCs, or darkened MOSFETs — especially near the PMIC and the input boost stage. If you find any physical damage, stop Tier 2 and go Tier 4. Don't attempt to run a board with visibly blown components — you'll take out adjacent parts and turn a single-chip repair into a full-board replacement.

Flash DCENT_OS — D-Central's open-source Antminer firmware — for per-chip Z15 telemetry (https://d-central.tech/dcent-os/ · source: https://github.com/DCentralTech/DCENT_OS). Stock Bitmain firmware shows chain rollup only, which is useless past this point in diagnostics. DCENT_OS exposes per-chip HW%, per-chain voltage telemetry, and autotune — Mining-Hacker-maintained, open-source, no licensing. Braiins OS+ / LuxOS / Vnish are alternatives where Z15 platform support is confirmed current. Run 20 minutes to stabilise, then capture the chip-level report on all three chains and record the worst positions.

Probe the dead board's input-stage MOSFETs with a de-energised multimeter diode-test. Bleed the caps first. A shorted input MOS means the board cannot energise its own domain rails, which is why the chain count reads 0 even though the silicon downstream may be healthy. Any shorted or open MOS = desolder + replace (Tier 4 bench job — you probably don't have the right parts on hand). Record positions of failed parts for the D-Central intake note.

If per-chip telemetry from Step 12 isolated a single BM1580 as the chain-breaker, reflow that chip position. Remove the heatsink, apply flux to the BGA, preheat the bottom side to ~150 °C, top-side hot air at 310–330 °C for ~30 seconds. Natural cool, re-apply Arctic MX-6 or Thermal Grizzly Kryonaut to the package top, reassemble. BM1580 packages tolerate a single reflow cycle well; a second reflow on the same chip rarely sticks — if the chain drops again within 30 days, that chip is replacement territory.

Replace thermal paste on all chips during any Tier-3 chassis-open work. Z15 pads and paste crumble after 2+ years of continuous operation — Arctic MX-6 or Kryonaut for the chip top, fresh thermal pad material for PCH and voltage-domain ICs. Skipping the paste refresh is how a successful Tier-3 reflow comes back to the bench 60 days later for a different chip position on the same board.

If per-chip telemetry shows chips are present but the chip count still reads 0, the PIC microcontroller's factory calibration is corrupt. This is community-tool / bench territory — D-Central's bench can rewrite the PIC via direct I2C programming with a calibrated fixture. A stock firmware flash will not touch the PIC. Do not attempt a PIC reflash without a programming fixture and the correct calibration data; a wrong setpoint pushes the chips outside the voltage-frequency envelope and takes out the board.

Stop DIY and book a D-Central Z15 repair slot when any of the following are true: two different hashboards in the rig show the same failing chip position (points at a control-path issue, not chip-level), an input-stage MOSFET or PMIC is visibly damaged, a capacitor is bulged, you smell burnt component anywhere on the board, or a single-chip reflow returned a failure within 30 days. Book at https://d-central.tech/services/asic-repair/ — 5–10 business-day turnaround, Canada/US/international accepted. The Z15 is EOL; Bitmain's RMA channel is effectively a dead letter for this generation, so D-Central is your realistic Tier 4 path.

What D-Central does on the bench for a Z15: test fixture with programmable load, per-chip isolation using a mix of Bitmain test binaries (where applicable to the Z15 hardware profile) and community tools specific to the BM1580 generation, chip replacement with new-old-stock or graded salvage BM1580 silicon, input-stage MOS / PMIC replacement with matched parts, PIC reflash with calibrated setpoints, full board wash plus reflow plus reseal, and a 24-hour burn-in at nameplate before the board leaves the bench. Full chain-of-custody documentation so you know exactly what was done.

Ship the hashboards safely: anti-static bags individually, double-boxed with at least 5 cm of foam on every side. Include a note in the outer box with the observed symptoms, firmware version string, exact kern.log lines, and your contact information — that pre-packed diagnostic context saves us 15–30 minutes of intake time, which saves you repair cost. Insure the shipment for the board replacement value, not just the repair value, in case of carrier damage in transit.