Bitaxe – NVS Corruption / Manufacturing Data Missing (2.0.0+)

Stop pulling the cable on a running Bitaxe — every shutdown from now on goes through the AxeOS web UI's `Restart` or `Power Off` button, then unplug. This single behavioural change closes 70% of NVS-corruption tickets in D-Central's queue. The Bitaxe is a real computer running a journaled key/value store on flash, and that store needs a clean shutdown to commit its last write. Treat it accordingly. If your home setup loses power involuntarily, add a small UPS — that's the next step.

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. Power the Bitaxe via the barrel jack and capture the boot log. Save it to a file. You'll reference the exact error string (`nvs: open failed`, `CRC mismatch`, `ESP_ERR_NVS_INVALID_STATE`) through every subsequent step.

Browse to the Bitaxe's IP address. If the AxeOS dashboard loads at all, screenshot the model field, serial number, MAC, and firmware version — confirms the failure pattern and gives you a known-state reference. If reachable, try `Settings → System → Restore Factory Defaults`. On builds where this works, it rebuilds the AxeOS NVS namespaces without touching factory metadata. Reboot, recheck. If it clears the corruption, you're done at Tier 1; if it doesn't, the corruption is deeper than the UI can reach, continue to Tier 2.

If the corruption appeared right after a firmware update attempt, power-cycle once more — the device may be stuck mid-OTA with `OTA_DATA` pointing at a half-written slot, and a power cycle can roll back to the previous good slot. Do not re-attempt the OTA until Step 7 (NVS health check) confirms the partition is intact. Repeated OTA attempts on a Bitaxe with a damaged NVS will compound the corruption, not fix it.

Photograph the silkscreen revision sticker on the board near the ESP32-S3 module — `Gamma 602`, `Supra 401`, `Hex v304`, `Ultra 207`, etc. Save the photo with your purchase records. You'll need this exact string in Tier 3 to pick the correct factory `.bin`. Wrong-revision firmware causes exactly the corruption pattern you're trying to fix, and is one of the top three failure modes D-Central diagnoses on inbound boards.

Install esptool with `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). Hold the BOOT button while plugging in if your build needs it; most newer Bitaxe revisions auto-enter bootloader on USB connection. Verify connectivity: `esptool.py --chip esp32s3 -p <PORT> chip_id`.

DUMP NVS BEFORE YOU ERASE ANYTHING — this is your insurance: `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 your serial number, MAC, and calibration values. Even a CRC-failing partition usually has readable string data. Skip this step and you cannot blame anyone but yourself when the unit reboots with serial `0`.

Dump and decode the partition table to verify geometry: `esptool.py --chip esp32s3 -p <PORT> read_flash 0x8000 0x1000 ptable.bin`, then `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). If the offsets are different, wrong-board firmware was flashed at some point — note this and skip directly 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, configure your home Wi-Fi, configure pool URL and worker name. Verify the dashboard now shows correct model, serial, MAC. If serial / MAC repopulate from eFuses (newer AxeOS builds), you're done. If they're still blank, factory data lived only in NVS — go to Step 10 to merge from your dump.

If the surgical erase didn't restore serial / MAC, rebuild a clean NVS image from your Step 7 backup. Decode `nvs-backup.bin` and pull out the recoverable key/value pairs into a CSV (one row per: namespace, key, type, encoding, value). Generate a new image: `python -m esp_idf.nvs_partition_gen.nvs_partition_gen generate factory.csv nvs-restored.bin 0x6000`. Write it back: `esptool.py --chip esp32s3 -p <PORT> write_flash 0x9000 nvs-restored.bin`. This is fiddly — the namespace and key names must match what AxeOS expects. They're documented in `github.com/skot/ESP-Miner` under `main/`.

Identify the correct factory `.bin` for your board revision from Step 5's photo. Open `github.com/skot/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). Keep both files for later reference and updates.

Full erase + factory write — the reset button: `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, verify model/serial/MAC populate correctly.

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.

Verify under load: run the Bitaxe at stock settings for 30 minutes after restoration. Watch the AxeOS dashboard — model field stays populated, serial doesn't reset, MAC stays consistent across power-cycles, hashrate matches the variant nameplate (`Supra ~700 GH/s`, `Gamma ~1.2 TH/s`, `Hex ~3.0 TH/s` indicative). Power-cycle deliberately three times during the 30 minutes (clean shutdown via web UI, then unplug). If anything drifts back to corrupt state within the test, the underlying flash has wear damage and Tier 4 is your destination.

Add a UPS for production miners — single best NVS-corruption insurance for any 24/7 home Bitaxe setup. APC Back-UPS 600 / CyberPower CP685AVR class units run CAD $80-$150, protect through brownouts, line-voltage dips, momentary outages, and accidental cable disconnects. ROI is single-digit days when you factor in the operator time NOT spent on `esptool read_flash` recovery. Same UPS can cover your home router and Bitaxe together — your stratum connection stays up too.

Stop DIY when: (a) `esptool read_flash` reports SPI-layer hardware errors that don't clear with baud reduction, (b) `erase_flash` succeeds but `write_flash` verification fails on multiple sectors, (c) a clean factory reflash boots once then re-corrupts within a week with no triggering event, (d) WROOM module shows physical damage — burn marks, lifted pads, cracked package, scorched silkscreen near the antenna, or (e) you've spent more than two hours and the bench is faster and cheaper. Book a D-Central Bitaxe repair slot.

D-Central bench process for NVS corruption: USB-C serial diagnostic and full-flash dump under controlled bench power, partition-table validation against the board's silkscreen revision, NVS extraction with bit-error analysis, OTA partition rebuild, factory `.bin` flash with the correct image for your specific board, and — when SPI flash itself is failing — desolder/reflow of the WROOM module with fresh-stock replacement. Final step: 24-hour burn-in at nameplate on D-Central's bench stratum to confirm calibration holds and NVS retains writes across power cycles. 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 2), 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 corruption was rail-driven — D-Central cannot reproduce a rail-driven write fault if the rail is sitting on your desk. Canadian, US, and international shipping all welcomed.