Whatsminer M60S – Hashboard Not Detected

Power-cycle with a full 60-second cold reset. Pull the C13/C19 cord at the wall (not just the miner switch), wait a full minute so the PSU bulk capacitors fully discharge, then re-energize. A surprising fraction of Whatsminer HB_NOT_FOUND events recover on cold boot because the control board's I2C bus re-scans the adapter plate and re-enumerates each hashboard's EEPROM on power-up. Note which chain comes back and which stays missing. Expected: all three SM chains report their chip counts within 2 minutes of boot.

Confirm the fault on both WhatsminerTool and the miner's web UI. Connect WhatsminerTool v9.0.1 or newer, run IPFOUND, and pull the status page. Cross-check the chip-count-per-chain with the built-in web UI at http://<miner-ip>. If WhatsminerTool reports all three chains but the web UI shows a missing chain (or vice versa), that's a firmware state issue, not a hardware fault — reboot via the tool and re-test before opening the chassis.

Read the specific error subcode — don't stop at HB_NOT_FOUND. MicroBT's Whatsminer Error Code PDF (2021-09-30) distinguishes at least four sub-families that all present as 'hashboard not found': 41x (EEPROM detect), 42x (EEPROM parse), 44x (chip-count mismatch — community knows this means X chips are dead, not contact technician), and 53x (SM not found — adapter-board or control-board comms). The remediation tree branches hard on which sub-family you're in. Log the exact number before doing anything invasive.

Check your inlet air. The M60S is rated for intake below about 30 °C, and a hot intake can destabilize the control-board-to-hashboard I2C handshake enough to drop a chain on boot. Verify the intake side is clear of obstruction, the room ambient is under 30 °C at the miner's intake, and there's no recirculation from another miner's exhaust blowing back in. If you corrected an airflow problem here, cold-boot again and re-test before going deeper. Expected: stable enumeration at cool intake temperatures.

Power off, then reseat the hashboard ribbon cables at both ends. This is the Mining Hacker first move, not the last. Community data from Zeus Mining, MicroBT repair forums, and our own bench log says the 30x/41x/53x family on Whatsminer is the 'ribbon-cable trinity' — vibration from shipping, rack moves, or fan-induced resonance loosens the contact surfaces before the hashboard actually fails. Press each cable fully home at the control-board end, at the adapter-plate end, and at the hashboard end. Use a bright light — bent pins are the silent killer.

Reseat the DC power harness between the PSU and the hashboards. Whatsminer M60S-class hardware uses bolted copper-bar connections on the high-current side — check every nut with a proper wrench, not fingers. Loose copper-bar contacts show up as intermittent HB_NOT_FOUND because the chain briefly undervolts and drops off the I2C bus before recovering. A torque-spec is not publicly documented by MicroBT; snug to finger-tight plus a quarter turn with the proper socket, then verify no play. Copper is soft — don't gorilla it.

Swap the suspect hashboard into a known-good slot. Power off, move the missing chain's hashboard into the slot of a working board, and move the working board into the original slot. Repower. If the fault follows the hashboard, you've isolated a board-level failure (ribbon cable excluded). If the fault stays with the slot, you've isolated an adapter-plate or control-board failure. This single swap saves hours of dead-end chip diagnostics later. Note: always re-torque the ribbon and DC bolts after any physical move — don't assume they survived the shuffle.

Inspect the adapter plate between the control board and the hashboards. On the M60S, the adapter plate carries power, I2C, and chain-enable signals to each SM slot. Any discoloured trace, swollen electrolytic capacitor, scorched pad, or cracked solder joint at the adapter is a hard stop — you cannot fix hashboard detection if the adapter itself is failing. A 30x magnifier or a cheap USB microscope earns its $25 here. If the adapter is visibly damaged, mark it as the root cause and skip to Tier 3 / Tier 4.

Measure PSU 12V output under load. Whatsminer codes 236, 255, 268, 540, 541, and 542 all trace back to PSU failure according to community data — and PSU-driven rail sag can present as hashboard not detected when it's actually the board browning out. With the miner running a stress test (or as close to steady-state as you can get), probe the 12V rail at the PSU output lugs with a multimeter. Expected: 12.0 to 12.6V static, no sag below 11.5V under full load. Any dip beyond that range means PSU first, hashboard second.

