Bitaxe – Wrong Firmware .bin Flashed for Chip (1366 vs 1370)

Identify your exact board revision before touching the Web Flasher. Flip the Bitaxe over, read the silkscreen: `201`, `202`, `204`, `205`, `207` (Ultra); `401` (Supra); `600`, `601`, `602` (Gamma); `800` (Gamma Turbo / GT); `v303`, `v304` (Hex). Photograph it. If the silkscreen is illegible, read the ASIC part marking on the chip itself: `BM1366` = Ultra / Hex family, `BM1368` = Supra, `BM1370` = Gamma family, `BM1397` = Max (legacy). Cross-fork devices (NerdAxe, NerdQAxe++, Nerdminer v2) use different codebases entirely and are NOT covered by the stock Bitaxe Web Flasher. Accurate identification prevents repeated mistakes.

Connect only USB-C to a PC — no main PSU. Disconnect the barrel / XT30 / USB-C main power cable. Plug a good-quality USB-C data cable (many charging-only cables lack D+/D-) from PC to Bitaxe. The ESP32-S3 takes USB bus power for bootloader access, so you do not need main power to flash. Confirm Device Manager, `lsusb`, or `dmesg` shows a new `USB JTAG/serial debug unit` or `ESP32-S3` device (VID `0x303A`). If it does not appear, hold `BOOT` on the board, tap `RESET`, release `BOOT` to force the mask-ROM bootloader.

Open the Bitaxe Web Flasher in Chrome or Edge. Navigate to `bitaxeorg.github.io/bitaxe-web-flasher/`. The tool requires WebSerial — Chrome, Chromium, Edge, Brave work; Firefox and Safari do not. Accept the permission prompt, pick your serial port from the browser's chooser. The dropdown shows supported board revisions by NAME, not just variant. Select the EXACT revision matching your silkscreen. Hex owners: pick `multichip` image matching `v303` or `v304`. Turbo / GT owners: pick `800`. Do not guess — cost of picking wrong from a dropdown is the same cost that got you to this page.

Click Flash and wait the full 30 - 60 seconds without interruption. The tool erases the entire flash region (application partition, NVS partition, OTA partitions), writes the factory image, verifies the checksum, and reboots the ESP32-S3. Do not unplug, do not close the tab, do not let Windows decide to sleep the USB hub mid-flash. Losing power during the write lands you in a genuinely bricked state that needs the Tier 3 recovery procedure. A full successful flash shows progress to 100%, a `Done` banner, and typically a brief serial-console reboot banner.

Reconnect main PSU to a verified-good outlet and watch for recovery. Unplug USB-C. Reconnect main power — Ultra / Supra / Gamma: regulated `5 V / 3 A`. Hex: regulated `12 V / 5 A`. Turbo / GT: `5 V / 6 A` minimum. Watch for: OLED splash with `BITAXE` / `AxeOS` logo within `~3 s`, Wi-Fi AP `bitaxe_xxxx` on your phone within `~15 s`, and cold-boot LEDs. Connect to the AP, complete first-boot wizard, configure Wi-Fi, pool, and stock frequency / voltage. Factory flash wiped NVS, so re-entering config is expected and normal.

Validate `count_asic_chips` on the AxeOS status page. Once AxeOS is up and on Wi-Fi, open status. Confirm `count_asic_chips` matches expected: `1` on Ultra / Supra / Gamma / Max; `2` on Gamma Turbo / GT; `6` on Hex; `4` on NerdQAxe++ (if cross-flashed, would use NerdQAxe++ fork). Wrong count = still a mismatch — picked the wrong image in dropdown. Repeat Step 3 more carefully. `count_asic_chips` is the single most reliable post-flash sanity check.

Burn-in under full load for 30 minutes before returning to production. Ramp to stock frequency and voltage in AxeOS. Watch for: stable `Vin`, HW% `< 1%`, no spurious `Power Fault Detected`, ASIC temperature stabilized. A 30-minute burn-in catches any pre-existing hardware fault previously masked by the wrong firmware's non-functionality (e.g. a marginal TPS546 that never had a chance to fault because the board wasn't actually drawing Vcore). If everything looks clean, reconfigure pool / worker / frequency preferences and return to normal operation.

Attach a USB serial terminal at `115200 baud` for live flash verification. Use PuTTY (Windows), `screen /dev/ttyACM0 115200` (Linux), or Arduino Serial Monitor. Reset the board after a Web Flasher flash and watch the cold-boot banner. Correct flash: `ESP-Miner v2.x.y` / `Board: 602` / `ASIC: BM1370` / `count_asic_chips = 1` in first few seconds. Still-mismatched flash: `BM1370 timeout` or `EMC2101 read fail`. Live view confirms the flash took and the image matches before re-plugging main PSU. Useful when AxeOS web UI gives ambiguous status.

Use `esptool.py` directly for stubborn cases or corrupt partition tables. If the Web Flasher consistently fails or reports checksum errors, drop to the command line. `pip install esptool`. Then: `esptool.py --chip esp32s3 --port COMx --baud 921600 erase_flash` to wipe completely. Then `esptool.py --chip esp32s3 --port COMx --baud 921600 write_flash 0x0 esp-miner-factory-602.bin` substituting your correct image filename. This bypasses any browser / WebSerial quirks and gives verbose error output (timeout, bad checksum, MD5 mismatch). Espressif's toolchain is the reference implementation; the Web Flasher wraps it.

Verify image authenticity before flashing if the `.bin` came from anywhere other than `bitaxeorg`. Tampered firmware for open-source miners has been spotted in Discord link drops and random GitHub mirrors. If the `.bin` did NOT come from `github.com/bitaxeorg` (stock Bitaxe), `github.com/shufps/ESP-Miner-NerdQAxePlus` (NerdQAxe++), or `github.com/BitMaker-hub` (Nerd family), don't flash it. The Web Flasher pulls vetted builds from official org repos. Checksum-verify any locally-saved `.bin` against the release page before flashing if paranoid. Community best practice; no confirmed in-the-wild Bitaxe malware as of 2026-04.

