Whatsminer M30S – Hashboard Not Detected

Full cold power cycle at the breaker. A soft reboot from WhatsminerTool won't cut it — kill 240 V at the panel for `60 seconds minimum`. Drains PSU rail capacitors fully, resets the control board's chain-enumeration latches, and clears any wedged driver state from a firmware update or brownout. Bring power back, wait the full 90-second boot, then re-check `Device` view. On newer M30S revisions the chain-enumeration retry count is `2` — if the first attempt fails for any reason, it won't retry without a full cold boot.

Export logs before you touch anything else. WhatsminerTool → `Remote Ctrl > ExportLog`. Save `miner.log`, `upfreq_test.log`, and `power.log` to a dated folder. Open them and grep for `530`, `531`, `532`, `410-412`, `440-442`, `430-432`, `510-512`, `520-522`, and any PSU hex codes. This is the factual record of what the firmware saw — priceless if you ever ship to D-Central, because we can skip intake diagnosis and go straight to the isolated subsystem. Log export is two minutes; skipping it costs hours downstream.

Verify firmware build and hardware revision match. WhatsminerTool → `System > Firmware Version`. Read off the build string (e.g. `20251209.16`). Check the adapter-plate's printed revision sticker against the firmware's intended hardware rev. Flashing an M30S+ build onto an M30S base unit can cause the control board to refuse chain enumeration, presenting as `HB_NOT_FOUND`. If mismatch suspected, note the current build and the correct target build — don't reflash until Tier 2.

Confirm ambient intake temp and airflow. `≤ 30 °C` at the front grille with an IR thermometer. An overheating M30S with PSU-side thermal protection tripped can cut power to adapter rails intermittently, presenting as "hashboard not detected" on boot when the PSU hasn't fully recovered. Rare but real in Canadian summer garages without outdoor air intake. Cool the room, re-attempt power-on in cooler conditions first.

Check community channels for known-bad firmware versions. MicroBT doesn't publish a changelog. Check BitcoinTalk, r/gpumining, and Whatsminer operator Discord servers for recent reports of `HB_NOT_FOUND` correlating with specific firmware build strings. If your build is known-bad, flash one version back via WhatsminerTool → `Firmware Upgrade`. Flash with the correct hardware-revision file only — cross-flashing bricks the control board.

Power off and re-seat every connector on the affected chain. Breaker off, 60-second drain, anti-static strap grounded to chassis. Disconnect the ribbon cable between the affected hashboard and the adapter plate — inspect both ends of every contact under good light. Disconnect the high-current power connectors between adapter plate and hashboard. Disconnect the adapter-plate-to-control-board cable. Reconnect firmly. A re-seat alone recovers 40-50% of M30S `HB_NOT_FOUND` cases in D-Central's intake, especially on units over 18 months old.

Clean oxidized contacts with DeoxIT D5 or 99% IPA. If you saw any green/black oxidation on ribbon contacts, adapter plate pins, or power connector terminals, wipe them with DeoxIT D5 (preferred — contains a thin protective film) or 99% isopropyl alcohol on a lint-free wipe. Let dry fully — 60 seconds minimum — before reconnecting. Vancouver Island, Maritime Canada, and coastal PNW operators deal with this on every M30S older than 18 months. Prairie dust does the same via fine particulate intrusion.

Swap the hashboard into a known-good slot. Power off, label slots with tape, physically swap the undetected board into a slot that was working and move the healthy board into the affected slot. Power on, wait 90 seconds, check `Device` view. This one test tells you whether the fault is board-level or slot-level (adapter/control-board path) — cuts the diagnostic tree in half. Record whether the fault follows the board or stays in the slot.

Measure adapter-plate DC output under attempted boot. Chassis open, multimeter on DC, probe the adapter-plate output rail to the affected hashboard slot during the 90-second boot cycle. Rail should come up to nominal voltage within the first 10 seconds as the control board enumerates each chain. No voltage present → adapter-plate fault (blown fuse, cracked solder under bus-bar, or failed P-FET). Voltage present but no chain comms → comms-level fault on the board or the control-board-side I²C/SPI bus.

