Antminer S17 – Hashboard Not Detected
Critical — Immediate action required
Symptoms
- Web UI `Miner Status` reads `ASIC 0` on one or more chains while the others read the expected chip count (nominal: `48` BM1397 chips per chain on S17 Pro)
- `kern.log` or the miner status page shows `check_asic_number_with_power_on: Chain[0] find 0 asic` (substitute `[1]` or `[2]` for whichever chain is dead)
- Kernel log also shows `bitmicro_pll_init Chain[N] failed`, `get power type version failed`, `ERROR_POWER_LOST`, or `fail to read pic temp`
- Total hashrate drops to roughly `2/3` of nameplate (one dead chain) or `1/3` (two dead chains) — on a stock S17 Pro that's ~35 TH/s or ~17 TH/s vs the 53 TH/s nameplate
- Dashboard `missing chain` indicator or red X on a specific chain position
- Fans on the suspect slot ramp to 100% — control board can't read the chain temp sensor so it defaults to max PWM for safety
- Hashboard status LED on the affected chain is dark or red-latched while the other two boards' LEDs are green
- Miner still boots to the web UI and connects to pool — this separates ERR_NO_HASHBOARD from CB_ERR or ERR_SHORT
- Pool dashboard reports reduced share submission and lower accepted-shares-per-minute
- Swapping the suspect board to a different slot: fault either follows the board (board fault) or stays in the slot (backplane / cable / control-board fault)
- Visual inspection: ribbon cable partly out of its ZIF socket, bent data-connector pin, darkened power-connector contact, or hairline solder cracks near VRM components
- Chain enumerates briefly at cold start then drops after a few minutes of hashing — the classic S17 solder-joint fatigue signature (cold-works-hot-fails)
- On S17s past the 2-year mark: fault appeared gradually after weeks of rising HW% before chain disappeared — solder fatigue in the VRM/boost power tree
Step-by-Step Fix
Breaker-off power cycle for 60 s minimum. Flip the breaker fully off, wait a full minute — not 5 s — to let residual rail voltage discharge and wedged chain-init driver state clear, then flip on. Watch the web UI for the missing chain to reappear. A meaningful fraction of transient ERR_NO_HASHBOARD events on the S17 come from stuck chain-init state and nothing more. If the chain reappears, monitor for 24-48 h before declaring it fixed — the underlying fault may still be there and will likely return.
Factory-reset the firmware profile. Hold the IP-Report / Reset button for 5 s within the first 2 min after power-on. This clears any custom autotuner state, aggressive undervolt profile, or overclock that may be pushing a marginal domain past its cutoff. S17s live closer to their silicon ceiling than newer generations, and a profile that worked for 18 months may suddenly trigger find 0 asic as solder joints age.
Verify ambient and airflow. S17s throttle aggressively and will drop chains under thermal stress. IR thermometer on the intake — target <= 30 C for S17 family (tighter than S19). Confirm nothing is blocking intake filters, miner has >= 30 cm clearance on the intake side, and exhaust isn't recirculating to intake. A dusty filter alone can push an aging S17 into chain-drop territory. Running hot is the single most damaging thing you can do to the generation.
Check firmware version and consider rolling back. S17 firmware has shipped builds with chain-init regressions. Log into the web UI, note installed version, cross-check against support.bitmain.com/hc/en-us/articles/900000245886 and the S17 firmware download page. If you're on a flagged build, roll one version back via the documented SD-card recovery procedure — the S17 has a microSD recovery slot, unlike newer generations.
Reseat network cable and verify pool configuration. Rule out the `looks like a chain problem but actually the pool disconnected` scenario by confirming pool connectivity, that the config hasn't reverted to factory defaults, and that eth0 link LED is solid green. If the miner restarted into factory defaults, your pool URL and worker name are gone and need re-entering before you can see whether hashing actually resumes.
Open the chassis and re-seat every ribbon cable. Breaker off, 60 s discharge. Phillips #2 driver off the top cover. ESD wrist strap grounded to chassis. For every hashboard data ribbon: flip the ZIF latch open, pull the ribbon fully out, inspect contact fingers and socket pins with a 10x loupe for corrosion / bent pins / dust, push the ribbon fully back in until it bottoms out, close the latch until you feel and hear the definitive click. Do the same at the control-board end of every ribbon. This fixes a meaningful fraction of S17 ERR_NO_HASHBOARD tickets and costs nothing.
Re-seat the hashboard power connectors. The multi-pin power connector between each hashboard and the PSU harness is an S17-generation failure point. Unplug, inspect for darkened pins or melted retention clips, reseat firmly. Darkened pins = replace the connector or ship to D-Central. Never re-power a visibly heat-damaged connector — the next startup transient may take out the backplane and turn a CAD $20 connector fix into a CAD $320 control-board replacement.
Swap the suspect hashboard to a known-good slot. Label slots 0 / 1 / 2 with tape. Move the dead-chain board to a healthy slot and a healthy board into the suspect slot. Power on, watch kern.log. This 5-minute swap tells you definitively: fault follows the board (board is bad, proceed to Tier 3) or fault stays in the slot (control board / backplane / ribbon is bad, likely Tier 4). Document the result photographically before doing anything else.
DMM the +12 V rail at the board-to-backplane connector under load. Multimeter on DC volts, black lead to chassis ground, red lead to +12 V pin on the backplane-side header. Miner hashing at full power. Expect >= 12.2 V sustained. If it sags to < 11.8 V under load, APW9 / APW9+ is tired or the backplane trace is damaged. Rock-solid voltage means power is fine and the fault is on the hashboard itself.
Swap PSU with a known-good APW9 or APW9+. Match the variant exactly. If the chain comes back with the known-good PSU, the original is the fault. Ship the original APW9 to D-Central for a component-level rebuild — typically CAD $120-240 which beats a new unit. If the chain stays dead with the swap, PSU is not the issue and you can escalate to bench work on the hashboard.
Flash DCENT_OS — D-Central's open-source Antminer firmware — for post-repair validation and per-chip isolation. Per-chip HW%, autotune, per-domain voltage/temp diagnostics, stratum v2, source on GitHub at github.com/DCentralTech/DCENT_OS. Alternatives: Braiins OS+, LuxOS, Vnish. Why this matters on the S17: once you bring a chain back, DCENT_OS tells you which position in the 48-chip chain was nearly dead — giving a pre-emptive repair target before the chain re-fails. Stock Bitmain firmware hides exactly the data that saves your next hashboard.
Re-flash the hashboard EEPROM. Before any chip-level work, rule out EEPROM corruption on the hashboard-identity chip. Zeus Mining's workflow uses their proprietary `hash board code editor` gated behind an email request; D-Central uses an in-house procedure on our bench. If you don't have hashboard EEPROM tooling, this is a ship-to-bench step — the cost of getting it wrong (bricking the hashboard identity and forcing full-board replacement) is much higher than the cost of shipping.
Bench-PSU bring-up of the suspect board. Lab PSU at 13.8 V, current limit 2 A. Connect only +12V_IN and GND — no ribbon, no data. Power on. Healthy S17 board draws < 0.3 A in pre-bringup and settles within 2 s. Shorted board clamps at the current limit with voltage sag. IR thermometer or thermal camera over the board within the first 5 s — the shorted component heats first. Mark, photograph, cut power immediately. This technique saves hours of blind probing.
Reflow the VRM / boost-stage power tree. The single most valuable S17-specific repair. If the board is at fault, no visible component damage, and the miner passes cold and fails hot, the hashboard has solder-joint fatigue in the VRM area. Hot-air rework station at 310-330 C top-side, bottom-side preheat ~150 C, flux the entire VRM/boost region, reflow for ~30 s watching solder visibly wet back onto pads, let cool naturally. Community consensus: reflow fixes ~30% of `dead` S17 hashboards that are really cold-solder victims.
Replace a dead BM1397 chip via BGA reflow/replace. If per-chip diagnostics (from DCENT_OS / Braiins OS+ / LuxOS / Vnish after a successful chain re-enum, or from Zeus's PT2 test fixture before) isolate a single dead chip breaking the daisy-chain, it's reflow or replace territory. Zeus documents chip positions 13, 15, 23, and 63 as commonly called-out failing positions on S17+ chains — probe there first. Chip replacement requires 0.5 mm pitch BGA rework experience; D-Central stocks graded BM1397 chips for this.
Replace a dead PIC microcontroller. If the log shows `fail to read pic temp` and the chain is dead, the hashboard PIC is suspect. PIC chip swap is a focused rework operation: hot-air the dead PIC off, replace with a pre-flashed equivalent (D-Central stocks these), reflow and re-verify. This is specialist-level QFN / TQFP rework; if you're not confident with this package class, ship the board.
Know when to stop DIY on an S17. Ship to D-Central when: visible fire damage / bulging caps / cratered chips / PCB delamination; two hashboards drop within 30 days (upstream APW9 / circuit issue); fault stays in the slot after board swap; bench-PSU isolation points at a dead chip and you lack BGA experience; hashboard EEPROM corruption without tooling; or your reflow didn't hold past 30 days. The S17 generation especially rewards knowing when to stop — attempts past skill level frequently turn a CAD $150 repair into a CAD $400 full-board replacement.
Ship safely to the Mining Hackers. Anti-static bag per hashboard. Double-box with >= 5 cm foam on every side. Ship the control board separately if suspect. Include a printed note with observed symptoms, kern.log excerpt if captured, firmware version, date of first fault, electrical environment (120/208/240 V single/split/3-phase), and contact info. D-Central's S17-family bench: programmable current-limited load, per-chain voltage-rail validation, thermal-camera isolation, VRM/boost reflow, chip/PIC/MLCC replacement, hashboard EEPROM validation, 24 h nameplate burn-in with DCENT_OS per-chip logging. Turnaround 5-10 business days, Canada-wide, US and international welcome.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
