Bitaxe – Power Fault / TPS546 Out of Regulation Window
Critical — Immediate action required
Symptoms
- AxeOS dashboard reports `Power Fault Detected` or a related TPS546 status string
- Dashboard `Vcore` reads `nan`, `0.00 V`, or wildly off-target (setpoint `1.20 V`, actual `0.55 V` or `1.85 V`)
- `/api/system/info` returns `nan` for `voltage`, `current`, `power`, or `coreVoltageActual`
- Hashrate flatlines at `0 GH/s` or oscillates wildly (full speed → zero → full speed) every few seconds
- Wall draw collapses to ~5 W (Gamma/Supra/Ultra) or ~10-12 W (Hex) when expected is ~16-17 W / ~30 W / ~80 W
- AxeOS log shows `TPS546 read error`, `PMBus NACK`, `i2c_master_transmit_receive` failures, or `i2c handle not initialized`
- Bitaxe heatsink is briefly warm, then goes cold within 30 seconds (regulator latched off)
- Hashboard temperature telemetry reports unrealistic values (`-1.0 °C`, `255 °C`, or stuck `0 °C` — sensor on same I2C bus as TPS546)
- Audible high-frequency tick or click from the regulator area (out-of-regulation oscillation)
- `PG` (Power Good) signal stays low — measurable on a scope at the TPS546 `PWRGD` pin
- LED never reaches steady hashing state, or reaches it for <60 s then drops back
- Symptom appeared after aggressive autotune push, thermal event (closed enclosure / no airflow), wrong-voltage brick, power surge, or brownout
Step-by-Step Fix
Cold power-cycle for a full 10 seconds. Unplug barrel jack (Supra/Ultra/Gamma), XT30 (GT), or 12 V IEC brick (Hex). Count to 10 — longer than feels necessary. Reconnect. The TPS546D24A latches OCP, OTP, and Vout-out-of-regulation faults internally on STATUS_WORD until VIN is physically removed; soft reboots via AxeOS, /api/system/restart, or pressing RST on the ESP32 do not clear them. This single move recovers the majority of transient power-fault events. Watch dashboard for 3 minutes post-reconnect; expect hashrate climb to nameplate (~1.2 TH/s Gamma, ~700 GH/s Ultra, ~2.4 TH/s GT, ~3 TH/s Hex).
Pull anything plugged into USB-C and re-verify barrel/XT30 power only. USB-C on every current Bitaxe is serial + ESP-flash only; it cannot deliver enough current to power the ASIC. A user who plugs only USB-C into a Gamma sees ~2 W wall draw and 0 GH/s — identical at the dashboard to a TPS546 power fault. Confirm canonical input is connected, brick LED solid, cable fully seated.
Drop autotune / core-voltage target back to stock and reboot. Aggressive autotune trips OCP under transient hash bursts even when average current is fine. Stock voltage: 1200 mV BM1370 Gamma, 1250 mV BM1366 Ultra, 1300 mV BM1397 Supra. After cold boot, leave on stock for 30 minutes before re-tuning. Stable at stock = autotune was your fault.
Move the unit out of any enclosed space. Bitaxe stuffed in closed plastic case, on a hot shelf, or under a desk pile-up routinely runs the TPS546 hot enough to trip OTP. Move to flat desk with 15 cm clearance on all sides and ambient airflow. Fault clears = environment was the cause; fix airflow before reinstalling.
Verify firmware version is current stable. AxeOS top-right or System → Info. Anything in the v2.8.0 window on Gamma 601/602 silicon overlaps with a known firmware regression that interacts with TPS546 init. Flash current stable AxeOS factory .bin for your exact board revision via the Bitaxe Web Flasher (bitaxe.org) before spending more time on hardware. Never OTA blind on a faulting board — Web Flasher over USB-C is more reliable.
Multimeter the input rail under load. DC mode, probe at barrel-tip / XT30 plus / Hex 12 V connector while the unit is attempting to boot or hash. Expect 4.95-5.15 V (5 V boards) or 11.7-12.3 V (Hex) sustained. Sag below the lower bound = supply inadequate. Most consumer USB-PD bricks droop 200-500 mV under continuous 16 W load — exactly what kicks a marginal TPS546 into UVLO. Swap to D-Central Bitaxe PSU or bench supply at 5.00 V current-limited to 5 A.
Capture the AxeOS serial boot log over USB-C. Connect USB-C, open `screen /dev/ttyUSB0 115200` (Linux/Mac), PuTTY at 115200 baud (Windows), or Arduino Serial Monitor. Power-cycle via barrel/XT30 and capture first 30 s. Specific signatures to look for: `TPS546 read error`, `i2c_master_transmit_receive(1206): i2c handle not initialized`, `Power Fault Detected`, `VOUT out of regulation`, `STATUS_WORD: 0x...`. Each maps to a different root cause. Save the log — if you ship the board, this cuts D-Central diagnostic time in half.
Probe Vout directly with a multimeter (DC) on the ASIC core rail. Locate the largest output cap downstream of the TPS546 (largest ceramic next to buck inductor). Probe across it. Healthy: matches coreVoltage setpoint within 25 mV (e.g. 1.20 V ± 0.025 V on Gamma). Vout = 0.00 V while ESP32 alive = regulator latched off, proceed to Step 9. Vout close to setpoint but telemetry shows nan = bus hung, not rail; flash current AxeOS and re-test.
Try a clean factory flash via Web Flasher rather than OTA. Some power-fault cases are firmware state, not hardware. Hold BOOT, tap RST, release BOOT to put ESP32-S3 in download mode. Open bitaxe.org Web Flasher, select factory image for your exact silicon (BM1370 Gamma/GT, BM1366 Ultra/Hex, BM1368 newer Supra revs, BM1397 original Supra). Flash. Reconfigure WiFi and pool. Boot. Factory flash erases NVS — including any aggressive autotune state that might have cooked the TPS546.
Inspect input cable and connector. Bitaxe barrel jacks (5.5 x 2.1 mm) work loose under cable strain. Wiggle the connector while powered and watch the dashboard — if hashrate flickers or fault re-latches, jack is worn. Same for GT XT30: partial seating produces transient VIN drop indistinguishable from PSU sag. Strip back, reseat firmly, cable-tie supply lead to chassis to remove strain on connector.
Bench-supply with current limiting to characterize the fault. Set regulated bench PSU to 5.00 V (or 12.0 V Hex), current-limited to 5 A (or 8 A Hex). Power Bitaxe through barrel/XT30. Monitor current draw through boot. Healthy: brief spike to ~3.5 A (5 V boards) as VCORE comes up, settles to ~3.2 A steady-state. Failed: stays flat at ~1 A (ESP-only). Or climbs past 4.5 A and bench supply hits current limit before ASIC stabilizes — TPS546 trying to source too much current, suggesting partial short on core rail or damaged decoupling cap.
Scope PWRGD and Vout rails through boot. With 100 MHz+ scope, probe TPS546 PWRGD (one channel) and Vout at output cap (second channel), trigger on rising edge of VIN. Healthy: Vout ramps cleanly to setpoint over ~1-2 ms, PWRGD rises high ~1 ms later. Out-of-regulation: Vout overshoots, rings, sags, or never reaches setpoint; PWRGD pulses low before staying high. Saw-tooth on Vout = oscillating regulator (compensation issue or output cap dead). Clean ramp but PWRGD never asserts = chip-internal fault, replace.
Inspect output-side caps and buck inductor under 10x-20x magnification. Look for: cracks in MLCC bodies (especially X7R, which crack under PCB flex during shipping), blackening, lifted pads, visible solder damage. TPS546 loop stability depends on output cap network; a cracked 22 µF MLCC silently drops capacitance to picofarads and the regulator goes unstable. Replace any visibly damaged cap with same-value, same-dielectric, same-or-better-voltage-rated part. Inductor: check thermal damage (browning), cracked core, windings pulled away from pads.
Reflow the TPS546 if package damage is suspected. Remove heatsink. Apply flux generously around QFN. Preheat board from below to ~150 °C on PCB heater. Hot-air top-side at 280-310 °C for ~20 s. Let cool naturally — do not blow with cold air. Reapply thermal paste, reinstall heatsink, retest. The TPS546D24A QFN tolerates one or two reflow cycles cleanly; past that you are replacing the chip. Reflow fixes hairline solder cracks from shipping or aggressive thermal cycling and recovers ~30% of bench cases.
Replace the TPS546 if reflow fails. TPS546D24A is QFN40 5 x 7 mm — compact but reworkable on hot-air bench with patience. Source from Digi-Key (TPS546D24ARVFR) or Mouser, or order board-level swap from D-Central Bitaxe parts. Critical: D24S drop-in (different IC_DEVICE_ID byte) requires current AxeOS for firmware tolerance — flash forward before shipping to save a return visit. Honor pin-strapping resistor values from original; the strap configures default VOUT_COMMAND and PMBus address.
Stop DIY and book a D-Central bench slot when: (a) you have cold-cycled, swapped PSU, flashed current AxeOS, and fault persists; (b) scope shows clean VIN but Vout never asserts or rings continuously; (c) you have found visible cap or chip damage you do not have rework gear for; (d) input-side MOSFETs or polarity-protection circuit may be damaged (e.g. 12 V brick mistakenly plugged into 5 V Bitaxe); or (e) you have burned more than 2 hours of bench time. Past 2 hours the D-Central bench at d-central.tech/services/asic-repair/ is faster AND cheaper than your hourly rate.
D-Central bench process. USB-C serial diagnostic first (5 minutes, saves you hundreds in misdiagnosis). Bench PSU with current logging through boot to characterize fault class. PMBus probe on a working test fixture to verify chip comms. Output cap and inductor inspection at 20x. TPS546 swap if package damage confirmed. Current AxeOS factory flash with verified VCORE init in serial log. 24-hour burn-in at nameplate hashrate on the D-Central bench stratum before return-shipping. We log silicon revision (D24A vs D24S) and board rev per repair — that data feeds back into published advice.
Ship safe. Anti-static bag (the pink ones, not just bubble wrap). Padded box with at least 3 cm foam on every side. Include: (a) symptoms observed, (b) firmware version last running, (c) which tiers you have tried, (d) the supply you have been using — including the PSU lets us test the whole power path end-to-end. Bitaxes are tiny: a Gamma ships Canada-wide for roughly CAD $15-25, US/international welcomed. We turn most TPS546 boards in 3-7 business days.
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.
