Bitaxe – ESP32 Crash Loop / Reboot Loop

Cold-unplug the barrel jack for a full 10 seconds, then power back up. Do not soft-reboot — the TPS546 buck converter (Gamma / GT) and the ESP32-S3 RTC domain need real time to discharge so the fault latch and any stale NVS flags clear. A 2-second blink leaves capacitors partially charged and the fault state set. This single step resolves roughly 30% of Gamma / GT crash-loop tickets and it costs $0.

Move the Bitaxe to its own wall outlet and remove any USB hub, extension cord, or surge strip in the path. Plug the adapter directly into the wall. A single cheap hub that also feeds a Raspberry Pi, a webcam, and a phone will brown out the Bitaxe whenever one of the other devices spikes current. If the loop clears with a direct connection you had a shared-rail brownout, not a firmware issue.

Swap the PSU for a known-good one rated at least 1.5x the miner's nominal draw: Ultra / Supra need at least 5V 4A, Gamma needs 5V 6A minimum, GT needs a solid 60W+ USB-PD brick with a PD-to-barrel trigger cable or a 5V 10A+ barrel supply. Crashes that appear only when the ASIC tries to start (first 5-10 seconds after boot) almost always trace to PSU sag. Measure VIN at the barrel jack under load if you have a multimeter.

Inspect the USB-C port and the barrel-jack connector for lint, dust, bent pins, or mechanical damage. Shine a flashlight inside. Puff out with dry compressed air — no liquid, no cotton swabs that can shed fibers. Intermittent contact here creates brownout-style crashes that look exactly like firmware bugs. If the port is physically damaged, stop forcing cables in and move to Tier 3 resolder.

Confirm ambient air temperature at the Bitaxe intake is at or below about 35 degrees C. Passive-cooled Bitaxes in closed boxes, on sunny window ledges, or next to a furnace vent can thermal-throttle the ESP32-S3 and crash before the ASIC even spins up. Move the miner somewhere cooler with open airflow to the heatsink and try again. Not usually the cause, but fast to rule out before you touch firmware.

Capture the serial log. Plug USB-C from the Bitaxe into a laptop. Open a serial monitor at 115200 baud: `idf.py monitor`, `pio device monitor`, Arduino Serial Monitor, `screen /dev/ttyUSB0 115200`, or PuTTY on a Windows COM port. Power the Bitaxe from the barrel jack so you see real rail behavior, not laptop-bus-powered behavior. Record at least three full boot cycles. The first error line before each `rst:0x...` tells you which of the six root causes you're hitting.

Reflash AxeOS via the Bitaxe Web Flasher at https://bitaxe.org/flasher in Chrome or Edge (WebSerial required). Click Connect, select 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). Click Erase then Flash. Wait for completion, unplug, power from the barrel jack. This resolves roughly 50% of crash-loop tickets by overwriting a corrupt app partition.

Reflash via esptool.py from a terminal when the Web Flasher fails or your browser blocks WebSerial. Install esptool: `pip install esptool`. Download the correct factory image from https://github.com/bitaxeorg/ESP-Miner/releases. Hold BOOT while plugging USB-C (or short GPIO0-to-GND briefly on older boards without a BOOT button), then release BOOT. Run: `esptool.py --chip esp32s3 --port COM4 --baud 460800 erase_flash` followed by `esptool.py --chip esp32s3 --port COM4 --baud 460800 write_flash 0x0 esp-miner-factory-gamma-v2.x.x.bin`. Replace COM4 with your port (/dev/ttyUSB0 on Linux, /dev/tty.usbserial-* on macOS).

Downgrade or upgrade around known-bad firmware builds. If your log shows v2.1.5, flash v2.1.4 or v2.1.7+. If v2.11.0b1, flash stable v2.11.x. If v2.14.0b1, flash stable v2.14.x. Early v2.0.x BM1397 builds and v2.7.1 / v2.8.0 on Gamma also shipped known regressions. Beta builds crash — that's what betas are for. Production miners run the latest stable release tag from bitaxeorg/ESP-Miner. Read the changelog to confirm which bugs were fixed.

Once the miner is stable, enable AxeOS's restart-on-no-hashrate watchdog in settings. This does not prevent crashes — it self-heals them. The next time a rare panic slips through, the miner reboots itself and resumes hashing without you noticing. Standard Mining Hacker hygiene for any Bitaxe on a long-uptime deployment, especially lottery-miner setups and Bitaxe Hex multi-chip builds.

Full NVS erase. Even after a clean reflash, stale non-volatile storage can hold corrupt WiFi credentials, selftest fail flags, or bad pool config that re-trigger the crash immediately. Erase everything with `esptool.py --chip esp32s3 --port COM4 erase_flash` (no --flash_only), then write the factory image fresh, then reconfigure WiFi and pool from scratch via the AP captive portal. This is the 'I've reflashed three times and it still loops' fix — because the app was clean, but NVS wasn't.

Flash a debug build and read the panic decoder output. Clone bitaxeorg/ESP-Miner, run `idf.py set-target esp32s3`, `idf.py build`, `idf.py flash monitor`. When the panic fires, `idf.py monitor` runs the backtrace through the ELF and gives you source-line attribution — e.g. `stratum_api.c:237` or `asic.c:119`. That file:line tells you whether to file a GitHub issue on bitaxeorg/ESP-Miner (real bug) or fix your config (user error). This is the difference between 'my Bitaxe is broken' and 'I've reproduced a bug'.

Measure the TPS546 rails under load on Gamma / GT. With the miner attempting to boot, probe VOUT at the TPS546 with a multimeter. Gamma core rail is nominally 1.1-1.3V (firmware configurable). Drops below spec or oscillation on a scope = failing TPS546 input filtering or the IC itself. If VIN 5V is clean but the output rail collapses, 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.

Resolder the ESP32-S3-WROOM module or XT30 connector if suspect. ESP32-S3 modules on 24/7 miners thermally cycle hard and solder pads under the module can fatigue, producing intermittent crashes that look exactly like firmware bugs. Bitaxe GT's XT30 is a known weak point — connector pins walk out under vibration (see dedicated bitaxe-gt-xt30-connector-loose page). Reflow the module with a bottom preheat stage at ~150C and top hot-air at roughly 300C for 30 seconds. Reseat / resolder XT30 pins with fresh solder.

Cross-reference firmware against your exact board revision before flashing. Bitaxe Gamma shipped as 600, 601, 602, and 'Gamma 600 ESP MON16' variants — flashing a 601 image on a 602 board causes obscure I2C init crashes (ESP-Miner issue #1291 `I2C handle not initialized` after v2.8.0). Ultra boards 202, 204, 205, 207 have similar divergence. The GitHub releases page explicitly notes which image matches which board sticker. Read it, don't guess. Wrong image on the wrong board = instant reboot loop.

Stop DIY and ship to D-Central ASIC + Bitaxe Repair when any of these are true: full erase_flash plus fresh factory image still boot-loops; rails measure 0V after forced download mode; visible burn / cracked solder / bulging cap / scorched trace; cooked-electronics smell; the ESP32-S3 does not enumerate on USB-C with BOOT held; or you lack a preheat + hot-air rework setup for module-level repair. Book a slot at https://d-central.tech/services/asic-repair/. We stock salvaged-grade ESP32-S3-WROOM modules, TPS546 bucks, EMC2101 controllers, and BM1366 / BM1368 / BM1370 ASICs for every Bitaxe variant. 3-7 business day turnaround on Bitaxe-class work. Canada / US / international shipping.