Whatsminer – Firmware Upgrade Stuck In Progress

Stop touching the miner. If WhatsminerTool's bar has been stuck for less than 15 minutes, do not power-cycle, do not click Cancel, do not open another upgrade session. Set a 25-minute timer from the last bar movement, walk away, come back. Mid-flash patience saves more control boards than every other tip on this page combined. Power-cycling a miner that was 30 seconds from completing its verification phase is the most expensive mistake you can make on a stuck upgrade.

Switch from wifi to wired ethernet for the upgrade. ~40% of stuck-upgrade tickets trace to network drops during the transfer phase. WhatsminerTool was on a laptop on wifi, the AP roamed, the TCP session broke, BTMiner is now waiting on bytes that will never arrive. After recovery, redo the upgrade from a wired ethernet connection on the same subnet as the miner. If you must use wifi, sit within 3 m of the AP and confirm signal strength > -55 dBm before clicking Upgrade.

Verify the `.bin` matches your exact model + cooling variant before flashing. Open `support.whatsminer.com` → Firmware → your exact model. Download the `.bin` whose filename contains your specific cooling tag (`_air`, `_hydro`, `_immersion`). Verify SHA-256 if MicroBT publishes a hash. Do not assume that 'M50 firmware' works on M50S, M50S+, M50S++ — they are different builds with different hashboard counts and chip generations. Wrong `.bin` is the leading cause of mid-flash stalls and post-flash `Code 810`.

Stage the upgrade during a stable power window. Mid-evening on a residential 120 V circuit during peak load is the worst time. Line-voltage sag during the upgrade can drop the control-board rail enough to corrupt a flash write. Schedule upgrades for low-load hours (early morning) or after you've verified your circuit is on a UPS. A $150 small UPS in front of the control board is the cheapest insurance you'll buy for a fleet operator.

Pull `get_version` and confirm the upgrade actually completed before declaring success. WhatsminerTool reporting '100% Success' doesn't always mean the new firmware is running — sometimes the report is for the staging phase and the boot side later silently failed. After every upgrade, query `get_version` from the API and confirm the string matches the version you intended to flash. Don't trust the dashboard alone.

Run SD-card bootloader recovery on a post-erase stall. Download the MicroBT SD recovery image for your exact model from `support.whatsminer.com` → Firmware → SD Recovery. Write to a 4-8 GB microSD with Balena Etcher. Locate the SD slot on the control board (side-edge slot on M30S/M50S; behind the top cover on M60/M66). Insert label-side per the teardown reference. Power on. The bootloader boots the SD image, re-initializes the control-board flash partition, and writes a clean baseline firmware. Wait 4-8 minutes. Remove the SD card after first clean boot, reboot, and re-flash the correct production `.bin` via WhatsminerTool over wired ethernet.

Clean up firmware partitions before retrying on older boards. If Tier 1 retries keep stalling at 75-95% on an M30S/M31S/M32 with > 18 months of service, you may be hitting partition-full. SSH in, check `df -h /` and `df -h /var`. Rotate and delete old `messages.*.gz` logs in `/var/log` with caution. Clear `/tmp` of anything older than 24 hours. Reboot, retry the upgrade. This buys you the headroom for the next flash.

Capture the upgrade log on retry for diagnostic value. Before the next upgrade attempt, SSH in and `tail -f /var/log/messages` in a second window. Start the upgrade. Watch the lines stream by — `flash erase begin`, `flash erase complete`, `flash write block X/Y`, `verify start`, `verify complete`. The exact line where streaming stops tells you which phase failed and informs the recovery decision better than any progress bar. Save the log to your maintenance archive.

Try a known-good `.bin` from your local archive. If the upgrade keeps stalling on the latest MicroBT release for your model, fall back to your last-known-good `.bin` from the archive. Specific MicroBT firmware trains have shipped with upgrade-state-machine bugs that the next dot-release silently fixed; a stuck upgrade on `V202405.x` may flash cleanly on `V202404.x`. Once stable on the older build, monitor MicroBT release notes for a fixed-upgrade-hang line before retrying the newer version.

