Whatsminer Error 800-802 – Firmware Checksum Error

Hard power-cycle at the PDU for a full 60 seconds. Not a MinerTool soft reboot — physical AC cut at the breaker or PDU outlet. Wait the full minute so bulk caps drain. Restore power and watch the first 120 seconds of the boot sequence. A half-written OTA after a brownout can leave the active partition in an inconsistent state that a true cold start recovers from — the bootloader falls back to the backup partition (on M50-class and later) and the miner comes up clean. Clears roughly 10% of `800` tickets with zero tools and zero risk. Count the 60 seconds.

Capture the state before touching anything. Web UI screenshot of the `800` banner. SSH if you can (`root` / sticker password) and run `cat /etc/btminer_version > /tmp/baseline.txt`, `dmesg >> /tmp/baseline.txt`, `cat /proc/mtd >> /tmp/baseline.txt`. If SSH is locked, hit the API: `echo -n '{"cmd":"get_version"}' | nc <miner-ip> 4028` and `{"cmd":"get_error_code"}`. Save everything to a single `<serial>-baseline-<date>.txt`. D-Central's bench asks for this artifact first on every ship-in; producing it yourself shortens every step after this one.

Check the peers on the same LAN. Any other miner flagging `800` right now? Did you run a fleet firmware push in the last 24-48 hours? If yes, it's a failed-push problem — every flagged miner needs individual recovery; don't waste time waiting for a group reboot to fix it. If you're the only `800` on the LAN, the cause is local and you work the miner on its own.

Try a factory reset via the control-board button before anything destructive. Hold the reset button for `5` seconds until the LED flashes fast. This clears pool config, network config, cached error state — but does not rewrite the firmware image. If `800` clears, the underlying issue was the config partition (unusual for `800` specifically, but it happens when the config partition and image partition share eMMC blocks and both got hit). If `800` persists after factory reset, the corruption is in the image itself — continue to Tier 2.

Download the correct firmware. `support.whatsminer.com` → find your exact model, exact hardware revision if prompted, exact cool mode. Air-cooled firmware on an air-cooled board. Hydro firmware on a hydro board. *Never* mix. Archive the downloaded `.bin` into a repair-images folder on your workstation so you have a known-good copy for the next time.

Verify the download. `sha256sum <file>.bin` on Linux / macOS; `certutil -hashfile <file>.bin SHA256` on Windows. Compare against the SHA-256 published on the support page. Match? Proceed. Mismatch? Re-download — ideally from a different network. A silently-corrupted download is a direct cause of `Code 800`; skipping this step is how half the `800` tickets on D-Central's Whatsminer bench got there.

Flash with WhatsminerTool via the network. Latest MinerTool from `support.whatsminer.com/en-US/article/481`. Add the miner by IP, select the verified `.bin`, click "Firmware Upgrade." Do not disconnect ethernet, do not close MinerTool, do not touch the PDU. Flash takes 2-5 minutes. Miner reboots twice automatically. Wait 5 full minutes after the second reboot, then re-check the error state. Clean boot, `Mining` status, hashrate climbing? Fixed — monitor for 48 hours to confirm. `800` still there? Move to Tier 3.

Verify your local ethernet is reliable before assuming the flash failed. A flaky cable or an oversubscribed switch can drop packets mid-flash and produce a failed image. Swap the patch cable, run the miner into a known-good switch port, try a second reflash. Rare but real — and free to rule out before opening the chassis.

Prepare an SD-card recovery image. `support.whatsminer.com` → SD-recovery section → match your model + rev + cool mode. This is a *different* file from the standard OTA `.bin` — it includes the bootloader plus rootfs and is designed to be burned to microSD. Burn with balenaEtcher (cross-platform) or Rufus (Windows). Use a fresh 4-16 GB microSD from a reliable brand; no-name cards fail during the write-back phase and make the problem worse.

