Whatsminer Error 810 / 820 – Wrong Firmware Water vs Air

Identify the chassis before you touch the firmware. Read the model sticker on the rear panel above the PSU. Write the full model string down. Open `support.whatsminer.com` in a browser and confirm your exact model's cooling variant (air / hydro / immersion). If the sticker is gone or illegible on a second-hand miner, look at the chassis: visible fans = air; water quick-connects on the back = hydro; neither and flat profile = immersion. This single step prevents ~80% of `Code 810` recurrence because it stops you from flashing the wrong `.bin` the second time. Do not skip it because it seems obvious — every `Code 810` support ticket we see starts with someone assuming they knew the chassis.

Record the current firmware string via `get_version`. WhatsminerTool V9.0.1 → API → `get_version`. Record the full output, including any `_air`, `_hydro`, `_immersion`, `_air_V20xxyy`, `_hydro_V20xxyy` suffix. If the suffix matches your physical chassis: the EEPROM flag is probably wrong — jump to Tier 3. If the suffix does NOT match your physical chassis: you flashed wrong firmware — stay in Tier 1 and re-flash correctly.

Pull the correct firmware from MicroBT's matrix. `support.whatsminer.com` → Firmware → select your exact model → download the variant whose filename names your chassis type. Do NOT download the generic-sounding file without confirming the chassis tag. MicroBT's matrix sometimes lists an "air/hydro" universal build — those still require the matching EEPROM flag and are not a shortcut. Save the file. Note the full filename for the flash step.

Verify the download before flashing. If MicroBT publishes a SHA-256 checksum for the `.bin`, verify (use `Get-FileHash` on Windows, `sha256sum` on Linux/Mac). If no hash is posted, download twice from the same page and compare file sizes and hashes locally. Corrupted firmware downloads are a surprisingly common cause of `Code 810` recurrence after a "successful" flash — especially on slow or captive-portal wifi. Three minutes of verification saves you an hour of troubleshooting.

Flash via WhatsminerTool. WhatsminerTool V9.0.1 → Firmware → Upgrade → select the verified `.bin`. Uncheck "Keep configuration" on a second-hand miner (you want a clean baseline); check it on your own miner if your pool settings are already correct. Start the upgrade. Wait 3-6 minutes. DO NOT power-cycle during flash — that's how control boards brick mid-upgrade. When the tool reports success and the miner auto-reboots, watch the first boot log. If `Code 810` clears and hashboards come up green, monitor 24 hours before declaring fixed.

If MinerTool flash fails with `verification error` / `signature error`, try again with "Keep configuration" unchecked. Config-layer corruption occasionally wedges the upgrade state machine on MicroBT firmware. Unchecking "Keep configuration" blows away the cached config on flash and usually gets the upgrade past a previously-stuck verification step. If it still fails, the control board is half-flashed (partially written `.bin`) and you need Tier 2 SD-card recovery to get back to a clean state.

SD-card bootloader recovery. Download the MicroBT SD recovery image for your exact model from `support.whatsminer.com`. Write it to a 4-8 GB microSD card with Balena Etcher (GUI, recommended) or `dd` if you live in a terminal. Power the miner off. Locate the SD card slot on the control board — usually on the side edge, accessible through a small slot in the chassis on M30S/M50S, or requires top-cover removal on M60/M66. Insert the card label-side as shown in your model's teardown doc. Power on. The bootloader will read the recovery image for 2-4 minutes, re-initialize the control-board flash partition, and reboot to a clean flashable state. Remove the SD card after the first clean boot and re-flash the correct `.bin` via WhatsminerTool.

Verify EEPROM chassis flag via API after recovery flash. WhatsminerTool → API → `get_miner_info` → check the `chassis_type` field. If it matches your physical chassis, you are done. If it does NOT match, the EEPROM flag is wrong — you have an EEPROM programming problem, not a firmware problem. Tier 3 from here.

