Bitaxe – Voltage Change Not Persisting After Reboot

Hard-refresh the AxeOS dashboard before you trust anything: `Ctrl+Shift+R` on Windows / Linux or `Cmd+Shift+R` on Mac, or open the dashboard in an incognito / private window. A surprising fraction of `voltage didn't save` tickets are stale browser cache showing the value you typed last session while the chip actually reverted to stock. If the value disappears on hard refresh, your save genuinely failed and you continue to Step 2. If it survives the refresh, you're done at Step 1 - it saved, your previous reading was just cache.

Pull ground truth from the REST API, not the dashboard: `curl http://<bitaxe-ip>/api/system/info` and read `coreVoltage`, `frequency`, `autotune`, `flipscreen`, etc. The API hits the live NVS-loaded config, bypassing every browser caching layer. Do this *before* a save, *after* a save, and *after* a reboot. Persistence is confirmed only when all three readings show the new value across a power cycle. Save the JSON output for your records.

Disable autotune and retest. Navigate to the AxeOS autotune settings, toggle autotune off, save. Reboot. Re-enter your `coreVoltage` and `frequency` manually. Reboot again. Verify via `/api/system/info`. If the manual values now persist, you weren't broken - autotune was overwriting your operator-set values every cycle with its own derived stability point. Re-enable autotune only if you want adaptive tuning; for pinned static values, leave it off and tune by hand.

Screenshot the dashboard, capture API output, and document the failure pattern: dashboard reading before save, success-toast moment, dashboard reading after reboot, `/api/system/info` JSON after reboot. This documentation is what you'll attach to a GitHub issue against `bitaxeorg/ESP-Miner` if the cause is firmware regression, and what D-Central will reference if the unit ends up on the bench. The right reproduction trail saves hours of bench diagnostic time.

Connect a USB-C *data* cable (not charge-only - half of `esptool can't find the chip` tickets are the wrong cable) and open a serial terminal at `115200 8N1`. Use `screen /dev/cu.usbserial-* 115200` on Mac, `pio device monitor` if PlatformIO is installed, PuTTY on Windows, or Arduino IDE Serial Monitor as a last resort. Trigger a settings change from the dashboard while watching the boot log scroll. Save the log. Look for `nvs_commit failed`, `ESP_ERR_NVS_PAGE_FULL`, `ESP_ERR_NVS_NO_FREE_PAGES`, `ESP_ERR_NVS_INVALID_HANDLE`, or `nvs_set_blob` errors.

Install esptool: `pip install esptool` (Python 3.7+). Confirm with `esptool.py version`. Identify the correct serial port: `/dev/cu.usbserial-*` on Mac, `/dev/ttyUSB*` or `/dev/ttyACM*` on Linux, `COM*` on Windows (Device Manager). Most newer Bitaxe revisions auto-enter bootloader on USB connection; older ones need the BOOT button held during plug-in. Verify connectivity: `esptool.py --chip esp32s3 -p <PORT> chip_id` should return the chip ID and revision.

DUMP NVS BEFORE YOU ERASE ANYTHING - `esptool.py --chip esp32s3 -p <PORT> -b 460800 read_flash 0x9000 0x6000 nvs-backup.bin`. If the read errors out, drop the baud rate to `115200` and retry. Once you have a clean dump, run `strings nvs-backup.bin | head -50` or open it in a hex editor and scan for the values you've been trying to save. This dump is your insurance: if the surgical erase doesn't restore proper persistence, you can rebuild from the dump rather than starting over.

