Bitaxe – Stuck in Boot Loop / Rapid LED Cycling

Cold-unplug the barrel jack for a full 10 seconds — not 2, not 5, 10. This lets the TPS546 buck converter discharge fully, clears any latched fault state, drains the input-side capacitors, and resets the ESP32-S3 RTC domain. Soft reboots and power-button cycles never clear a wedged fault latch; a short 2-second blink just partially discharges caps and leaves the fault set. Roughly 30% of Gamma / GT boot-loop tickets resolve at this step alone and it costs $0.

Move the Bitaxe onto its own wall outlet. Remove every USB hub, extension cord, surge strip, and shared supply in the path. Plug the adapter directly into the wall. A single cheap USB hub feeding a Raspberry Pi, a webcam, and a Bitaxe will brown out the Bitaxe every time another device spikes current. If the loop clears on a direct wall connection you had a shared-rail brownout — not firmware, not hardware, just bad power topology. Stop blaming the miner.

Swap the PSU for a known-good supply rated at least 1.5x the miner's nominal draw: Ultra / Supra need 5V 4A minimum, Gamma needs 5V 6A minimum, GT needs a solid 60W+ USB-PD brick with a quality PD-to-barrel trigger cable or a 5V 10A+ barrel supply, Hex needs 12V at appropriate amperage. Loops that appear only when the ASIC tries to start (within 5-10 seconds of power-on) almost always trace to PSU sag under load. If the loop clears, replace the old supply permanently — don't trust it for a second miner either.

Swap the USB-C cable for one you know is data-capable. Test it first on a phone: if File Transfer / MTP mode works between phone and laptop with this cable, the data lines are intact. Charge-only cables are the single most under-diagnosed fault on Bitaxe boot-loop tickets — they deliver enough power to show the OLED splash, then fail the moment you open serial. Barrel-jack cables also matter: cheap thin-gauge ones drop 0.3-0.5 V at full Bitaxe load, which is enough to brown out an otherwise-fine 5 V supply.

Inspect the PCB visually. Pull the Bitaxe from its enclosure. Under good light — or a loupe — look for: scorch marks on the board, bulging / leaking MLCC capacitors near the TPS546, cracked solder joints under the ESP32-S3-WROOM module shield (stress fractures run perpendicular to the module edge), damage to the barrel-jack center pin, discoloration or pin-walk at the XT30 (GT only). Sniff the board — burnt phenolic or cooked-electronics smell means you're already at Tier 4. Do this before you touch firmware.

Measure VIN at the barrel jack under load with a multimeter. While the miner is cycling through its boot attempt, probe the barrel jack center-pin to ground. Healthy reading: >= 4.9 V sustained. If it sags below 4.7 V when the ASIC tries to start, your 'known-good' PSU is actually sagging — swap again or measure the supply at its own output terminals to isolate whether the loss is in the cable or the adapter. If VIN stays clean, measure the 3V3 rail at any accessible test point on the ESP32 side — a dead or oscillating 3V3 with VIN clean means a downstream buck has failed.

Capture the serial log. Plug USB-C from Bitaxe to laptop. Open a serial monitor at 115200 8N1: `idf.py monitor`, `pio device monitor`, Arduino Serial Monitor, `screen /dev/ttyUSB0 115200`, or PuTTY on Windows COM-port. Power the Bitaxe from the barrel jack (not laptop USB — you want real rail behavior under ASIC load). Record at least three full boot cycles. The first error line before each `rst:0x...` tells you exactly which of the seven root causes you're hitting. 30 seconds of serial capture turns a guessing game into targeted engineering.

Force ESP32 download mode. Hold the BOOT button while plugging USB-C into the laptop (Gamma / GT), or briefly short GPIO0 to GND on older Ultra / Supra boards without a physical BOOT button. Release BOOT after USB-C is connected. Run `esptool.py --chip esp32s3 --port COM4 chip_id` (replace COM4 with your actual port — /dev/ttyUSB0 on Linux, /dev/tty.usbserial-* on macOS). A healthy ESP32-S3 responds in under 2 seconds with its MAC address and feature flags. No response = the ESP32-S3 module itself is likely dead or the USB-C port is physically broken; skip to Tier 4.

