Whatsminer – MinerTool Diagnostic Codes
Informational — Monitor and address as needed
Symptoms
- WhatsminerTool dashboard shows one or more numeric codes (e.g. 213, 236, 410, 540, 2020, 5110, 8410) next to a miner in the scan list
- Red/amber status indicator in the tool device tree with code tooltip on hover
- Web UI at http://<miner_ip>/cgi-bin/luci/admin/status/overview displays the same code plus a short English description
- API response on TCP 4028 includes an `Error Code` field in the `summary` command output
- `miner.log` (exported via MinerTool) contains lines matching `error_code=XXX` or `fault: XXX`
- A 100001, 100002, or 100003 code appears on a miner running non-stock firmware (Vnish, Asicdip, HiveOS, jailbroken builds)
- A 0x0001-0x2000 hex code appears in `power.log` but is not mapped to a human-readable description in the tool UI
- LED status on the miner chassis is blinking red (fast or slow) and the web UI code matches the LED decoder reference
- Code appears intermittently - sometimes on scan, sometimes not - indicating a borderline thermal, voltage, or fan-speed threshold condition
- A code in the 2010-2350 range appears but the miner is actively hashing shares (pool/stratum failover code)
- A code in the 5110-5112 range appears only during startup / frequency ramp, then clears once the miner reaches target hashrate
- `system.log` shows an 8410 code after a firmware upgrade, indicating model/firmware mismatch (e.g. M20 firmware on an M30 chassis)
Step-by-Step Fix
Export the full log bundle first. In WhatsminerTool, select the miner, Remote Ctrl -> ExportLog. Save the ZIP with the date and miner serial in the filename. You will reference miner.log, power.log, and system.log for every diagnostic step. Operators who skip this step and try to diagnose from the UI code alone fix the wrong thing about 40% of the time. The logs contain the real error narrative - timestamps, voltages, PMBus dumps, per-chain readings, firmware state transitions.
Screenshot the status panel on the miner's web UI at http://<miner_ip>/cgi-bin/luci/admin/status/overview. Capture error code, firmware version, uptime, per-chain hashrate, per-chain temp, fan RPMs, PSU input voltage. This becomes evidence for any escalation to D-Central or MicroBT, and doubles as before/after reference if you start making changes. Name the file with the date and miner serial so you can compare across service visits.
Cross-reference the numeric code against the range table: 110-140 fan, 200-275 power, 300-352 temp sensors, 410-442 EEPROM, 510-562 chip, 600-610 chassis thermal, 710-712 control-board, 800-802 firmware, 100001-100003 anti-tamper, 2010-2350 pool, 5110-5112 freq ramp, 8410 firmware/hardware mismatch. This single step cuts diagnosis time in half. Knowing the range tells you which log file to open first.
Power-cycle the miner hard at the breaker, not via soft-reboot. Soft reboot leaves the BMC running; a breaker cycle forces a full cold-start of the BMC, the PSU microcontroller, and every hashboard PMIC. Many transient codes - especially 710-712 watchdog flags and some 100xxx anti-tamper false positives - clear after a cold start. Wait 60 seconds with the breaker off for full capacitor discharge.
Confirm firmware version against the MicroBT compatibility matrix. If you are on a build older than 20230801, most codes in the 2010-2350 range (pool/stratum) and the 100001-100003 range (anti-tamper) won't even be emitted - upgrade. If you are on a build newer than 20251209.16, check the D-Central firmware changelog for known regressions before treating the code as real. Always flash firmware matching your exact chassis model.
Decode the PSU hex code from power.log. Open the file in any text editor, search for `0x` - entries appear as `psu_fault: 0xXXXX` or `pmbus_register: 0xXXXX`. Reference: 0x0001 input under-voltage, 0x0002 input over-voltage, 0x0004/0x0008 output over-current rail A/B, 0x0010 over-temp secondary, 0x0020 fan stall, 0x0040 PMBus timeout, 0x0080 output short, 0x2xxx critical silicon fault. If 0x0004/0x0008 coincides with 236/237/238, the true cause is a hashboard chip drawing out-of-spec, not a tired PSU.
Measure line voltage at the outlet under full load with a multimeter. Probe while the miner is actively hashing at full power, not at idle. Expect 235-245 V on 240 V split-phase or 202-212 V on 208 V commercial. Below those windows and you have a circuit sag problem that generates phantom 200-275 codes on a healthy miner. Sag during evening peak (6 PM-10 PM) but not overnight points at neighborhood load on a shared transformer - electrician territory.
Measure PSU output voltage at the hashboard connector under load. Multimeter on DC, probe the screw terminal where the PSU output meets the hashboard. Expect the model-specific value: 14.0-14.5 V for M30/M31 series at stock, 16.5-17.5 V for M50/M53 series, higher for M60/M63/M66. If output sags >0.5 V under load while input is clean, the PSU is dying. Confirm by swapping with a known-good unit from spare-parts shelf.
Re-seat the hashboard adapter plate and all ribbon cables for any 410-562 code. Power off at the breaker, disconnect the ribbon connectors, inspect for oxidation / bent pins / dirt, apply a light pass with 99% isopropyl on a lint-free wipe, reconnect firmly. Listen for the click. About one in three 410-412 (EEPROM read) tickets resolve here - the EEPROM is fine, the data line was intermittent. Common on miners in humid or freeze-thaw environments.
Clean the chassis intake and verify all fan RPMs for 110-140 fan codes and 600-610 chassis thermal codes. Vacuum the filters, wipe the intake grille, verify every fan spins freely by hand (miner powered off), check the dashboard for RPM readings under load - target is typically 4500-7000 RPM depending on model. One fan reading 0 RPM while the others are fine = dead fan, not a firmware problem.
Reflash stock firmware via MinerTool for 800-802 or 8410 codes. Download the correct firmware for your exact chassis model number (the M-series identifier on the back plate, not the SKU on the invoice - M30S, M30S+, M30S++ are three different firmware targets). In WhatsminerTool -> Upgrade -> select firmware file -> start. Wait for Success status. If the M50/M60 was previously Vnish-converted, the bootloader may reject stock - skip to recovery-mode reflash. Never interrupt a firmware upgrade.
Reflow a failing chip for persistent 540-562 codes. Once you have isolated which chip position is dominant in upfreq_test.log and confirmed it is not an adapter-plate or ribbon issue, remove the hashboard, apply flux to the target chip's BGA pads, preheat the bottom to ~150 C, and hit the top with hot air at 310-330 C for about 30 seconds. Let it cool naturally. Re-apply thermal paste (Arctic MX-6 or Kryonaut), reassemble, retest. A second reflow within six months is a signal to replace rather than reflow again.
Reflash PSU firmware on a Whatsminer PSU if 0x hex codes persist after physical checks. This is a lesser-known MicroBT workflow - the PSUs run their own firmware, and MicroBT's service tool (separate from MinerTool, distributed only to authorized repair partners like D-Central) can reflash PSU firmware over PMBus. Customer-accessible alternative: if the PSU is under 18 months old and generating persistent hex faults that clear on cold start, book a D-Central bench diagnosis.
Replace a dead thermistor for 300-340 sensor codes. The chassis thermistors are low-value NTC thermistors soldered to the control-board adapter or a small sub-PCB. When one dies, the BMC reads -999 C or +999 C and flags it as 'sensor missing' or 'catastrophic over-temp.' Desolder, solder in a matching replacement (10 kOhm NTC, B-value 3435 or 3950 depending on generation - check silk on PCB). Re-glue the sensor bead with thermal-conductive epoxy.
Run a per-chip current audit via SSH + cgminer API. SSH into the miner, query the API with the `stats` command, parse per-chain voltage, current, and temp fields. Compare across all three hashboards. A single board drawing >10% more current than the other two, at the same voltage, is a failing chip or a bad voltage-domain regulator - the most reliable way to pre-emptively spot a chip about to generate a 540 / 560 code before the BMC flags it.
Stop DIY when: a 0x2xxx PSU hex code persists after PSU swap (silicon-level PSU fault - bench replacement); a 540-562 chip code isolates the same chip position on two different hashboards (PCB-layer or firmware issue); a control-board 710/712 code persists after breaker cycle and firmware reflash (BMC flash death); any 100001-100003 code on a miner you do not know the firmware history of (custom-firmware conversion with no audit trail - we recover stock with the service tool). Book a D-Central ASIC repair slot.
What D-Central does at the bench: test fixture with programmable load for per-chain / per-chip isolation, official MicroBT service tool for EEPROM and PSU firmware reflash (not distributed publicly), chip replacement with graded salvage or NOS inventory for the full M-series chip families, reflow + reseal + post-repair 24-hour burn-in at nameplate, and final verification with a clean MinerTool scan showing zero codes.
Ship safely. For partial-miner repairs (hashboards only, PSU only), pack in anti-static bags, double-box with >=5 cm of foam on every side. For full miners, leave the chassis assembled - Whatsminers ship well in original cardboard. Include a note with observed MinerTool code(s), firmware version, exported log bundle on a USB stick or emailed to the case, and your contact info. That one page of notes cuts our bench diagnostic time in half.
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.
