Whatsminer Error 701 – Control Board Chip Incompatibility

Pull the chassis top cover and identify the control board silkscreen label. Phillips #2 on M30S-family, Torx T10 on M50S-family, six to eight screws around the perimeter. The control board is the small PCB at the front of the chassis behind the network ports. Read the silkscreen — `CB2-V10`, `CB4-V10`, `CB5-V1`, `CB5-V5`, `CB6-V4`, `CB6-V5`, `CB6-V7`, `CB6-V9`, or `CB6-V10`. Photograph it for your records. This single label tells you whether the control board is the right family for your hashboards. Skip this step and you will be flashing firmware blind for hours. `Code 701` is unforgiving when the hardware mismatch is real.

Cross-reference silkscreen against the chip-family table. `CB2-V10` (`H3`) drives M20S only. `CB4-V10` (`H6OS`) drives M20S/M21S/M30/M30S/M31S/M32 hashboards. `CB5-V1`/`CB5-V5` (`H6OS`) drives M30S+/M30S++/M31S+ refresh + M50/M50S/M50S+/M50S++. `CB6-V4` (`H6`) drives M30S++/M50/M50S transitional. `CB6-V5` (`H616`) drives M53/M63 hydro. `CB6-V7`/`V9`/`V10` (`H616`) drives M56/M66 + late M63S. If your silkscreen ↔ chassis pairing is wrong, no firmware fixes this — plan a control board upgrade (Tier 4 or buy matching board from D-Central). If the pairing is correct, continue to firmware path.

Pull current firmware version and chip type. WhatsminerTool V9.0.1 → API → `get_version` and `get_miner_info`. Record firmware string and `chip_type` field if exposed. Compare against your physical hashboards. If `chip_type` reports a different generation than what's installed, the firmware was cross-flashed — pull the correct `.bin` next step. If `chip_type` matches but `701` still throws, the control board is talking to chips and getting an answer it cannot drive.

Download the correct firmware from `support.whatsminer.com`. Pick the `.bin` matching your exact model. Verify SHA-256 if MicroBT publishes one. Save the file locally. Note the full filename. Do not download from a forum drop or Telegram link — `701` recurrence after a `successful` flash from a non-MicroBT source is a documented field pattern, usually because the build was tampered with or built for a different control board family.

Flash via WhatsminerTool with `Keep configuration` unchecked. WhatsminerTool V9.0.1 → Firmware → Upgrade → select the verified `.bin`. Uncheck `Keep configuration` for clean baseline. Start upgrade. Wait 3-6 minutes. Do NOT power-cycle during flash. When the tool reports success, watch the boot log. If `701` clears on first boot and stays clear for 30 minutes of hashing, monitor 24 hours before declaring fixed. If `701` returns immediately, escalate to Tier 2.

