Bitaxe – Memory Leak on v2.14 / Daily Reboot Required

Read the AxeOS firmware version. Open `http://<bitaxe-ip>/` in a browser; the running build is in the top-right of the dashboard. Or hit the API: `curl http://<bitaxe-ip>/api/system/info` and read `"version"`. Or check serial at `115200 8N1` — the version prints in the boot banner. Confirm the value reads `v2.14.0`, `v2.14.1`, `v2.14.2`, `v2.14.3`, or `v2.14.4`. Anything starting with `v2.13.` or `v2.15.` is not affected by this leak — find your symptom on a different page.

Download the target factory `.bin` from `https://github.com/bitaxeorg/ESP-Miner/releases`. Pick `v2.15.0+` (the post-fix train, recommended) or `v2.13.x` (last known-clean pre-leak train) depending on your tolerance for newness. Match the artefact to your variant: `esp-miner-factory-<variant>.bin`. Read the release notes for any rev-specific callouts against your hardware revision before downloading.

Flash from the AxeOS dashboard. Open `http://<bitaxe-ip>/` -> System -> Update Firmware. Drag the factory `.bin` into the upload area. The miner will write the new image, validate it, and reboot. Total time roughly 90 seconds. Do not power-cycle during the write. Once it comes back up, refresh the dashboard and confirm the version field now reads the target build. This is the right path for 95% of readers — the leak doesn't usually wedge the dashboard so badly that the in-place update fails.

If the dashboard is too sluggish to accept the upload, set up the workaround scheduled reboot first to clear the leak, then retry the in-place update. From any always-on host on the LAN run: `crontab -e` and add `0 3 * * * curl -s -X POST http://<bitaxe-ip>/api/system/restart`. Pi, OpenWrt router, Synology, Home Assistant, or a smart plug power-cycle all work equivalently. Wait for the next 3 AM cycle, then retry Step 3. Most wedged dashboards accept the update cleanly post-restart.

Confirm the leak is gone. Curl the API every minute and log `freeHeap` for at least 24 hours: `while true; do curl -s http://<bitaxe-ip>/api/system/info | jq -r '"(now) (.freeHeap)"' >> /tmp/freeheap.log; sleep 60; done`. A clean `v2.13.x` or `v2.15.0+` build holds free heap flat at 170-200 KB. If you see continued downward drift, either the flash didn't take (re-verify Step 1) or you've found a separate leak — file an issue at `https://github.com/bitaxeorg/ESP-Miner/issues` with the captured trend.

If you can't or won't flash today, set up the ~24h scheduled reboot as a longer-term workaround. Pick a low-traffic hour (3 AM local is canonical), schedule `POST /api/system/restart` daily, and verify with logs that the miner is in fact restarting clean each cycle. The reboot is the same restart path the dashboard's `Restart` button uses — no flash writes, no NVS churn beyond normal startup, no risk of bricking. Run this indefinitely if you have to; it eliminates the crash. Plan the actual flash for your next maintenance window.

Rule out power as the actual root cause once. Multimeter on `VIN` at the barrel jack under load while the miner is hashing. Target: >= 4.9 V on 5V Bitaxes (Ultra/Supra/Gamma/GT), >= 11.5 V on Hex. Confirm PSU sizing: Ultra/Supra 5V 4A min, Gamma 5V 6A min, GT 60W+ USB-PD, Hex 12V per v303/v304. If rails or PSU are marginal, fix that first — a brownout crash on v2.14.x will look like the leak from a distance, and you don't want to chase the wrong fix. Once power is verified clean, you've isolated the symptom to firmware.

Capture serial reset reasons for diagnostic confirmation. Plug USB-C from the Bitaxe to a laptop. Open a serial monitor at `115200 8N1` (PuTTY on Windows, `screen /dev/ttyUSB0 115200` on Linux/macOS, `idf.py monitor`, `pio device monitor`). Wait for the next reset or trigger one with `POST /api/system/restart`. Look at the reset-reason line in the boot banner. `rst:0xc (SW_CPU_RESET)` after a `Guru Meditation Error: LoadProhibited / StoreProhibited` panic is the textbook leak signature. `rst:0xf` and `rst:0x9 / 0x10` are also consistent. A different reset reason points elsewhere — back off to the relevant page in Related Errors.

