Bitaxe – BM1366 Not Responding After Power Surge
Critical — Immediate action required
Symptoms
- Surge event just occurred: grid event, near-lightning, breaker trip, generator transfer, or upstream PSU failure
- Bitaxe no longer emits its `bitaxe_xxxx` Wi-Fi AP on cold boot — no SSID visible on any nearby device
- OLED display blank or flashes once and dies; other Bitaxes on same bench are fine
- AxeOS `Vin` reads `0 V` despite a known-good PSU, OR reads nominal `5 V` / `12 V` but hashrate is stuck at `0 GH/s`
- AxeOS logs `ASIC init failed`, `ASIC serial timeout`, or `BM1366 no response` on every boot attempt
- `count_asic_chips` returns `0` on Ultra (expected `1`) or fewer than `6` on Hex
- ESP32-S3 serial console (USB-C, `115200 baud`) shows `brownout_det: detected`, `Guru Meditation Error` loops, or complete silence
- Device does not enumerate over USB-C — host OS reports no new device; `dmesg` / Device Manager shows nothing
- Visible physical damage: scorch on BM1366, discolouration around TPS546, bulged electrolytic, blackened 5V LDO, or burnt-resistor smell near input
- `Power Fault Detected` fires within `1-2 s` of every power-on, even from a known-good PSU (TPS546 UVLO latch)
- Fault coincided with a house-wide event (neighbour A/C kick, UPS switch, transformer event) — not a user action
- Other devices on the same power strip also died or rebooted at the same instant — classic mains-coupled surge signature
- The PSU itself may be dead — DMM at PSU output reads `0 V` or out of spec; the PSU ate the surge
- Board continuity-beep short between `Vin` and `GND` rail (with all power disconnected) indicating a regulator or cap failed shorted
Step-by-Step Fix
Unplug everything for a full 60 seconds before any recovery attempt. The TPS546-family regulator and the ESP32-S3 brownout watchdog can both latch into a fault state that a soft reboot will not clear. Main PSU, USB-C, fan connectors — all unplugged. Use the time to move to a different wall outlet on a different breaker from the one involved in the surge event. Empty the bulk input caps, force a true cold start, and change the upstream context before re-powering.
Try USB-C alone first — no main PSU connected. The ESP32-S3 is USB-bus-powered for bootloader access, so this isolates 'is the MCU alive' from 'is the rail alive.' Connect USB-C from PC to Bitaxe. If the PC enumerates any ESP32-S3 JTAG/serial device in Device Manager, `lsusb`, or `dmesg`, the MCU survived. If not, hold `BOOT` on the board, tap `RESET`, release `BOOT` — this forces the ROM bootloader, which is mask-ROM and cannot be damaged by firmware events. Still no enumeration means MCU-level damage and Tier 4.
Flash the factory image via the Bitaxe Web Flasher. If USB-C enumerated the device, open `bitaxeorg.github.io/bitaxe-web-flasher/` in Chrome or Edge (WebSerial required). Select the EXACT factory image for your board revision — Ultra 202/204/205/207, Supra 401, Gamma 601/602, Hex v303/v304 each have different images. Flashing the wrong one will not physically damage the board but will prevent correct boot until re-flashed correctly. Flash, wait ~30-60 seconds, disconnect USB-C, reconnect main PSU, watch for the Wi-Fi AP. Recovers surge-hit Bitaxes where damage was limited to a corrupted application flash partition.
Cold-boot from a known-good regulated PSU on a DIFFERENT outlet. Never power a surge-hit Bitaxe from the PSU that was attached during the surge until you have DMM-tested it — the PSU often eats the transient and fails subtly, passing slightly-wrong voltage afterwards that finishes the job on a marginal board. Swap to a regulated brick from Mean Well, CUI, or the D-Central Bitaxe bundle. Ultra/Supra/Gamma: `5 V / 3 A` minimum. Hex: `12 V / 5 A` minimum. Watch for Wi-Fi AP and OLED splash.
Reconfigure and monitor the board for 24 hours if it boots. A surge-recovered Bitaxe can look healthy for 5 minutes and then degrade as damaged components heat up or a marginal chip hits its thermal limit. Reconfigure Wi-Fi, pool, and any custom tuning, then monitor AxeOS status for: intermittent `Power Fault Detected`, HW% climbing above baseline (`<1%` on a healthy BM1366 Bitaxe), `Vin` sag under ramps, unexplained reboots, or chip temperature creeping up. Latent surge damage often shows up over days, not minutes. If anything looks marginal, reduce frequency/voltage and plan a bench assessment.
DMM the suspect PSU, open-circuit and under load. Unplug from the Bitaxe. DMM on DC volts, probe at the plug with no load. Ultra: expect `5.0-5.25 V`. Hex: expect `12.0-12.6 V`. Then apply a `2-5 A` load (12V halogen bulb for Hex, USB load bank for 5V, or an electronic load). Under load: Ultra `>= 4.8 V`, Hex `>= 11.5 V`. PSU reads `0 V`, oscillates, or sags materially = PSU is the primary casualty. Replace before powering the Bitaxe. Many 'surge killed everything' tickets resolve to 'the PSU saved the Bitaxe; buy a new PSU.'
Continuity-test the Bitaxe's input rail with the board fully disconnected from all power. DMM on continuity / diode mode. Probe tip-to-sleeve on the barrel jack (Hex) or VBUS-to-GND on USB-C (Ultra). Healthy: high-impedance, several kΩ to MΩ, with a brief charge-up spike. Shorted: continuous beep, resistance under `~10 Ω`. A shorted rail means the TPS546, the 5 V LDO, or a bulk cap failed shorted internally. Do not power a shorted board — the PSU's OCP will fire and may cascade further damage. Shorted = Tier 4.
Inspect the input connector and surrounding PCB under magnification (jeweller's loupe or USB microscope). A surge leaves subtle clues at its entry point: a vaporised trace section, a blackened TVS diode package, solder splash from a blown capacitor nearby, pitted contacts on the barrel jack or USB-C port, or black residue on the connector shell. Photograph anything suspicious for a D-Central repair note. Damaged connectors must be replaced before further testing — intermittent contact cascades into endless confusion.
Probe `Vin` live on a verified-good PSU. If the board boots, open AxeOS status and watch `Vin` across idle to full-hashing ramp. Expected: Ultra `5.0 V ± 0.1`, Hex `12.0 V ± 0.2`, stable across the ramp. A surge-damaged TPS546 or LDO will regulate badly — `Vin` may sag, oscillate, or spike during transients that a healthy board rides cleanly. Cross-check with a DMM on the rail; discrepancy between AxeOS and DMM suggests the ADC or a sense divider also took damage. This live probe distinguishes a fully-recovered board from one with latent damage.
Swap to a known-good PSU from another healthy Bitaxe to bisect PSU vs board. If you run multiple Bitaxes, borrow a proven-working PSU from a healthy unit, connect to the surge-hit board. Symptom moves with the PSU = PSU is the root cause. Symptom stays with the Bitaxe = board damage. Cheapest 5-minute diagnostic in the entire triage; also why D-Central's multi-Bitaxe bundles include a spare spec-matched PSU.
Scope the `Vin` rail and `Vcore` under load. A `50 MHz` handheld scope (Owon HDS242, Rigol DHO804) on the input rail during a frequency ramp reveals ripple and transients a DMM averages out. Healthy regulated PSU: `< 100 mV` pk-pk ripple on `Vin`. Surge-damaged TPS546: often `> 500 mV` ripple or intermittent undershoots that trigger `Power Fault Detected` without failing any DMM-averaged reading. Probe `Vcore` near BM1366 decoupling caps — stock `1.25-1.35 V`, clean and stable. Lost transient response = regulator damaged.
Check the TVS diode at the input. Locate the TVS near the barrel jack or USB-C VBUS (typically SOD-323 or SMA). DMM diode-test in-circuit, board unpowered. Healthy TVS: open-circuit both ways at normal DMM voltages. Failed-short TVS (common post-surge — it did its job but didn't survive): reads as a short. Desolder and replace with same-spec part (`$0.50-$2` each). A surprisingly common single-component fix on surge-hit Bitaxes that otherwise look dead. Restores input protection for the next transient.
Replace the 5 V LDO (Ultra/Supra/Gamma) or the TPS546 regulator (Hex, Gamma/GT) if damaged. Identify the part from board silkscreen and the bitaxeorg schematic repo. Hot-air desolder: preheat bottom `~150 °C`, top-side `~310-330 °C`, lift part, clean pads with braid and flux, reflow new part down. Keep peak temp under 3 seconds or adjacent caps lift. Post-replacement, DMM-verify the rail before powering the full board. Hot-air-station job, not an iron job.
Reflow or replace the BM1366 if `count_asic_chips = 0` after clean firmware flash and clean rails. Reflow first — transient damage occasionally cracks a solder joint on the BGA rather than killing silicon. Preheat `~150 °C`, top-side `~310-330 °C` for `~30 seconds`, cool naturally, retest. If reflow fails, replacement: desolder, clean pads, place fresh BM1366 from D-Central graded inventory or trusted supplier, reflow down. On Hex with `count_asic_chips = 1-5`, replace the dead chips (usually the ones closest to the input rail) — the others are typically fine.
Inspect ESP32-S3 for USB-C-coupled ESD damage. If the board powers up but the ESP32-S3 no longer enumerates over USB-C, check the VBUS ferrite, the ESD protection diodes on D+/D-, and the `3.3 V` rail to the MCU. ESP32-S3 tolerates substantial ESD thanks to on-die protection, but a direct mains transient through the USB-C shield can punch through. Clean `3.3 V` at the MCU with MCU silent = MCU damaged, and replacement requires BGA-adjacent rework (Tier 4).
Re-flash firmware after any component replacement. Any hot-air rework can briefly raise flash temperature and corrupt data. After any Tier 3 swap, re-flash the factory image via Web Flasher before full-load validation. Use the correct factory image for the board revision (flashing the wrong variant is recoverable but confusing). Verify `count_asic_chips` matches expected before declaring the repair complete. Run 30-minute full-load burn-in before returning to production.
Stop DIY if the input rail shows a continuity-beep short with the board fully unpowered. A shorted `Vin` rail means a component failed shorted internally — desoldering BGA parts and large electrolytics without a hot-air station and a rework microscope is a reliable way to lift pads and turn a `$45` parts-swap into a `$150` replacement board. Ship the board to D-Central. Our bench handles this class of work every thunderstorm season.
Stop DIY on visible thermal damage. Scorched packages, bulged caps, blackened LDO or TPS546, charred PCB — bench-rework jobs. Iron-level work compounds the damage; hot-air with proper board preheat and a rework microscope is mandatory. The board is usually worth saving (ESP32-S3, OLED, EMC2101, connectors, PCB are all reusable), but only with a proper process. Pack anti-static, ship to D-Central.
Stop DIY if the ESP32-S3 doesn't enumerate in forced-bootloader mode. A dead ESP32-S3 needs replacement — the part is a QFN package, technically reworkable with skilled iron-plus-hot-air, but post-replacement bring-up (fuse verification, peripheral re-init) is bench-only. D-Central can also harvest the OLED, connectors, and passives to another board if ESP replacement isn't economically worthwhile for your specific case.
Ship to D-Central with the PSU and the surge context. Pack the Bitaxe in an anti-static bag, include the original PSU (so we can reproduce the fault with your exact stack), and attach a note describing the surge event (thunderstorm? UPS switch? other devices affected?), your diagnostic steps taken, and observed symptoms. Canada-wide shipping; US/international welcomed. Turnaround `5-10` business days. D-Central pioneered Bitaxe ecosystem — original Mesh Stand, first heatsinks, deep bench history on surge-damaged boards through Canadian thunderstorm season.
Consider the economics before committing to a full repair. Tier 4 surge-damage repair averages `CAD $60-$140` depending on which components failed. Ultra replacement: `CAD $130-$180`. Hex replacement: `CAD $220-$320`. If multiple components failed (TPS546 + BM1366 + ESP32-S3 all dead after a severe strike), replacement is often the better economic call. Bitaxe is open-source hardware — bench time to recover a triple-component-death isn't always worth it. D-Central will quote honestly; ask us before committing.
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.
