Bitaxe Supra – BM1368 Not Responding After Power Cycle
Warning — Should be addressed soon
Symptoms
- AxeOS dashboard loads cleanly, but System Info -> ASIC Model reads none, unknown, blank, 0, or BM1368: 0/1
- Hashrate pinned at 0 GH/s or 0.00 GH/s indefinitely; no shares ever submitted to any pool
- Serial console at 115200 baud over USB-C shows Chain init: 0/1 chips found, BM1368 init: no response, ASIC_init failed, or Chip count: 0
- OLED displays splash and basic status (IP, Wi-Fi) but never transitions to a mining/hashing state
- Vin in AxeOS reads clean (4.95-5.25 V) - the input rail is not the immediate problem
- Vcore reads 0 V with a DMM, fluctuates wildly, or reads a plausible 1.20-1.30 V yet the chip still does not respond
- Power draw at the wall is suspiciously low (2-5 W instead of expected 15-18 W for a hashing Supra)
- Wrong AxeOS image was previously flashed (Gamma image, Ultra image, very old 1.x build) - symptom can persist after re-flashing the correct image until full NVS factory-reset
- Supra was recently moved, dropped, transported, or had its heatsink remounted right before the symptom appeared
- Board is new-out-of-box and has never hashed - classic factory QA escape, often a cold solder joint under the BM1368 BGA
- Board was hashing fine, then stopped after a power event, surge, brownout, or hot-plug of USB-C while main PSU was on
- No visible damage to the BM1368 package - no scorch, no discolouration, no cracked epoxy - yet the chip is silent
- Heatsink is loose, missing, or recently remounted with visible PCB flex
- After a serial-log capture, the FIRST failing line is in the chain-init phase, not in TPS546_init / I2C bring-up
Step-by-Step Fix
Full cold-boot with 60-second discharge. Unplug EVERYTHING - main PSU, USB-C, any accessory cable - and wait a full 60 seconds before re-powering. The discrete regulator on Supra can latch into a fault state that a soft reboot will not clear, and the ESP32-S3 brownout detector can hold the chain-init phase in a hung state. A true hard-discharge drains the bulk input caps and forces clean cold-init. Use this minute to ask: which PSU is connected? The original Bitaxe-bundled brick, or a random 5V charger from the drawer? Note that and address it in Step 4.
Try USB-C only (no main PSU) for bootloader access. Connect a USB-C data cable from a PC to the Supra with NO main PSU attached. The ESP32-S3 is USB-bus-powered for firmware access only - this isolates 'is the MCU alive' from 'is the BM1368 chain alive'. If the PC enumerates an ESP32-S3 JTAG/serial device (Device Manager / lsusb / dmesg), the ESP is healthy and the problem is downstream at the BM1368 or its rail. If not, hold BOOT, tap RESET, release BOOT - forces the mask-ROM bootloader. Confirms you can reach the MCU for firmware recovery.
Open a serial console and capture the full boot log. Same USB-C connection, any serial terminal (screen / minicom / PuTTY / VS Code Serial Monitor) at 115200 baud, 8N1. Connect main PSU with terminal already open. Watch init lines: VCORE_init, TPS546_init (if present), Chain init, Chip count: N. Screenshot or paste the entire output. The FIRST line that fails or reports 0 is your starting diagnostic clue and the single highest-value piece of information for any support ticket. Five minutes with a serial terminal saves ten days of guessing - and is the difference between a useful D-Central support ticket and a useless one.
Swap to a known-good regulated 5.0 V / 3 A PSU. The single highest-yield fix on Supra. NOT a phone charger, NOT a PC USB port, NOT a 5V wall-wart from the drawer - those sag below 4.8 V under the BM1368 transient init load and produce Chain init: 0/1 intermittently. Use a D-Central Bitaxe PSU bundle, a Mean Well GST60A05-P1J, a CUI brick of equivalent spec, or any genuinely-regulated 5.0 V / 3 A unit with a center-positive USB-C or barrel matching your Supra revision. Plug in, power-cycle, re-check dashboard. Meaningful fraction of cases resolve here.
Re-flash the correct factory AxeOS image via Web Flasher. Open bitaxeorg.github.io/bitaxe-web-flasher/ in Chrome or Edge. CRITICAL: select the EXACT image for Bitaxe Supra AND your board revision. Supra 401 and 402 are different images. The Web Flasher lists multiple variants - Ultra, Supra, Gamma, Hex, GT - and they are NOT interchangeable. An Ultra image on a Supra boots AxeOS but mis-handshakes with the BM1368 and reports 0/1. Read the silkscreen on the PCB before flashing - do not guess. Flash, wait for completion, full power-cycle (USB-C AND main PSU unplugged 30 s), reconnect, re-check.
NVS factory-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 correct 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 BM1368 chain-init is a transient load. Open-circuit: 5.0-5.25 V. Under 2-5 A load (halogen bulb, USB load tester, electronic load): >= 4.8 V sustained. 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' Supra failures trace back to a PSU that tests fine on a DMM at idle but fails under real-world current. Replace before continuing further diagnostics.
DMM-verify Vcore with AxeOS running at idle. Probe the BM1368 Vcore test points (silkscreened on Supra 401/402; otherwise reference the bitaxeorg/ESP-Miner schematic) with the board powered and AxeOS running but no work dispatched. Expected on Supra: ~1.20-1.30 V at stock frequency. Vcore = 0 V means the regulator is dead. Vcore out-of-range or oscillating means regulator damaged but partially working. Vcore = 1.20-1.30 V means the regulator is fine and the problem is downstream in UART or chip itself. 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 BM1368. Power off, remove heatsink, inspect: 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? Remount with appropriate thermal paste (Arctic MX-6 or Thermal Grizzly Kryonaut), even pressure, correct screw torque (finger-tight-plus-quarter-turn, NOT cranked). Re-power, re-check. A non-trivial number of BM1368 not responding 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 Ultra or another Supra, swap to the dead Supra. 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 - cheapest diagnostic tool in the shop. Avoids buying parts for a problem you do not actually have.
Measure the BM1368 nRST line under power. With board powered and AxeOS running past initial bring-up, DMM in DC volts on the BM1368 nRST pin (referenced in the Supra schematic) against GND. Expected: ~3.3 V (deasserted). If reading 0 V or close, the chip is held in permanent reset - UART will never respond regardless of Vcore or firmware. Causes: ESP32-S3 GPIO stuck low from corrupt firmware, shorted nRST net to GND, or open/burnt pull-up resistor. Re-flash AxeOS first; if nRST stays low after re-flash, escalate to Tier 3 trace inspection.
Scope UART TX/RX during Chain init. A cheap 50 MHz handheld scope or logic analyzer on the BM1368 UART RX (data from ESP) and TX (data from chip) reveals exactly where the handshake breaks. Trigger on the ESP TX line going active during boot. Healthy: ESP TX shows 0x55 0xAA preamble at 115200 baud, BM1368 TX replies within microseconds with chip-ID readback. Failure modes: (a) ESP TX active, BM1368 TX flat = chip not replying, go to reflow. (b) ESP TX flat = firmware not driving the bus, re-flash AxeOS with NVS-erase. (c) Both flat = chip unpowered or held in reset, go to nRST check. (d) ESP TX correct, BM1368 TX shows garbage = wrong-firmware mis-handshake, re-confirm Step 5 firmware match.
Reflow the BM1368 with hot air. With heatsink removed and 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. Reflow recovers a measurable fraction of BM1368 not responding boards - especially new-out-of-box units where the fault is a factory cold BGA joint. Thermal stress of normal operation gradually worsens cold joints until handshake breaks; reflow re-forms the joint. Re-apply thermal paste, reseat heatsink correctly, retest.
Discrete regulator (LDO/buck) replacement on Supra. If Step 8 showed Vcore = 0 V on Supra, the discrete 5 V -> Vcore regulator IC is the suspect. Identify the part from silkscreen and Supra schematic - typically a SOT-223 or QFN package near the BM1368 bulk caps. Hot-air desolder, clean pads with braid + flux, place a replacement of matching spec (watch drop-out voltage, current rating, feedback divider - different revisions use different parts). Re-test the rail with DMM before powering the full board. Re-flash AxeOS, verify Vcore reads ~1.20-1.30 V, retest.
BM1368 replacement at the bench. If reflow fails and Vcore is confirmed clean, the chip itself is dead. BM1368 replacement: desolder with hot air + low-melt alloy or a preheater, clean pads with braid + flux, place a fresh BM1368 (~$30 USD per chip from D-Central inventory or a graded reseller - verify date code), reflow down with proper thermal profile. Re-flash AxeOS factory image. Full bring-up from Step 1. Tier 3 only if you have hot-air, preheater, microscope, and prior BGA experience; otherwise this is firmly Tier 4.
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 - reflow, regulator swap, BM1368 replacement - re-flash the correct factory AxeOS image via Web Flasher BEFORE full-load validation. Verify the dashboard reports BM1368: 1/1 and hashrate climbs to nameplate before declaring the repair complete. A common false-failure: the hardware repair is good, but leftover rework-induced flash corruption makes it look like the repair did not take.
Stop DIY on BGA rework if you do not have hot-air + preheater + microscope. The BM1368 is a BGA package. 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. Without hot air, you cannot reflow at all. Ship the board. D-Central bench has the full rework stack and BM1368 chip inventory on the shelf - ~$30 chip cost + bench labour, far below the cost of a new Supra board if your alternative is buying replacement and your skill stack is not ready.
Stop DIY on intermittent symptoms. If the Supra sometimes detects the BM1368 (1/1 after a particular reboot) and sometimes does not (0/1 after another), the fault is intermittent - a cold joint sensitive to temperature or mechanical stress, or a damaged passive right at threshold. Intermittent faults need scope-level diagnostics with controlled thermal bake-out that are not practical at home. Ship it. Intermittent BM1368 chain faults are the one category where home diagnostics routinely fail and chase the operator in circles for weeks.
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, scope shows ESP TX correct but BM1368 TX flat after a reflow attempt, serial log shows conflicting errors on different reboots - you have crossed the threshold where bench-level isolation is worth more than more-DIY. D-Central sees the full failure distribution weekly; we 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 log + PSU + context. Pack the Supra in an anti-static bag, include the original PSU so we can test your exact stack, attach a note with: board revision (read silkscreen - 401 or 402), AxeOS version flashed, serial console boot log (paste or screenshot), Tier 1/2/3 steps already tried, observed symptoms, any context (power event? new-out-of-box? dropped? recently transported?). Canada-wide shipping, US and international welcomed. Expected turnaround 5-10 business days. D-Central is a pioneer in the Bitaxe ecosystem - original Mesh Stand manufacturer, first Bitaxe + Bitaxe Hex heatsinks designer, BM1366/1368/1370 chip inventory kept on the shelf for chip-level repairs.
Consider economics vs replacement. A bench BM1368 replacement on Supra runs roughly CAD $90-$170 (chip + labour, directional). A new Supra board replacement is roughly CAD $130-$200. If the diagnostic reveals multi-component damage (regulator + BM1368 + passive all dead), a replacement board is often the better economic path - and the dead Supra becomes parts inventory for a future repair. 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.