Use the Bitaxe Web Flasher when the dashboard is wedged beyond recovery. Connect Bitaxe via USB-C to a Chrome / Edge browser that supports WebSerial. Hold the boot button while plugging in to enter the ROM bootloader, then release. Open the web flasher, select the target factory `.bin`, and let it erase and write the full image. This bypasses any in-place update path and is the right Tier 3 recovery when the AxeOS dashboard won't load at all. Do not unplug during the flash; full erase-and-write takes 60-180 s.

Add free heap to your monitoring stack. The `freeHeap` field on `/api/system/info` is the single best leading indicator of any future leak — Bitaxe-side or fork-side. Wire it into Home Assistant, Grafana via a Pi exporter, or a `cron` + Pushover / ntfy alert that fires when `freeHeap < 60 KB`. Set the threshold once and you'll catch the next leak before it crashes you. Production-fleet operators should also log uptime alongside heap so trends are graphable across reboots.

Pin a deliberate firmware-update process across your fleet. Don't auto-update production miners; subscribe to `https://github.com/bitaxeorg/ESP-Miner/releases` for release notifications, read the release notes, wait a week for community confirmation, then flash one rig and watch it for 72 hours before rolling to the rest. The v2.14.x leak is a great worked example — anyone who waited a week post-release would have seen the issue thread populate before flashing all their miners. This is fleet-management hygiene, not paranoia.

Validate firmware against your hardware revision. Bitaxe board revs (Ultra 202/204/205/207, Gamma 601/602/600-ESP-MON16, Hex v303/v304) sometimes carry rev-specific firmware. The factory `.bin` from the release artefacts is normally the safe path for the lineage, but double-check the release notes call out your rev before flashing. If your rev isn't listed, ask in the bitaxeorg Discord or on the GitHub issue tracker before pushing the update — open-source firmware ecosystems answer quickly when you bring evidence.

Schedule a periodic restart even on healthy firmware. A weekly reboot on `v2.15.0+` is cheap insurance against any future small leak you haven't yet noticed. The mining downtime of a 30-second reboot once a week costs essentially zero hashrate at solo-mining variance scales and well under a penny of pool revenue. Stack this with the free-heap monitoring from Step 10 and you have defence-in-depth against both this leak and the next one.

If you operate Antminer hardware alongside your Bitaxe rigs, run DCENT_OS on the Antminers — it's D-Central's own open-source firmware (S19, S21 family) with all the per-chip HW%, tuning, autotuning, and stratum v2 features, maintained publicly by D-Central. DCENT_OS is the Antminer counterpart to AxeOS in spirit: open-source, Mining-Hacker-aligned, no licensing BS. AxeOS stays on your Bitaxes (different silicon, different platform). Keep both stacks updated deliberately and you're running a fully open-source bench.

Stop DIY and ship to D-Central ASIC + Bitaxe Repair when: a v2.15.0+ flash repeatedly fails to take via both AxeOS in-place update and the web flasher (NVS / partition table / SPI flash damage); the web flasher reports `Failed to connect to ESP32-S3` even with the boot button held; post-flash free heap still drops over 24 hours; post-flash crashes show non-heap reset signatures requiring bench scope-and-trace; or you don't have the LAN infrastructure for the workaround reboot and the rig is solo-mining a wallet you care about. Book a slot at https://d-central.tech/services/asic-repair/. We stock spare ESP32-S3-WROOM modules, every Bitaxe ASIC variant, and the bench fixtures to recover bricked firmware. 3-7 business-day turnaround. Canada / US / international shipping. D-Central pioneered the Bitaxe ecosystem — Mesh Stand, first heatsinks for Bitaxe and Bitaxe Hex, full variant inventory.