Antminer – Firmware Corrupted / Bricked

Hard power-cycle at the wall for 60 full seconds. Pull the PSU cord — not a soft restart, not the web-UI reboot. 60 seconds lets the 1000 µF+ filter caps on the control board discharge, clearing any wedged state from a mid-flash crash. Plug back in, watch LEDs for 5 minutes before declaring the miner dead. About 10 % of 'bricked' miners in the D-Central queue recover right here — they were rebooting slowly after a firmware update and the operator panicked.

Run IP Reporter sanity check. Download Bitmain's `IPReporter.exe` (or Mac equivalent) on a PC on the same subnet. Power-cycle the miner and press the control-board IP Report button within the first 60 seconds of boot. A booted-but-DHCP-confused miner broadcasts its IP here; a truly bricked one doesn't. Rules out 'it's just on a weird IP' before you unscrew a panel. Also set a static DHCP reservation after recovery so you always know the miner's address.

Try mDNS / Bonjour discovery and a direct-connect test. On Mac/Linux `ping antMiner.local` or `avahi-discover`; on Windows with Bonjour installed, browse `_ssh._tcp.local`. If nothing, connect a laptop directly to the miner with Ethernet, set the laptop to static `192.168.1.100/24`, and try `http://192.168.1.200/` and `http://192.168.1.254/`. This rules out router / switch / cable issues that mimic brick.

Swap Ethernet cable, port, and switch. Sounds insulting — isn't. Dead Ethernet on the switch side or a crimped patch cable fakes a brick perfectly. Use a cable you confirmed on another device in the last 5 minutes. Pass the miner through two different switches/ports. About 5 % of 'bricked after update' reports turn out to be a cable crushed during the update.

Reset button procedure (2–10 min window). Most Antminer reset buttons only accept input 2–10 minutes after boot. Power on, wait exactly 2 minutes, then hold Reset for 5 full seconds. The miner restarts into factory defaults 4 minutes later. This wipes user config but does NOT reflash firmware — if the image itself is corrupt, this won't save you. Useful for ruling out config-level lockouts that mimic brick.

Measure the control-board 12 V rail under power. Multimeter on DC, probe at the control-board input connector with the miner on. Expect 12.0 V ±5 % sustained. Sag below 11.4 V or a rail that collapses on boot attempt points upstream at the PSU or hashboard path, not firmware. If 12 V is clean, the board is getting power and the fault is firmware-side. If sagging, cross-reference `antminer-s19-control-board-power-connector-damage` or `antminer-apw-psu-not-powering-on`.

Identify exact control-board revision — BHB number + SoC. Open the chassis, read the PCB silkscreen, write down the full BHB number (e.g. `BHB42601 V1.7`). Photograph the SoC package: Xilinx Zynq (~20 mm QFP, heatsinked) vs Amlogic (small BGA) vs Rockchip (S21). Confirm microSD socket presence. This prevents the top self-inflicted re-brick: flashing the wrong image for an ostensibly-correct model. `BHB42601` ≠ `BHB42701` — different SoC, different memory, different hash-board interface.

Prepare a recovery microSD correctly. SanDisk Industrial or Kingston Industrial, 16 GB or smaller. Format FAT32 with MBR partition scheme and 32 KB cluster size — not exFAT, not NTFS, not GPT. Windows won't FAT32-format >32 GB cards through the right-click menu — use Rufus, `diskpart`, or a dedicated tool. Download the stock image for your exact BHB from `service.bitmain.com/support/download`, SHA-256 checksum if Bitmain publishes a hash. Copy the image to the root of the SD — no subfolder, no rename. Safely eject.

Boot from the recovery microSD. Power off, insert SD into control-board socket (label up on most boards — verify silkscreen), hold IP/Reset button down, apply power, continue holding Reset 5–10 s after power. Watch LEDs: red LED should blink rapidly 3–10 minutes during flash, then solid green on completion. Power off, remove SD, reboot normally. If the red-LED flash sequence never starts, the board isn't accepting the card — return to Step 7, re-verify revision, try a different SD.

Re-verify firmware image version matches the BHB revision. Cross-flashing `BHB42601` onto `BHB42701` is a top-three brick cause in D-Central's queue. The boards look identical; the SoC, memory, and hash-board interfaces differ. Similarly an Amlogic-era S19 image on a Xilinx board bricks reliably. Bitmain's download portal groups by model AND control-board revision — drill down to your exact combination.