Swap the internal Whatsminer PSU with a known-good unit. If multiple chains drop out (not just one), or if adapter-plate voltage is low across the board, the internal PSU is implicated. Pull the PSU, swap in a known-good M30S PSU from a donor unit. Power on, baseline. If all three chains come back, the original PSU is failing internally — check the PSU hex fault code register via WhatsminerTool before ordering a replacement.

Reflash the stock MicroBT firmware for your exact hardware revision. WhatsminerTool → `Firmware Upgrade`. Download the correct build from `support.whatsminer.com` — verify the revision on the adapter-plate sticker first. A clean reflash clears any corrupted control-board state that could be causing chain-enumeration refusal. Do not cross-flash. If running custom firmware (Vnish, Asicdip), revert to stock before further diagnostics — custom Whatsminer firmware trips anti-tamper checks (codes `100001`/`100002`/`100003`) that can silently block chain enumeration.

Reflash the hashboard EEPROM from a known-good dump. If `miner.log` showed `410-412` "detect eeprom error," the EEPROM chip or its I²C lines are the fault. With the board out and on the bench, use an EEPROM programmer (CH341A or equivalent) and a donor dump from a bin-matched M30S hashboard to rewrite the EEPROM. This recovers a real percentage of "dead" boards at effectively zero parts cost. MicroBT does not publish EEPROM dumps — the community maintains them. If programming fails entirely, the chip itself is physically dead → Step 13.

Replace the hashboard EEPROM chip. If reflash fails, desolder the EEPROM (typically a small SOIC-8 or TSSOP-8 package near the adapter-plate connector — check your board revision), clean the pads with flux and braid, solder in a fresh part, reflash with a donor dump. Straightforward SMD rework, not BGA — within reach of anyone comfortable with a fine-tip soldering iron and flux. Verify with the programmer before reinstalling the board in the miner.

Reflow a suspected dead chip on the chain. If per-chip isolation (from `upfreq_test.log` on a sibling error, or from IR thermal imaging showing a cold chip where its neighbours are warm) points to one specific chip position, that chip may have lost a solder ball under BGA. Preheat the board from below to `~150 °C`, top-side hot-air at `310-330 °C` for 30-45 seconds until the solder mask relaxes and the chip self-aligns. Cool naturally. Re-apply thermal interface material, reassemble, test. MicroBT chips tolerate reflow reasonably well — better than Bitmain S19-generation chips, in bench experience.

Inspect and replace failed passives near the affected chain's voltage domain. Bulging electrolytic capacitors, cracked MLCCs, burnt resistors near the PMIC on the affected chain — desolder with flux and braid, replace with footprint-matched parts. Voltage-domain passive failure is a common root cause when the chain comes back *intermittently*, especially across temperature cycles. Any discoloration on PCB traces → stop, that's Tier 4.

When to stop DIY and ship. Stop and ship to D-Central when any of: (a) adapter-plate DC output reads `0 V` under attempted boot and you've confirmed the fuse/P-FET by visual inspection; (b) you see burnt-component odor, PCB trace discoloration, or any visible damage near the voltage domain of the affected chain; (c) an EEPROM reflash, chip reflow, or replacement doesn't recover the chain within one attempt; (d) the same chain fails after a control-board swap; (e) you suspect the control board's SPI/I²C bus to the chain is dead and you don't have spare M30S control boards on hand. Further DIY risks turning a `$200` repair into a `$700` one.

D-Central bench workflow. Programmable M30S test fixture with per-chain current monitoring, simulated pool traffic, and isolation of each hashboard against known-good control and adapter plates. Chip replacement from graded, bin-matched M30S silicon inventory. EEPROM reflash from D-Central's verified dump library, cross-referenced by bin and hardware revision. Full reflow and reseal, 24-hour nameplate burn-in in performance mode before shipment back. Canada-wide shipping, US/international welcomed. Typical turnaround: `5-10 business days`. Ship boards only (not chassis) to save freight — anti-static bags, double-box with `≥ 5 cm` foam each side, include observed symptoms, firmware build string, and power environment notes.