Bitaxe Gamma – Zero Hashrate Pulling Only 5W (Warm Restart Fails)

Cold power-cycle the miner. Physically unplug the 5V barrel jack (or USB-C on applicable revs), count a full 30 seconds out loud so capacitor discharge on the 5V rail completes, then plug it back in. Do NOT use the `Restart` button in AxeOS or `POST /api/system/restart` - those are exactly the paths that fail on this bug. This single action recovers hashing in 95%+ of reports that match the warm-restart signature.

Verify the PSU is appropriate. Use the OEM Bitaxe Gamma power brick or a quality `5V / 6A+` equivalent rated for sustained `30 W`. Cheap phone chargers, undersized USB adapters, and long or thin USB-C cables cause rail sag under load that masquerades as the warm-restart bug. D-Central's Bitaxe-compatible PSUs are spec'd for full-load delivery.

Re-seat the barrel connector and inspect for oxidation. Oxidation or mechanical slop on the 5V barrel jack creates intermittent rail drops under load that look identical to this bug. Wiggle-test the connector once the Gamma is hashing - if power or hashrate dips with finger pressure, replace the cable or the jack. On GT boards with `XT30`, see the dedicated XT30-loose walkthrough.

Confirm chip type and firmware compatibility before any flash. AxeOS `System Info` should list `BM1370` for Gamma / GT. Flashing the wrong `esp-miner.bin` for your chip family (a `BM1366` image on a `BM1370` board, for example) bricks the ASIC link and produces symptoms that look just like the warm-restart bug. When in doubt, verify the board silkscreen revision against the ESP-Miner release notes.

Update AxeOS to the latest stable release. Use the AxeOS web UI OTA at `Settings -> Firmware Update`. The ESP-Miner maintainers have shipped several boot-path hardening changes since `v2.4.2` where this issue was first pinned - longer `TPS546` off-delays before ASIC init and firmer ASIC reset sequencing. Flashing forward is the #1 community-recommended mitigation. OTA switches between two partitions, so a failed update rolls back rather than bricks.

Capture the full boot log over serial. Plug USB-C into the Gamma, open a `115200 baud` serial terminal (`screen /dev/tty.usbmodem*` on macOS/Linux, PuTTY or the ESP-IDF monitor on Windows), and power the board. Copy the first ~10 seconds of output. Look for `TPS546 Status:` lines, `device_config: ASIC:` confirmation, any `E (...)` error lines, and the `ASIC init` completion. A healthy boot has no `E (...)` lines and ends with a clean stratum handshake.

Reconfirm stock settings before further tuning. In AxeOS, set frequency to `485 MHz` and core voltage to `1100 mV` (Gamma stock). Do not overclock while chasing this bug - overclocking does not cause it, but it muddies every other diagnostic reading. Tune up again only after the warm-restart issue is eliminated.

Full factory reset the NVS. In AxeOS: `Settings -> Reset to Factory Defaults`. Reconfigure WiFi and pool. Rationale: a corrupted NVS block can confuse the ASIC-init routine and deliver warm-restart-like failure even on a cold boot. Post-`v2.0.0` AxeOS requires a valid manufacturing data partition - if yours was wiped during earlier experimentation, you may need the dedicated NVS corruption recovery flow.

USB Web Flasher full recovery. If OTA won't complete or the device is stuck between partitions, use D-Central's Bitaxe Web Flasher guide. This is a USB-serial full re-flash that bypasses OTA partition logic entirely. Takes roughly 5 minutes. Recovers 99% of firmware-state issues on Gamma and GT.

Monitor power draw with an external wattmeter. An in-line USB-C power meter (any Chargerlab KM002C-class device) or a Kill-A-Watt on the adapter's AC side catches rail issues the AxeOS UI can miss. A healthy Gamma under load draws `15-18 W` sustained with no dips below `10 W` except during legitimate restarts. Persistent dips point at PSU or cable, not silicon.

Scope the 5V rail at the barrel under load. DC-coupled oscilloscope, `20 MHz` bandwidth limit, probe on the board side of the barrel while the Gamma is hashing. Expected: `4.95-5.10 V` DC with under `50 mV` ripple and no sag below `4.7 V` on load transients. Sag into the `4.5 V` range means your PSU or cable is the root cause - no firmware work will fix it until you address the supply.

Scope VCORE at the ASIC package. DC-coupled, low-impedance ground, probe on one of the `TPS546` output ceramic caps near the `BM1370`. Expected: `1.05-1.15 V` DC with under `20 mV` ripple during hashing. If VCORE reads near `0 mV` while AxeOS reports the nominal request, the `TPS546` has shut off its output - this is the `Status: 0x2841` pathology from issue #1188, a different failure mode that needs Tier 3 VRM work.

Reflow the `BM1370` if the chip is confirmed dead. If cold power-cycle does not recover hashing AND VCORE measures healthy AND firmware is latest stable AND both soft and hard reset fail, the `BM1370` itself may have taken damage. Pre-heat `150 C` bottom-side, top-side hot air at `310-330 C` for about `30 s`, let it cool naturally, re-apply thermal paste (Arctic MX-6 or equivalent), reassemble. Same silicon family as Antminer S21, same reflow tolerances.

Replace the `TPS546` voltage regulator if you see persistent `Device ID mismatch` or `Status: 0x2841` and the part is hot or visibly discoloured. Source the `TPS546D24A` or `D24S` from Digi-Key or Mouser - note the `D24A` vs `D24S` variant, as AxeOS firmware `v2.7.x+` checks for both but earlier firmware only recognised one. Fine-pitch QFN rework: hot air only, no soldering iron, proper flux, controlled pre-heat.

Clean flux residue and debris near the VRM. `BM1370` boards are tightly packed - flux bridging a `TPS546` sense line can look identical to a regulator fault. Use isopropyl `99%`, a soft brush, and compressed air. Do not use ultrasonic cleaning on a populated Bitaxe unless you have removed the ESP32 module first - the module's shielding is not ultrasonic-safe.

Stop DIY. Board has visible damage (burnt `TPS546`, discolouration near `BM1370`, swollen ceramic caps, burnt-plastic smell). You've reflowed the `BM1370` once and the bug returned within two weeks. Multiple Gammas in your fleet exhibit identical warm-restart failure - that's a PSU, grid, or ESD environment issue a bench can isolate in minutes. Book a D-Central Bitaxe repair slot.

D-Central bench process: full serial-log capture, `TPS546` and VCORE rail scope traces under load, `BM1370` hot-air replacement from graded stock if needed, post-repair 24-hour burn-in at stock frequency, re-shipped with a QC log. We track warm-restart bug recurrences against firmware revision and chip lot internally - every unit we repair makes the next repair faster.

Ship safely. Anti-static bag, bubble wrap, rigid outer box. Include a one-page note covering observed symptoms, AxeOS version, board revision, PSU used, whether cold power-cycle intermittently recovered hashing or never did, and how long the unit had been in service. This saves diagnostic time at the bench, which saves you money. Canada-wide and worldwide shipping welcomed.