Swap in a known-good PSU of the correct M60S spec. The M60S nominal draw is roughly 3300W at stock; an undersized, aging, or knockoff PSU simply cannot sustain the rail through every chain's voltage-scaling step. If the fault clears when you swap a proven PSU in, you've found the culprit and can price the repair as a PSU replacement rather than a hashboard event. If the fault persists with a known-good PSU, you've eliminated the entire power-delivery branch and the problem is upstream of the hashboard chain.

Factory reset via the RESET button — hold for more than 3 seconds until the LED flickers red-green. This clears any corrupt firmware state that's preventing the control board from enumerating a specific chain. Caveat: the button behaviour differs slightly across M30/M50/M60 generations — on the M60S, watch for the dual-colour flicker and release the moment you see it. After reset, reconfigure pools via WhatsminerTool and re-scan. Expected: clean boot, all three chains enumerated. If the chain is still missing, firmware state is not your problem.

Re-flash the stock MicroBT firmware through WhatsminerTool. Do not attempt to downgrade. The M60S enforces firmware signature verification aggressively, and community reports of hard-bricks on downgrade attempts are well-documented — recovery requires manufacturer-side JTAG access that D-Central and most field shops don't currently offer for the M60S. Flash the latest-available signed MicroBT build (verify build string on the MicroBT download page before flashing). Expected: clean install, no signature errors, full chain enumeration restored if the root cause was firmware corruption.

Avoid custom firmware on the M60S for this fault. Vnish, Asicdip, and HiveOS variants can trigger anti-tamper integrity errors 100001 / 100002 / 100003, which present alongside a missing chain and complicate diagnostics significantly. If you're currently running a custom build and seeing HB_NOT_FOUND, revert to stock MicroBT first, re-verify the fault, and only then consider whether custom firmware is worth the complexity on this specific miner. This is the opposite of the Antminer recommendation — M60S anti-tamper is strict.

Flag the fault for component-level repair when the swap test pins it to the hashboard. If step 7 isolates the fault to a specific hashboard (fault follows the board, not the slot), and ribbon / adapter / PSU have all been eliminated, you are now in EEPROM-reflash, chip-reflow, or dead-chip territory. These are not field repairs on the M60S without a proper bench: hot-air station, 0.3mm reflow nozzles, stencil, chip-level schematic, and the ability to read/write the hashboard EEPROM via an external programmer. Ship to D-Central or the nearest trustworthy repair bench.

Read out the hashboard EEPROM before replacing. If you or your repair partner have SPI programmer access to the hashboard EEPROM, pulling the binary and inspecting the bin-type / chip-count fields can distinguish an EEPROM corruption event (reflashable — CAD $175 to $300 territory) from a physical chip-loss event (reballing or full replacement — CAD $450 to $900). MicroBT publishes no bin-decoder, so this is a community-knowledge task. The D-Central bench maintains a bin-type reference across Whatsminer generations for this exact diagnostic.

Bin-match any replacement hashboard before fitting. Whatsminer error codes 430-432 and 520-522 are thrown when a hashboard's bin type does not match the chassis / firmware expectation — which can happen if you buy a secondary-market replacement with mismatched ASIC bins. Verify the replacement board is compatible with your specific M60S revision (not just the M60 family generically). A wrong-bin board will enumerate, then immediately fault with bin-type error — a different problem wearing the same symptoms.

Escalate to D-Central's repair service when (a) the fault is isolated to the hashboard, (b) all field-repairable causes (ribbon / adapter / PSU / firmware) are eliminated, and (c) the estimated component-level repair cost is lower than a full replacement. D-Central's bench covers EEPROM reflash, ASIC reflow, adapter-plate rework, and per-chip diagnostic sweeps specifically for the Whatsminer SM3 generation. Freight to and from Québec is the Canadian miner's advantage — US and overseas miners pay duty and longer transit but still beat the Zeus Mining turnaround on quality control.