Bitaxe – ASIC Chip Not Detected / System Info Shows None
Critical — Immediate action required
Symptoms
- AxeOS dashboard loads and is reachable, but System Info -> ASIC Model reads none, unknown, blank, or 0
- Hashrate reads 0 GH/s or 0.00 GH/s indefinitely; no shares ever submitted to the pool
- Serial console at 115200 baud over USB-C shows ASIC_init failed, Chip count: 0, or BM1366/BM1368/BM1370 init: no response
- OLED displays splash and basic status but never transitions to mining/hashing state
- Vin in AxeOS reads clean (5.0 V on Ultra/Supra/Gamma, 12.0 V on Hex/GT) - the input rail is not the immediate problem
- Vcore reads 0 V, or reads a value but fluctuates wildly, or reads a plausible 1.0-1.35 V yet the chip still does not respond
- Bitaxe was recently moved, bumped, or had its heatsink remounted right before the symptom appeared
- Wrong firmware image was flashed (Gamma image on an Ultra, BM1366 image on a BM1370 board) - even once; symptom can persist after re-flashing until full factory-reset
- Hex-specific: Chip count returns 1-5 instead of 6 (partial detection, daisy-chain break)
- GT-specific: only one of two BM1370 chips detects (Chip count: 1 instead of 2)
- Board is new-out-of-box and has never hashed - classic factory QA escape, often a cold solder joint under the ASIC BGA
- Board was hashing fine, then stopped after a power event, a drop, a transport bump, or a heatsink retightening
- i2c_master_transmit_receive errors in the serial boot log (Gamma 601/602 TPS546 device-ID mismatch signature)
Step-by-Step Fix
Full cold-boot with 60-second discharge. Unplug EVERYTHING - main PSU, USB-C, any fan or accessory cable - and wait a full 60 seconds before re-powering. The TPS546 regulator family on Gamma/GT can latch into a fault state that a soft reboot will not clear, and the ESP32-S3 brownout detector can hold the chain init in a hung state. A true hard-discharge drains the bulk input caps and forces clean init. While waiting, note which PSU you are using - the original Bitaxe-bundled brick, or a random charger from the drawer? That question alone resolves a meaningful fraction of chip_id = none tickets.
Try USB-C only (no main PSU) for bootloader access. Connect a USB-C data cable from a PC to the Bitaxe with NO main PSU attached. The ESP32-S3 is USB-bus-powered for firmware access - this isolates 'is the MCU alive' from 'is the ASIC chain alive'. If the PC enumerates an ESP32-S3 JTAG/serial device (check Device Manager / lsusb / dmesg), the ESP is healthy and the problem is downstream. If not, hold BOOT, tap RESET, release BOOT - this forces the mask-ROM bootloader. Confirms you can reach the MCU for firmware recovery.
Open the serial console and watch the boot log. Same USB-C connection, any serial terminal (screen / minicom / PuTTY / VS Code Serial Monitor) at 115200 baud, 8N1. With terminal open, connect main PSU. Watch init lines: TPS546_init, ASIC_init, Chip count: N. Screenshot or paste the output. The FIRST line that fails or reports 0 is the starting diagnostic clue - and it is the single best piece of information to include in any D-Central / bitaxeorg Discord / OSMU support ticket. Five minutes with a serial terminal saves ten days of guessing.
Swap to a known-good regulated PSU matched to your variant. The single highest-yield fix for chip_id = none. Ultra/Supra/Gamma: 5.0 V / 3 A regulated brick, center-positive USB-C or barrel per variant - NOT a phone charger, NOT a PC USB port, NOT a 5V wall-wart from the drawer. Hex/GT: 12.0 V / 5 A regulated brick, center-positive 5.5 x 2.1 mm barrel or XT30 per revision. Ideal is a D-Central Bitaxe PSU bundle or a name-brand (Mean Well, CUI) unit. Plug in, power-cycle, re-check dashboard. A large fraction of chip_id = none cases resolve here.
Re-flash the correct factory image via Web Flasher. Open bitaxeorg.github.io/bitaxe-web-flasher/ in Chrome or Edge. CRITICAL: select the EXACT image for your variant AND your board revision (printed on PCB silkscreen). Ultra 204/205/207 each have different images; Gamma 601 and 602 have different images; Supra 401 vs 402 differ; Hex v303 vs v304 differ. Wrong image boots AxeOS but mis-handshakes. If uncertain of board revision, read silkscreen under good light - do not guess. Flash, wait for completion, full power-cycle (USB-C AND main PSU unplugged 30 s), reconnect, re-check.
NVS / factory-defaults reset after the re-flash. A previous wrong-image flash can leave stale config in NVS that the correct firmware then reads and gets confused by. After Step 5, in AxeOS: Settings -> Restore Defaults (where the button exists) or via serial nvs_erase / equivalent factory-reset sequence for your AxeOS version (check release notes). Then re-flash the factory image one more time and power-cycle. This belt-and-braces sequence clears the last common recoverable state before moving to hardware diagnostics.
DMM-verify the PSU under load. Open-circuit DMM is not enough - the Bitaxe ASIC init is a transient load. Open-circuit: Ultra 5.0-5.25 V, Hex 12.0-12.6 V. Under 2-5 A load (halogen bulb, USB load tester, electronic load): Ultra >= 4.8 V, Hex >= 11.5 V. If the PSU sags more than 0.3 V under load or oscillates, it is the primary suspect regardless of how it looks open-circuit. Many 'weird' Bitaxe failures trace back to a PSU that tests fine on a DMM but fails under real-world current. Replace before continuing.
DMM-verify Vcore with AxeOS running at idle. Probe the ASIC Vcore test points (silkscreened on most revisions; otherwise reference the bitaxeorg schematic repo) with the board powered and AxeOS running but no work dispatched. Expected: Ultra ~1.25-1.35 V, Supra ~1.20-1.30 V, Gamma ~1.00-1.15 V, Hex ~1.20-1.30 V, GT ~1.00-1.15 V. Vcore = 0 means the regulator is dead (TPS546 on Gamma/GT, discrete LDO on Ultra/Supra/Hex). Vcore out-of-range = regulator damaged but partially working. Vcore correct = power is reaching the chip and the problem is downstream in the UART/handshake. This single measurement narrows the diagnostic tree dramatically.
Inspect heatsink mount and PCB flex. A crooked or overtightened heatsink can mechanically flex the PCB and crack BGA joints under the ASIC. Power off, remove heatsink, inspect: is the thermal pad/paste evenly squeezed? Any visible bend in the PCB when laid flat on a table? Any tint or residue under the heatsink suggesting the chip ran hot at some point? Remount with appropriate thermal paste (Arctic MX-6 or Kryonaut), even pressure, correct screw torque (finger-tight-plus-quarter-turn, NOT cranked). Re-power, re-check. A non-trivial number of chip_id = none failures trace to a heatsink remounted wrong after cleaning.
Swap PSUs with a known-working Bitaxe. Fastest bisection when you own multiple Bitaxes: borrow the PSU from a confirmed-hashing unit, swap to the dead one. If the symptom moves with the PSU, you have found the root cause in five minutes. If the symptom stays with the board, the PSU is fine and the board is the suspect. This is why multi-miner households keep labelled spare PSUs per variant - cheapest diagnostic tool in the shop. Also avoids buying parts for a problem you do not actually have.
Scope Vcore during ASIC init. A cheap 50 MHz handheld scope on the Vcore rail during the ASIC_init window reveals transient sags that a DMM averages out. Healthy: Vcore steps up cleanly to target, holds flat with < 50 mV ripple, stays stable through init. Damaged regulator: Vcore oscillates, overshoots, or sags under init current draw. This is the measurement that distinguishes 'regulator just barely working' from 'regulator fine' - the former kills ASIC handshake while looking healthy on a DMM. Matching scope trace to the serial-log timestamp of ASIC_init pinpoints the exact failure window.
Reflow the BM1366 / BM1368 / BM1370 on single-chip boards. With the heatsink removed and the board on a preheater (~150 C), apply hot air top-side (~310-330 C, moving in small circles over the chip) for ~30 seconds. Do not exceed 3-4 seconds at peak local temp or adjacent caps lift. Cool naturally on the preheater, then to ambient. Retest. Reflow alone recovers a measurable fraction of chip_id = none boards - especially new-out-of-box units where the fault is a factory cold joint. Thermal stress of normal operation gradually worsens cold joints until handshake breaks; reflow re-forms the joint.
Chain-break localization and per-chip reflow on Hex/GT. Hex with Chip count: 1-5 or GT with Chip count: 1: the serial log identifies which chips responded and which did not. The FIRST missing chip in the chain is the physical fault - UART is a daisy chain and breaks at the first dead link. Reflow JUST that chip (shield adjacent chips with aluminium foil to avoid collateral thermal cycling). Retest. If reflow fails, replace only that chip rather than the whole board. Saves a $220+ Hex when the alternative is scrapping it.
TPS546 replacement (Gamma/GT only). If Step 8 showed Vcore = 0 on Gamma/GT and i2c_master_transmit_receive errors in the serial log, the TPS546D24x is the suspect (see ESP-Miner issue #1291 for the D24A vs D24S history across 601 vs 602 boards). Verify the exact part number on silkscreen. Desolder with hot air, clean pads, place the correct replacement, reflow down. Verify with DMM diode-check before powering. Tier 3 if you have hot-air + QFN rework skill; otherwise Tier 4. Re-flash factory image after the swap before full-load testing.
Discrete LDO replacement (Ultra/Supra/Hex). If Step 8 showed Vcore = 0 on Ultra/Supra/Hex, the discrete 5 V -> Vcore LDO is the suspect. Identify the part from silkscreen/schematic - typically SOT-223 or SOIC package near the main rail. Hot-air desolder, clean pads, place replacement of matching spec (watch drop-out voltage and current rating). Re-test rail with DMM before powering the full board. Pick up cheaply via Digi-Key / LCSC / Mouser once you have the part number. Always re-flash factory image after any rail work.
Re-flash factory image after ANY Tier-3 rework. Hot-air work can briefly raise SPI flash temperature and corrupt data silently. After any chip-level rework, re-flash the factory image via Web Flasher BEFORE full-load validation. Verify the dashboard reports the correct ASIC model and chip count before declaring the repair complete. Common failure mode: the hardware repair is good, but leftover rework-induced flash corruption makes it look like the repair did not take. Always re-flash; always verify chip count.
Stop DIY on BGA rework without preheater + controlled-temperature hot-air station + rework microscope. A BM1366/1368/1370 is a BGA package (ball-grid array under the die). Iron-only rework is not a path. Without a preheater, the thermal gradient rips pads off the board. Without a microscope, alignment is guesswork and bridges are guaranteed. Ship the board to D-Central. Our bench has the full rework stack, chip inventory, and bench history on hundreds of Bitaxe repairs. The board is worth saving; the ESP32-S3, OLED, EMC2101, connectors, and PCB are all reusable.
Stop DIY on Hex chain breaks where the fault is not consistent. Hex is six BM1368s on a UART daisy chain. If the serial log shows inconsistent chip counts across reboots, or the missing chip position changes, the fault is intermittent - a cold joint that is sensitive to temperature or mechanical stress. Intermittent faults need scope-level diagnostics and controlled thermal bake-out that are not practical at home. Ship to D-Central. Intermittent chain faults are the one place home diagnostics routinely fail.
Stop DIY on ambiguous diagnostics. If you have been through Tier 1 + 2 + partial Tier 3 and the story does not add up - Vcore looks right but chip will not handshake, serial log shows conflicting errors on different reboots, symptom is intermittent - you have crossed the threshold where bench-level isolation is worth more than more-DIY. D-Central sees the full failure distribution weekly; we can narrow in hours what takes weeks at home. Do not burn more hours chasing an ambiguous ghost; ship it.
Ship to D-Central with serial logs + PSU + context. Pack the Bitaxe in an anti-static bag, include the original PSU so we can test your exact stack, attach a note with: board revision (read the silkscreen), AxeOS version, serial console boot log (paste or screenshot), Tier 1/2 steps already tried, symptoms observed, context (power event? new-out-of-box? dropped?). Canada-wide shipping, US/international welcomed. Expected turnaround 5-10 business days. D-Central pioneered the Bitaxe ecosystem - original Mesh Stand, first Bitaxe + Bitaxe Hex heatsinks, full BM1366/1368/1370 chip inventory on the shelf.
Consider economics vs replacement before committing. A Tier-4 BM1366 replacement on Ultra runs CAD $85-160 depending on chip sourcing. New Ultra board replacement is CAD $130-180. Hex single-chip replacement is CAD $95-185; new Hex is CAD $220-320. GT replacement is CAD $260-360. If diagnostic reveals multi-component damage (TPS546 + chip + LDO all dead), replacement board is often the better economic path. We quote honestly up front - open hardware means an honest conversation, not a lock-in. Sometimes the right answer is a new board and salvaging the old one for parts.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
