Whatsminer M60S – Control Board Boot Loop

Full AC-drain cold boot. PDU off, leave the unit completely de-energized for five minutes — not 10 seconds, not a soft restart, a real drain. Power back on exactly once. Watchdog-class firmware locks (`267` / PSU hex `0x2000`) and certain `710` transient exceptions clear on a clean cold boot in roughly 60% of field cases. Do this before reaching for a screwdriver. If the loop returns on the next reboot, it is persistent — move to Tier 2.

Verify ambient and airflow. Ambient above 35 °C at the intake, or a physically obstructed intake, can push the M60S's internal PSU or CB thermal sensors into an immediate protection trip on boot (never reaches hashing). Measure intake temp with an IR thermometer at the grille, clear 15 cm of front clearance, retry the cold boot. Canadian garages in July heat-dome weather can 100% cause this.

Swap Ethernet cable and switch port. A marginal patch cable flapping its link LED at 1 Hz can look identical to a CB boot loop — miner boots, fails to reach pool, some firmware builds interpret repeated network-init failures as fatal and reset. Use a known-good cat5e minimum on a different switch port. Inspect AC cord and PDU outlet for heat, smell, or discolouration while you are at it.

Hold `RESET` button for 5 seconds to attempt a configuration reset. Clears stored pool / network / tuning state without re-flashing firmware. If the loop was caused by a bad pool config that crashes `btminer` on init, this clears it. If the loop persists, configuration is not the issue — move to Tier 2. Do not confuse this with the 30-second-hold firmware recovery combo; 5-second hold is safe and reversible.

Open the chassis for standoff + ribbon re-seat. PDU off, five-minute cap-drain, anti-static wrist strap mandatory. Remove the top cover (Torx `T20`, fastener count per the service notes — VERIFY). Torque the four M3 control-board standoffs snug (not cranked). Unplug and firmly re-seat ribbons from CB → button board, CB → PSU, and the three CB → hashboard ribbons. Inspect connector shells for oxidation or scorching.

Export MinerTool logs before the next power-up. Connect Ethernet. Power on. Even if the miner only stays alive 20 seconds, MinerTool V9.0.1 can pick up `system.log` and `power.log` in that window. Export, save, timestamp. These two files determine whether you are on a PSU branch (Step 7) or a firmware/eMMC branch (Step 10) — without them the next three hours are guesswork.

Multimeter on the PSU rail under boot load. Multimeter in DC mode, probes at the PSU-to-CB connector. Expected: rail comes up clean within ~2 seconds of AC-on and sits stable at nameplate voltage until the miner resets. A rail that sags during boot, collapses to zero mid-cycle, or oscillates = PSU-class fault. Confirm by swapping to a known-good M60S PSU (Step 8) — the most decisive test on this error.

Known-good PSU swap. If you own more than one M60S, borrow the PSU from a working unit and confirm. Stable boot with the swap = original PSU's capacitor bank or I²C fault channel is dead; reform the caps at the bench or replace the PSU entirely. Loop continues with a known-good PSU = PSU is ruled out, you are on a CB-class branch. Single most decisive diagnostic step; every Mining Hacker with multiple M60S units keeps a spare for exactly this.

Hashboard isolation. Power off, disconnect all three hashboard ribbons from the CB, power on. If the CB reaches a clean no-hashboards idle (API responds, LED goes to its no-HBs pattern), one of the hashboards is pulling the whole system down — reconnect one at a time, power-cycling between each, until the loop returns. That is your culprit board. If the CB still loops with zero HBs attached, fault is on the CB itself — move to Tier 3.

MinerTool firmware re-flash. Download the correct MicroBT-signed firmware for your exact sub-model (`M60S` / `M60S+` / `M60S++`) from `support.whatsminer.com`. Verify `SHA-256` (`CertUtil -hashfile file.bin SHA256` on Windows, `sha256sum` on Linux/macOS) against the portal's published hash before flashing. In the 30-60 second boot window push via WhatsminerTool V9.0.1 → Firmware Upgrade. Single-unit recovery, do not batch, do not interrupt.

SD-card recovery. Prepare a microSD (8-16 GB, SanDisk Ultra or Samsung EVO — no-name cards fail mid-flash) with MicroBT's recovery image via `balenaEtcher`. PDU off, chassis open, seat the card in the CB's microSD slot (near the Ethernet jack on current revision — VERIFY). Power on. Recovery runs 8-12 minutes; LED walks solid-red → slow-red-blink → alternating red-green → solid-green on success. Remove the SD once recovered.

Serial console bootloader capture. USB-UART at `3.3 V` (FT232RL, CP2102, or CH340 with a `3.3 V` jumper — NEVER `5 V`, you will kill the SoC). Wire `GND→GND`, `TX→RX`, `RX→TX`. Terminal at `115200-8-N-1` (PuTTY, `picocom`, `screen /dev/ttyUSB0 115200`). Power on and capture from the first character. Whichever boot stage prints last is where the failure lives — the strings after pin it to one of the five root-cause buckets.

RTC battery check. The community-confirmed Bitmain `CR2032` issue has an M60S analogue: a dead RTC cell can cause pool-auth TLS certificate checks to fail on boot, which on some firmware builds triggers a respawn-too-fast kernel response and a boot loop. If your CB has a visible coin cell, measure it. Below `2.8 V` = replace. A $2 part that masquerades as a $300 repair — classic undocumented Mining Hacker fix.

Reflow likely-failed caps on the CB (experienced only). Community fix for the related Antminer T17 `error power lost` is reflowing specific capacitors on the CB rather than replacing the whole board; same class applies on the M60S CB when you can see bulged or leaking electrolytics near the DC/DC converters. Hot-air rework, good lighting, fresh caps matched to original voltage + capacitance. Not beginner work but turns a $300 CB swap into a $5 repair when it succeeds.

Stop DIY. Serial console reports `ROM: secure boot fail` or `FUSE: rollback counter`; CB has visible physical damage (burnt traces, bulged caps you are not equipped to replace, bent eMMC pins); loop persists with zero hashboards attached AND a known-good PSU AND a verified firmware flash; two SD-card recovery attempts with verified image both failed. Continuing DIY cannot make it better, only worse. Book a D-Central repair slot.

D-Central bench process. Controlled power-up on a known-good PSU load to isolate CB-only fault; full serial-console capture from power-on; eMMC image validation against MicroBT's signing tree; component-level inspection under magnification, thermal imaging, ESR meter on DC/DC cap banks; CB swap from our graded M6x inventory when beyond component-level repair; post-repair 24-hour burn-in at nameplate. JTAG-class units we coordinate RMA with MicroBT's North American distributor.

Disclose custom-firmware history. If you flashed Vnish, Asicdip, or any unlocked image before the loop started, tell the bench. The fix path differs materially from factory-firmware crashes, and withholding history wastes diagnostic time and your money. Mining Hacker code: tell the bench what actually happened — every repair shop in the industry appreciates this.

Ship safely. CB-only: anti-static bag, small box, ≥3 cm foam on all sides. Whole miner: remove the PSU and pack separately to reduce impact load on CB standoffs, anti-static bag the CB through chassis access, double-box, label as electronics. Include a note listing sub-model, serial, last-known-good firmware version, LED pattern observed, what you flashed, what you swapped. That note saves 45 minutes of bench diagnostic time and saves you `CAD $75+` on the invoice.