Re-torque the voltage distribution bus. Power down at the breaker. Verify every bus bar bolt between PSU and hashboards is at spec torque (~5-7 N·m typical on M30S/M50S generations — check your model's service doc). Loose bus bars can cause intermittent power delivery to hashboards which surfaces as `Code 701` on the strictest firmware. Re-torque, re-seat hashboard data ribbons, power up, observe. This is one of MicroBT's official recommended fixes for `701`.

Re-seat every hashboard data ribbon and connector. Power off at breaker. Disconnect each ribbon from control board and hashboard side. Inspect for bent pins, oxidation, blackening. Apply gentle pressure to seat each connector fully — listen for the click. Reconnect every ribbon. Power up. `Code 701` from a marginal data ribbon is rare but documented — firmware can't talk to the hashboard cleanly, gets garbage on the chip-family query, reports it as `no support chip`.

SD-card bootloader recovery. Download the MicroBT SD recovery image for your model from `support.whatsminer.com`. Write to a 4-8 GB microSD with Balena Etcher (GUI) or `dd`. Power down. Find the SD slot on the control board (edge-mounted on M30S/M50S, requires top-cover removal on M60-family). Insert the card, power up. Bootloader reads SD image for 2-4 minutes and re-initializes the control board's flash partition. Remove the card after first clean boot. Re-flash the correct `.bin` via WhatsminerTool. SD recovery clears any residue from a partial or corrupted firmware flash that might be causing `701` on a control board that is actually correct for the chips.

Verify chip-type field after recovery flash. Run `get_miner_info` → `chip_type`. If field reports the correct chip family for your hashboards AND `701` is gone, you're done — original fault was firmware corruption. If `chip_type` is still wrong or blank, the EEPROM identifier on the control board may be missing or wrong (factory config flag wiped during a previous flash) — Tier 3.

Check `get_error_code` for sibling faults. After the recovery flash, query the full error array. `701` and `530` (hashboard not found) often appear together when the data ribbon is the actual culprit. `701` and `540` (chip ID read failure) often appear together when one or two specific chip positions are dead but the rest report correctly. Address each error separately — `701` clearing does not guarantee a healthy rig.

EEPROM identifier read (advanced). Some MicroBT control boards store a chip-family identifier in a small I2C EEPROM near the SoC (24C-class chip, package varies by CB-version). Firmware reads this at boot to decide which chip drivers to load. If EEPROM is blank, corrupted, or set to the wrong family, `701` is the result. Power down, isolate the control board from PSU, attach a CH341A I2C programmer to the EEPROM pins per your control-board service doc, read the dump. Chip-family flag offset varies by CB-version. If you don't have access to MicroBT's service decoder, ship to D-Central for a bench dump and reconciliation.

EEPROM identifier rewrite (with matching firmware staged). If you've read the EEPROM and identified the chip-family flag offset, write the correct value for your physical hashboards along with any CRC the EEPROM stores. Reinstall the board, power up, run `get_miner_info` → confirm `chip_type` reports correctly, flash matching firmware. Get the offset or CRC wrong and you brick the control board harder than a partial firmware flash — plan SD-card recovery as fallback.

Control board swap with verified-matching donor. Source a control board with the correct CB-version silkscreen for your chip family. D-Central stocks MicroBT control boards across CB-versions with SoC family verified pre-shipment — CB-version label is one input, but on the refurb market a relabeled board is real risk, so SoC verification matters. Install, flash matching firmware via WhatsminerTool. Pool settings restore via MinerTool's config import; static IPs and worker names re-enter manually. Confirm `701` clears on first boot and all three hashboard slots come up green.

Cross-check firmware train release notes. Some MicroBT models shipped with firmware that had a soft chip-family check (warned but continued) followed by hard-check firmware (refused to boot). If you bought a second-hand miner with soft-check firmware and tried to upgrade to hard-check, `701` can suddenly surface on a board that `always worked`. Roll back to the soft-check build to restore operation while you arrange a control board upgrade — the underlying mismatch is still real, but soft-check firmware will at least let the rig hash while the right board is in transit.

Archive the working build and configuration. Once miner boots green, archive the `.bin`, the SHA-256, the WhatsminerTool version, the EEPROM dump if you read it, the CB-version silkscreen photo, and any chip-family flag values. MicroBT pulls older builds from the public matrix without warning. Local archive is the only rollback path if a future upgrade goes sideways. Treat firmware like configuration: version-controlled, backed up, documented.

Stop DIY when: control board CB-version is fundamentally wrong for the chip generation (e.g. `CB2-V10`/`H3` board with M30S+ or newer hashboards), an EEPROM read returns garbage or zeros, an SD-recovery flash fails to clear `701`, or you're staring at a refurb/relabeled control board you can't trust. The fix is a control board upgrade, not more firmware. Book a D-Central ASIC Repair slot — turnaround 5-10 business days, Canada-wide + US/international.

What D-Central does at the bench. Visual silkscreen verification, SoC family confirmation against the silkscreen (catches relabeled refurb boards), EEPROM dump and chip-family flag verification on a CH341A fixture, control board upgrade from inventory if mismatch is confirmed, firmware flash with matching `.bin`, 24-hour burn-in at nameplate before return shipping. We capture the original EEPROM dump in case the failed board's calibration data is recoverable for a future repair, and you get the dump back on a thumb drive with the miner.

Ship safely. Power down at the PDU, disconnect from network, remove miner from rack. Control-board-only ticket: ship just the control board in an anti-static bag inside a padded box. Control-board + hashboard combo: ship the whole miner double-boxed with ≥ 5 cm foam on every side. Include a note with: observed error codes (`701` plus siblings), firmware version (`get_version` output), CB-version silkscreen photo, miner first-hand or second-hand history, prior flash history, and any donor parts swapped in. The more context, the faster the bench diagnosis, the lower your invoice.