Verify partition geometry: `esptool.py --chip esp32s3 -p <PORT> read_flash 0x8000 0x1000 ptable.bin`, then decode with `python -m esp_idf.gen_esp32part ptable.bin` (or the equivalent script in your IDF install). Confirm `NVS` is at offset `0x9000` for `0x6000` (24 KB), marked read/write, unencrypted (or correctly keyed if you're running NVS encryption). If the offsets are wrong or the partition is marked encrypted with a key you don't have, a previous bad flash wrote a non-default partition table - go to Step 11 to reflash the correct factory image.

Surgical NVS-only erase, preserves OTA partitions and bootloader: `esptool.py --chip esp32s3 -p <PORT> erase_region 0x9000 0x6000`. Power-cycle. AxeOS first-boot rebuilds the NVS structure with default values - the Bitaxe will fall back to AP mode `Bitaxe_XXXX`. Connect to that AP, reconfigure home Wi-Fi and pool, then enter your `coreVoltage` and `frequency` and save. Reboot three times in a row. Verify via `curl /api/system/info` after each reboot that the values held. If they hold across all three cycles, the previous corrupt journal page was the cause - you're done.

If surgical erase didn't fix persistence, the AxeOS firmware build itself may have a regression in the NVS-commit path. Identify the exact AxeOS version you're running (visible in dashboard or via `/api/system/info`). Check `github.com/bitaxeorg/ESP-Miner/issues` for filed regressions matching your symptom and version. If your build matches a known buggy release, plan to update to the latest stable in Step 11. If you're already on the latest stable and the issue is reproducible, *file a new GitHub issue* with your serial console capture, board revision, repro steps, and `/api/system/info` JSON before/after - this is how the open-source ecosystem fixes regressions.

Identify the correct factory `.bin` for your board revision from the silkscreen. Open `github.com/bitaxeorg/ESP-Miner/releases` and match the silkscreen exactly: `factory_gamma_602.bin` for Gamma 602, `factory_supra_401.bin` for Supra 401, `factory_hex_304.bin` for Hex v304, etc. Download the *factory* image (includes bootloader + partition table), not the OTA image (firmware only). Save the file - keep it for future reference. Note: naming has shifted across releases; match the format on the current releases page exactly.

Full erase + factory write: `esptool.py --chip esp32s3 -p <PORT> erase_flash` (wipes all 4/8 MB), wait for completion, then `esptool.py --chip esp32s3 -p <PORT> --baud 460800 write_flash 0x0 factory-<board-rev>.bin`. Wait for `Hard resetting via RTS pin`, then power-cycle by unplugging USB-C and the barrel. AxeOS first-boot will be slow (~30 seconds) as every region rebuilds. Connect to the AP `Bitaxe_XXXX`, configure Wi-Fi and pool, enter your tune. Verify persistence via `/api/system/info` across three power cycles.

If you prefer a UI to esptool, the Bitaxe Web Flasher at `bitaxe.org` is the equivalent of Step 12 in a browser. Select your board revision, follow the prompts. Limitation: the Web Flasher does not let you dump NVS first - for that you need local esptool from Step 7. Best practice: dump locally with esptool, then use the Web Flasher for the rewrite if you prefer the UI flow. Either path lands the same factory `.bin` on the chip and produces the same persistence behaviour.

Persistence burn-in test: set a known `coreVoltage` and `frequency` (off-default values you'll recognize, e.g., `1180 mV` and `490 MHz`). Verify via `/api/system/info`. Power-cycle by unplugging the barrel jack for 30 seconds. Boot back up, verify `/api/system/info` shows the same values. Repeat the cycle five times, capturing `/api/system/info` after each. If all five reboots show the same values, persistence is healthy and the previous failure was firmware-side or behavioural. If any of the five reverts, the underlying flash has wear damage - Tier 4 is your destination.

Add a UPS for production miners. Power-loss-during-`nvs_commit` is the dominant *real* persistence failure when stale-cache and autotune are ruled out. Entry-level units like APC Back-UPS 600 / CyberPower CP685AVR (CAD $80-$150) protect through brownouts, line-voltage dips, momentary outages, and accidental cable disconnects. ROI is single-digit days when you factor in operator time NOT spent on `esptool` recovery. The same UPS covers your home router so the AxeOS dashboard remains reachable when you most need it.

Stop DIY when: (a) latest stable AxeOS is flashed clean and a surgical NVS erase has been completed, but voltage still reverts after every reboot - wear-failed flash sector that software cannot fix; (b) `esptool write_flash` reports verification mismatches on the NVS region on multiple attempts; (c) persistence holds for a few hours then fails again - intermittent bit-error pattern; (d) WROOM shows visible damage (burn marks, lifted pads, scorched silkscreen); or (e) more than two hours of operator time has been sunk and the bench is faster and cheaper. Book a D-Central Bitaxe repair slot.

D-Central bench process for persistence failure: USB-C serial diagnostic and full-flash dump under controlled bench power, sector-level wear analysis with iterative verification rewrites of the NVS band, partition-table validation against silkscreen revision, factory `.bin` flash with the correct image, and - when SPI flash itself is failing - desolder and reflow of the WROOM module with fresh-stock replacement. Final step: 24-hour persistence burn-in on the bench (we save a known tune, power-cycle every hour for 24 hours, confirm the value held every cycle) before the unit ships back. Diagnostic data returns with the board, not just a sticker.

Ship safe to D-Central: anti-static bag, padded box, at least 3 cm of foam on every side. Include the exact symptoms observed (with serial-log excerpts if you captured them in Step 5), firmware version last running, the `nvs-backup.bin` from Step 7 if you got it (USB stick or email it ahead), the silkscreen board revision, and your contact info. Ship the PSU and cable too if there's any chance the original failure was rail-driven - D-Central cannot reproduce a rail-driven `nvs_commit` interruption if the rail is sitting on your desk. Canadian, US, and international shipping all welcomed.