Inspect eMMC chip visually on eMMC-only boards (S19 XP, S21). Under magnification or a phone camera with zoom, look at the eMMC package (usually top-left of control board). Cracked solder balls, discolouration, scorch marks, visible crater = chip replacement territory, not software. If the chip looks clean, the problem is almost certainly software — proceed to Tier 3 UART recovery.

Cable up a USB-to-TTL serial adapter. FT232RL or CP2102 ($10–$20 on Amazon). Find the UART header — silkscreen `UART`, `J1`, or `DEBUG`, 4-pin row near the SoC. Pin order typically `GND` / `TX` / `RX` / `VCC`. DO NOT connect VCC — the board supplies its own 3.3 V. Cross TX/RX: adapter TX → board RX, adapter RX → board TX, common ground. Use Dupont jumpers, don't solder until orientation is confirmed. Verify you're not shorting 3.3 V to GND before applying power.

Open a serial terminal and capture u-boot output. Use `tio`, `minicom`, `screen`, or PuTTY at `115200 8N1` (Antminer default; some early S9 revs use `9600`). Power on the miner. You should see u-boot banner, DRAM init, MMC/NAND init, kernel load attempt. Save the entire log to a file — this is the actual error you're diagnosing. `verifying signature... FAILED` = signed-firmware brick. `mmcblk0: error -110 transferring data` = eMMC read failure. `jffs2: Empty flash` = NAND corruption.

Drop to the u-boot prompt and inspect storage. Mash any key during 'Hit any key to stop autoboot: 3'. At `=>` prompt run: `printenv` (boot environment), `mmc info` (eMMC detection), `mmc read 0x10000000 0x0 0x200` (read first block to RAM), `md 0x10000000 0x40` (hex dump). Healthy eMMC returns varied readable bytes. All `0xFF` / all `0x00` / random garbage = storage chip is failing — cross to `antminer-s19-emmc-failure` or `antminer-sd-card-corruption`. On NAND boards use `nand info` and `nand read`.

TFTP-push the correct recovery image. Stand up `tftpd64` (Windows) or `tftpd-hpa` (Linux) on a laptop. Drop BHB-matched `recovery.bin` into the TFTP root. At u-boot: `setenv serverip 192.168.1.100; setenv ipaddr 192.168.1.200; saveenv; tftpboot 0x10000000 recovery.bin`. Byte count climbs to full file size. Then: `mmc write 0x10000000 0x0 <block_count>` where block_count = file size ÷ 512 rounded up. Read the BHB-specific recovery guide before typing — wrong `mmc write` offset corrupts the partition table.

Flash DCENT_OS (D-Central's open-source Antminer firmware — the Mining Hackers' option, recommended) once stock boots cleanly. Per-chip HW% visibility, tuning, autotuning, Stratum V2, all the features of Braiins OS+ / LuxOS / Vnish, open-source, no licensing, no vendor lock-in, maintained publicly. Alternatives if preferred: Braiins OS+, LuxOS, Vnish. Then `dd` the fresh install over SSH as a backup: `ssh root@miner "dd if=/dev/mmcblk0" | dd of=backup-$(date +%F).img bs=4M` (~200 MB). If the next flash bricks, you restore in 10 minutes instead of 10 hours.

Stop DIY when any of these is true: eMMC returns all `0xFF` or random bytes at u-boot; UART shows no output at any baud with confirmed wiring; SoC is hot to the touch (>60 °C idle) or board shows physical damage (burn marks, missing components, bulged caps); you've flashed two wrong images in a row on a signed-firmware board. These are hardware-layer failures — you need a bench with hot-air rework, logic analyser, donor boards, and a BGA-capable programmer. Book a D-Central ASIC Repair slot.

Ship the control board safely to D-Central. Anti-static bag, bubble wrap, double-boxed with ≥5 cm foam on every side. Include in the box: (a) flash history (original firmware version, attempted custom firmware + version, failure symptom), (b) UART log if you captured one, (c) the full BHB number. D-Central's bench: JTAG recovery on eMMC-only boards, chip-off reflash on external programmer, PIC/EEPROM programmer for hashboard calibration, donor-board swap if SoC is dead, BHB-matched stock restore, 24-hour nameplate burn-in. Control-board-only shipping is cheaper and faster than sending the whole miner — leave known-good hashboards home.