If WhatsminerTool refuses to retry with `device busy`, reboot WhatsminerTool itself. Close the application fully (check Task Manager / `ps aux` and kill any lingering process). Re-launch. The session-state cache occasionally wedges client-side and refuses to acknowledge the miner is ready for a fresh attempt. A clean WhatsminerTool restart resolves this in ~10 seconds without touching the miner.

Manual `.bin` flash via SSH if the WhatsminerTool path is permanently broken. On many BTMiner trains, the upgrade utility is a wrapper around `flash_eraseall` + `dd` to a known partition device. SSH in, `scp` the `.bin` to `/tmp`, and invoke the underlying utility manually (`/usr/sbin/upgrade_firmware /tmp/upgrade.bin` on most M-series, but verify the exact path on your firmware train). This bypasses any WhatsminerTool client-side bugs. You're now writing flash with no progress bar and no easy abort — confirm you have an SD recovery card on hand before pressing Enter.

Read partition layout and identify the active vs standby slots. On M50S+ and newer with dual-bank flash, the bootloader maintains two firmware partitions (`A` and `B`) and a flag indicating which is active. Stuck upgrades sometimes leave the flag in an indeterminate state — both banks marked invalid, or flag CRC corrupted. Reading the partition layout via `cat /proc/mtd` and the flag via the bootloader-exposed control file tells you whether you can swap the active flag back to a known-good bank without re-flashing. Bootloader-class work — get it wrong and the miner won't POST.

EEPROM-side check after recovery. Some stuck-upgrade scenarios corrupt not just the firmware partition but adjacent config bits in EEPROM — pool credentials, MAC address, chassis-type flag. After SD recovery + firmware re-flash, run `get_miner_info` and confirm `mac`, `chassis_type`, and serial number all read sane values. If MAC is blank or chassis_type is wrong, you have an EEPROM problem on top of the upgrade problem — Tier 4.

Bisect on firmware trains if the stall reproduces across multiple miners. If you have a fleet and the same upgrade reproducibly stalls on three+ identical miners, you have a bad firmware build, not bad miners. File a ticket with MicroBT (include WhatsminerTool version, miner model, chassis variant, firmware version old + new, and the exact stall percentage), roll the fleet back to the prior known-good build, and wait for MicroBT's next dot-release. Don't keep retrying — you'll eventually hit the post-erase brick on one of them.

Archive a post-mortem record for every stuck upgrade. Even if recovery succeeds, capture: WhatsminerTool version, source `.bin` (filename + SHA-256), network path (wifi/ethernet/cellular), stall percentage, miner model + serial + age, recovery path used, final working firmware version. Five minutes of documentation per incident builds an institutional memory that makes the next stall a 20-minute fix instead of a 3-hour panic.

Stop DIY when SD-card bootloader recovery does not bring the miner back (likely damaged flash partition, bad bootloader, or hardware fault on the control board); EEPROM-side corruption is suspected (MAC blank, serial blank, chassis_type missing); the same miner has had three+ stuck upgrades in a row (control-board wear or marginal flash chip); or you're staring at a fleet-wide reproducible stall. [Book a D-Central ASIC Repair slot](https://d-central.tech/services/asic-repair/).

What D-Central does at the bench: pull the control board, dump the full flash on a programmer fixture (CH341A class for serial flash; JTAG for newer ARM-side eMMC), inspect the partition layout for damage, repair or rewrite the bootloader if needed, restore the firmware partition with the correct `.bin` for the model + chassis flag, verify EEPROM integrity (MAC, serial, chassis_type), and run a 24-hour burn-in at nameplate load. If the control board is dead beyond recovery, swap from MicroBT spares inventory with the pre-programmed matching chassis flag. Typical turnaround 5-10 business days.

Ship safely. Power down at the PDU. Disconnect from network. Pull the miner from the rack. For a control-board-only ticket, anti-static bag the control board and ship in a small padded box. For a full-miner ticket, double-box the chassis with ≥ 5 cm foam on every side. Include a note with: observed stall percentage, WhatsminerTool version, source `.bin` filename, prior recovery attempts, model + chassis variant + serial. The more context, the faster the bench diagnosis, and the lower the invoice.