Handle swarm / multi-unit flashing carefully. If you run 4+ Bitaxes in a swarm, do NOT batch-flash the same `.bin` across mixed revisions. Each board's revision dictates its correct factory image. Many home miners own `2 x Ultra` + `1 x Gamma` + `1 x Hex` and flash Gamma firmware to every unit 'to match' — bricks three of four. Flash each board individually with its matching image, then re-form the swarm from AxeOS. Swarm firmware compatibility across revisions is a known issue (see bitaxeorg/ESP-Miner issue #1658, v2.14.0b1), so after mass re-flash, verify swarm functionality explicitly.

Erase NVS and force clean first-boot if selftest loops persist after a clean factory flash. If the board flashes successfully but immediately enters a selftest loop (known on some Supra `401` boards pre-v2.1.4, and Ultra `205 / 207` boards on v2.12.2+), a stale NVS entry may be triggering selftest failure. Use `esptool.py --chip esp32s3 erase_region 0x9000 0x6000` to wipe NVS only, preserving the application image. Then cold boot. First boot will enter wizard mode fresh. Saves a full reflash in cases where only NVS is the problem.

Hold `BOOT` to skip selftest on boards with known-bad selftest firmware. On Supra `401` + `v2.1.2 / v2.1.3` and Ultra `205 / 207` + `v2.12.2+`, holding `BOOT` during cold boot can bypass selftest long enough to reach AxeOS and update firmware to a version with a better selftest implementation. See the NVS-skip-selftest procedure in bitaxeorg/ESP-Miner Issue #516. Workaround, not a fix — follow up with firmware update to a build where selftest no longer fails on known-good hardware.

Recover from a genuinely bricked state (power-loss mid-flash). If the Web Flasher crashed, Windows ate the USB port mid-write, or the PC slept during flash, the application partition may be corrupted AND the bootloader may fail to hand off. Hold `BOOT`, connect USB-C, tap `RESET`, release `BOOT` — forces mask-ROM bootloader regardless of flash state. Mask-ROM is immutable silicon; no flash event can damage it. PC will enumerate the ESP32-S3 JTAG/serial device. Then `esptool.py erase_flash` (wipe), then `esptool.py write_flash 0x0 esp-miner-factory-XXX.bin` (rewrite). Canonical unbrick procedure — Solo Satoshi's guide has screenshots.

Cross-fork recovery: mistake-flashed a NerdQAxe++ image onto a stock Bitaxe (or vice-versa). Same procedure as any other wrong-image: ROM-bootloader recovery, `esptool.py erase_flash`, then flash the correct fork's factory image. Stock Bitaxe: use the Bitaxe Web Flasher. NerdQAxe++: use shufps/ESP-Miner-NerdQAxePlus releases. NerdAxe: use BitMaker-hub/ESP-Miner-NerdAxe releases. Nerdminer v2 (different hardware — ESP32 + LCD, not an ASIC miner): use NerdMiner_v2 repo. No hardware damage; only flash contents need correcting.

Flash custom community builds with extra care. Some experienced home miners run custom ESP-Miner branches with modified selftest, custom pools, adjusted voltage curves. These are typically source-built and MORE revision-specific than stock factory builds. Always read the fork's README for supported revisions, build with correct `CONFIG_MINER_BOARD` flag, keep a stock factory `.bin` on workbench for rollback. If a custom flash bricks the board, Step 14 unbricks it. Custom build wrong-config flashes are a well-known pit — always verify build parameters.

Stop DIY if the ESP32-S3 refuses to enter ROM bootloader even with `BOOT` + `RESET`. A physically-alive ESP32-S3 always responds to the forced-bootloader sequence — that is the entire point of the mask-ROM. If holding `BOOT` and tapping `RESET` does not produce USB enumeration on the host PC, the MCU itself has failed: surge damage, ESD event, QFN solder-joint fracture, or (rare) a genuine MCU die failure. This is NOT a wrong-`.bin` problem anymore; it crossed into hardware fault territory. Ship to D-Central.

Stop DIY if repeated correct-image flashes still produce `count_asic_chips = 0` on a known-good board revision. If you've confirmed the image, confirmed the revision, flashed three times cleanly, and the ASIC still won't enumerate — the wrong-`.bin` event may have masked a pre-existing ASIC fault (cracked BGA joint, thermal-cycled solder fatigue, or BM1366 die-level damage). At this point you're in the same triage as ASIC-Not-Responding. Ship to D-Central for hot-air reflow or chip-level replacement.

Ship to D-Central with the exact flash history. Pack the Bitaxe in anti-static, include the main PSU, and write out what `.bin` files you flashed in what order — the log narrows bench diagnosis quickly. D-Central's bench handles full flash-level forensics, mask-ROM recovery, and BGA rework when needed. Canada-wide shipping; US / international welcomed. Turnaround `5 - 10` business days. D-Central pioneered the Bitaxe ecosystem — original Mesh Stand, first heatsinks, schematic-level references for every factory image and every revision.

Consider the economics before committing to a full repair or replacement. A wrong-`.bin` recovery at D-Central bench is typically `CAD $35 - $85` — essentially labour for a 20-minute bench procedure with 30-minute burn-in. Full Ultra replacement: `CAD $130 - $180`. Hex replacement: `CAD $220 - $320`. If the flash event also revealed hardware damage, quote rises accordingly. We'll be honest with you — a three-minute Tier-1 flash you do yourself is always cheaper than shipping. Bench only makes sense when DIY has hit a wall.