Reflash AxeOS via the Bitaxe Web Flasher at https://bitaxe.org/flasher in Chrome or Edge (WebSerial required, no Firefox). Click Connect, pick the Bitaxe COM port, choose the factory image that matches your exact board — BM1366 for Ultra / Supra, BM1370 for Gamma / GT, BM1397 for Max. Read the sticker on the PCB, don't guess. Click Erase, then Flash. Wait for completion, unplug, power from the barrel jack. This single step resolves roughly 50% of boot-loop tickets by overwriting a corrupt or half-written app partition.

Reflash via esptool.py from a terminal when the Web Flasher fails or your browser blocks WebSerial. Install: `pip install esptool`. Download the correct factory image from https://github.com/bitaxeorg/ESP-Miner/releases. Force download mode per Step 8. Run: `esptool.py --chip esp32s3 --port COM4 --baud 460800 erase_flash` then `esptool.py --chip esp32s3 --port COM4 --baud 460800 write_flash 0x0 esp-miner-factory-gamma-v2.x.x.bin`. Replace the filename with the image matching your board. This bypasses browser bugs, WebSerial permissions issues, and flaky Chrome builds entirely.

Cross-check firmware image against board revision. Read the PCB sticker: it will indicate chip family and usually board rev (e.g. 'Gamma 602', 'Ultra 205', 'GT 800'). Compare against the image filename. Factory releases on bitaxeorg/ESP-Miner are named by chip family. Gamma 600 / 601 / 602 / 600-ESP-MON16 can need different builds — read the release notes on each tag before flashing. Wrong image = `ASIC serial: no ACK` and instant boot loop. Documented in ESP-Miner issues #213 and #1291.

Downgrade or upgrade around known-bad firmware builds. Boot loops are more common on specific releases: v2.1.5 (reboot storm, fixed in v2.1.6), v2.7.1 (Gamma temp bug), v2.8.0 (I2C race on Gamma 601/602, see issue #1291), v2.11.0b1 (HTTP socket exhaustion), v2.14.0b1 (heap leak). Beta tags crash; that's what betas are for. Production miners run the latest stable tag from bitaxeorg/ESP-Miner. Read the changelog before picking a version — it documents which regressions were fixed where.

Full NVS erase. Even after a clean reflash, stale non-volatile storage can hold a selftest-fail flag, corrupt WiFi credentials, or bad pool config that re-triggers the loop the instant AxeOS reads NVS. Force download mode. Run `esptool.py --chip esp32s3 --port COM4 erase_flash` with no filter — this wipes everything including NVS. Then write the factory image fresh. Reconfigure WiFi and pool from scratch via the AP captive portal (SSID `Bitaxe_xxxxxx`). This is the 'I've reflashed three times and it still loops' fix — because the app partition was clean, NVS wasn't.

Measure TPS546 rails under load on Gamma / GT. With the miner attempting to boot, probe VOUT on the TPS546 with a multimeter. Gamma core rail is nominally 1.1-1.3 V (firmware-configurable). Drops well below spec, or oscillation visible on a scope, indicates failing TPS546 input filtering or the IC itself. If VIN 5V is clean but the core rail collapses under ASIC load, the TPS546 is toast and needs IC-level replacement. SOIC-10 package on most revs — bench-level hot-air rework, not a soldering-iron job.

Reflow the ESP32-S3-WROOM module, flash chip, or XT30 connector on suspicion of intermittent solder. ESP32-S3 modules on 24/7 miners thermal-cycle hard and solder pads under the module can fatigue — producing boot loops that look exactly like firmware bugs but are actually cold joints. GT's XT30 is a documented weak point (see bitaxe-gt-xt30-connector-loose page). Reflow: bottom preheat at ~150 C for 60 s, top hot-air at ~300 C for 30 s, then let cool naturally. Reseat / resolder XT30 pins with fresh solder and flux. Temperature-dependent boot loops (works cold, fails warm) are always this.

Stop DIY and ship to D-Central ASIC + Bitaxe Repair when any of these are true: full erase_flash + fresh factory image still loops; two known-good PSUs both fail; rails measure 0V after forced download mode; visible burn / cracked solder / bulging cap / scorched trace / cooked smell; serial shows zero output on a verified-data USB-C cable; the ESP32-S3 does not enumerate on USB-C with BOOT held; loop is temperature-dependent and you lack hot-air rework gear. Book a slot at https://d-central.tech/services/asic-repair/. We stock salvaged-grade ESP32-S3-WROOM modules, TPS546 bucks, EMC2101 controllers, and every Bitaxe ASIC variant. 3-7 business-day turnaround. Canada / US / international shipping. D-Central pioneered the Bitaxe ecosystem — Mesh Stand, first heatsinks, full variant inventory.