Cross-check `get_error_code` output. Some MicroBT firmware trains throw `Code 810` and a sibling code at the same boot (e.g. `Code 5070` coolant flow on hydro if the pump never spun up because the air `.bin` didn't drive it). After your recovery flash, run `get_error_code` and confirm no sibling codes are lingering. If they are, treat each separately — `810` can clear while a pump or leak-sensor fault remains.

Document the firmware version for your archive. Pull `get_version` one more time after everything is green. Archive the full version string, the `.bin` file, and the SHA-256 hash into your miner's maintenance log. Next time MicroBT ships an upgrade and it goes sideways, you have a known-good rollback point. Five minutes of record-keeping saves hours on the next firmware incident.

EEPROM chassis-type flag read. If Tier 2 confirmed the EEPROM flag is wrong for your chassis, you need to read the EEPROM directly to confirm. MicroBT control boards use a standard I2C EEPROM (24C64 / 24C256 class, package varies by control-board revision). Power the control board off, isolate it from the PSU, and clip a CH341A-class I2C programmer to the EEPROM pins per the board's schematic (service docs on `support.whatsminer.com` cover pinouts for most M-series; for older boards you may need to cross-reference the chip datasheet). Read the full EEPROM dump. The `chassis_type` flag lives at a known offset — it varies by control-board generation. If you do not have access to MicroBT's service tools to decode the dump, you are in bench territory — ship to D-Central.

EEPROM flag re-write (with the matching firmware staged). If you have read the EEPROM successfully and identified the `chassis_type` offset, write the correct value (`air`, `hydro`, or `immersion` per your physical chassis) and a matching CRC if the EEPROM stores one. Re-install the control board. Boot. Run `get_miner_info` → confirm `chassis_type` reports correctly. Flash the matching firmware via WhatsminerTool. This is the "official" conversion path. Warning: get the offset or CRC wrong and you brick the control board harder than a bad firmware flash — plan for SD-card recovery as fallback.

Control-board swap with matching-chassis spare. If EEPROM re-write is out of scope, swap the control board with a known-good unit whose EEPROM chassis flag matches your physical chassis. D-Central stocks MicroBT control boards for most M-series, often with specific chassis-type flags pre-programmed. Pool settings transfer via MinerTool config restore; worker names / static IPs must be re-entered. Verify `Code 810` clears on the first boot with the new control board.

Cross-reference the model's firmware train history. Some MicroBT models shipped with firmware trains that had a soft EEPROM check (Code 810 was logged but not blocking) followed by hard-check firmware (Code 810 refuses to boot). If you bought a second-hand miner with a soft-check firmware and tried to upgrade to a hard-check build, the EEPROM flag mismatch that was previously invisible suddenly surfaces. Roll back to the soft-check build to restore operation, or fix the EEPROM. Your model's firmware-train release notes on `support.whatsminer.com` will indicate when the hard check landed.

Archive the corrected build locally. Once the miner boots green, archive the full `.bin`, the SHA-256, the MinerTool version used, and any notes on EEPROM flag state. MicroBT occasionally pulls older builds from the public firmware matrix; your local archive is your only rollback option if a future upgrade goes wrong. Treat firmware like configuration: version-controlled, backed up, documented.

Stop DIY when: EEPROM read returns garbage or all zeros (dead EEPROM chip), the control board fails to boot even with SD-card recovery (damaged flash partition or a blown fuse on the control board), the firmware flash repeatedly succeeds but `Code 810` returns on every boot (EEPROM flag is wrong AND the control board is not accepting re-writes), or you are dealing with a hydro chassis that has water damage from a prior leak that may have compromised the control board. [Book a D-Central ASIC Repair slot](https://d-central.tech/services/asic-repair/).

What D-Central does at the bench. EEPROM read on a programmer fixture (CH341A + custom carrier for MicroBT control-board pinouts), chassis-type flag reconciliation per the physical chassis, firmware re-flash with the matching build, full boot verification, 24-hour burn-in at nameplate load before return shipping. If the control board is dead, we swap from our MicroBT spares inventory with a pre-programmed matching flag. Typical turnaround 5-10 business days Canada-wide, US/international welcomed. We also capture and archive the original EEPROM dump in case the board goes bad again — you get the dump back on a thumb drive.

Ship safely. Power down at the PDU, disconnect from the network, remove the miner from its rack. Pull hashboards only if the ticket is a control-board + hashboard combo. Pack the control-board chassis in an anti-static bag if shipped alone, or ship the whole miner double-boxed with ≥ 5 cm foam on every side if you want us to test-in-chassis. Include a note with observed error codes (`810` + any siblings), firmware version (`get_version` output), chassis physical type, whether the miner is first-hand or second-hand, and any prior flash history. The more context in the note, the faster the bench diagnosis, and the lower the invoice.