Boot from SD. Power the miner off at the PDU. Open the control-board side cover (Phillips or Torx depending on generation). Locate the microSD slot on the control board. Insert the burned card fully. Power on at the PDU. The board boots from SD, re-flashes the on-board eMMC from the SD image, and automatically reboots into the newly-written firmware. Total time 10-15 minutes. Remove the SD card after the first successful boot and store it — it's your recovery tool for next time, so label it with model + firmware version + date.

If SD-recovery fails to boot, try a second SD card from a different brand. The SD-burn itself can silently fail on marginal cards. Also re-verify you have the right recovery image for the hardware — an M30S SD-recovery image on an M30S+ control board won't boot; an air-cooled image on a hydro board won't boot. Mismatch produces failed-boot symptoms that look like a dead control board but are actually an image-hardware mismatch.

Open the USB serial console on M60S / M63 / M66 generation. Type-C USB port on the control board (or 4-pin UART header on earliest M60S batches). Plug into your workstation, open a terminal at `115200 8N1` (PuTTY, screen, minicom). Reboot the miner, watch U-Boot scroll. Error strings to look for: `Bad CRC32 for image`, `Image integrity check failed`, `Unable to load FIT image`, `mmc read fail`. From U-Boot you can invoke the SD-recovery flow manually (`run recovery`), dump the image header (`md.b`), and force-boot from a TFTP server on a static IP for maximum control. Bench-tier recovery — saves hashboards that blind SD-flash can't.

Check the eMMC wear counters (M50 / M60 generation where supported). SSH in if you can (`root` / sticker). Run `cat /sys/block/mmcblk0/device/life_time` and `cat /sys/block/mmcblk0/device/pre_eol_info`. A `pre_eol_info` of `0x02` or higher means the flash is nearing end-of-life — the cause of your `800` is physical wear, and the control board needs replacement regardless of how many times you reflash. Not all firmware versions expose these counters; the ones that do give you a hard answer in 10 seconds.

Book a D-Central ASIC Repair slot at `https://d-central.tech/services/asic-repair/` when any of these is true: SD-recovery completes but `800` returns within 24-48 hours (eMMC wear — control board needs replacement); SD-recovery fails with a good card on a verified image (control board is dead at the flash controller or eMMC level); U-Boot console shows hardware init failures beyond just image corruption; signature / key-rotation errors on M60S+ / M66 that the public firmware won't resolve; or you simply don't have the bench gear (card burner, USB serial, preheater) and want a known-good miner back in production. Typical CAD turnaround 5-10 business days from Canada / US / international.

D-Central bench process on a `Code 800` case: capture U-Boot console output over UART, inspect the eMMC partition headers directly, attempt SD-recovery with a matched image, and if that fails, swap the control board from graded inventory (MicroBT control boards for M30S / M50S / M60S are stocked for same-week turnaround). On persistent eMMC-wear cases we'll pull the eMMC chip, re-program via a socket programmer, and re-solder — but at that cost point a control-board swap is usually the better economic call. Every ship-in gets 24-hour burn-in at nameplate before return.

Ship safely. If it's just the control board you're sending, anti-static bag, bubble-wrap, double-box with 3 cm foam minimum on every side. If you're sending the whole miner, remove hashboards and pack them separately; a hashboard flexing in transit cracks solder joints we didn't ship to repair. Include a note inside the box with: observed error code(s), firmware version(s) attempted, whether SD-recovery has been tried, whether `800` returned after a successful reflash, and any LED patterns you observed. The note directly shortens bench time — which directly lowers your invoice.

Retirement vs repair economics for older M20S / M30S / M31S hardware. On these generations, a control-board replacement cost can approach the current refurb market value of the entire miner. If the hashboards are still healthy, retiring the chassis and moving the hashboards into a refurbished control-board miner (or harvesting parts into D-Central's R&D stream) often beats paying for a like-for-like repair. We'll tell you honestly at quote time — the Mining Hacker answer is usually "keep it hashing as cheaply as possible," and sometimes that's retirement.

Prevent the next `800`. Ship-in or not, the habits below keep you out of this fault class long-term. Run them on every miner in your fleet, not just the one that just broke.