NerdNOS – Firmware Flash Incompatible Hardware

Identify the board product + revision + ASIC chip family before flashing anything. Power down. Read the silkscreen on the PCB for the full product name (`Bitaxe Ultra 204`, `Bitaxe Supra 401`, `Bitaxe Gamma 602`, `NerdAxe 500G`, `NerdQAxe`, etc.). With a `10x` loupe or phone camera at `2x` zoom, read the lasered marking on each ASIC: `BM1366`, `BM1368`, or `BM1370`. On multi-chip boards, confirm all chips read the same family. Photograph everything. That triple - board + revision + chip - is the only input to target-matching a NerdNOS build.

Connect USB-C to a PC with no main PSU attached. Unplug the board's main barrel / XT30 / USB-C power. Plug a known-good USB-C data cable (many USB-C cables are charging-only and lack D+/D-) from PC to board. The ESP32-S3 takes USB bus power for bootloader access. Confirm Device Manager / `lsusb` / `dmesg` shows a new `USB JTAG/serial debug unit` or `ESP32-S3` device (VID `0x303A`). If not, hold `BOOT`, tap `RESET`, release `BOOT` to force the mask-ROM bootloader. No enumeration after that = MCU damage, go to Tier 4.

Check the NerdNOS supported-target matrix for your exact hardware. Open `https://github.com/shufps/nerdnos/releases` and read the latest release notes in full. Find the supported-targets list - sometimes in the release description, sometimes in a `boards/` directory or `SUPPORTED_HARDWARE.md` file in the repo root. Confirm your board + revision + chip family is explicitly named. If it is: note the exact `.bin` filename. If it is not: NerdNOS does not support your board yet - flash stock firmware for your hardware instead. Subscribe to the relevant issue on the NerdNOS tracker to get notified when board support lands.

Flash the correct `.bin` over USB-C. If NerdNOS ships a WebSerial flasher for your release, use it - Chrome or Edge (WebSerial is not in Firefox or Safari), pick the serial port, select or upload your verified-correct `.bin`, click Flash. If no WebSerial tool exists, use `esptool.py`: `pip install esptool`, then `esptool.py --chip esp32s3 --port COMx --baud 921600 erase_flash` to wipe the full flash region, then `esptool.py --chip esp32s3 --port COMx --baud 921600 write_flash 0x0 <your-target-matched-bin>`. Wait the full `30 - 60 s` for write + verify. Do not unplug, close the tab, or let the PC sleep the USB hub mid-write.

Reconnect main PSU and watch for first-boot recovery. Unplug USB-C. Reconnect the board's main power source. Wait: OLED / TFT splash within `~3 s`, Wi-Fi AP broadcast within `~15 s`. Connect to the AP, complete the first-boot wizard - Wi-Fi SSID + password, pool URL (solo.ckpool.org:3333 for solo lottery, public-pool.io:21496 for public-pool), worker name, stock frequency and voltage. The factory flash wiped NVS, so you re-enter all of this. Write down your pool URL and worker before flashing next time.

Validate `count_asic_chips` on the status page / API. Once NerdNOS is on Wi-Fi, query the status endpoint. Confirm `count_asic_chips` matches your board: `1` for Ultra / Supra / Gamma / NerdAxe 500G, `2` for Gamma Turbo / GT, `4` for NerdQAxe, `6` for Hex. If count is wrong (typically `0`), the flash did not target the correct hardware - go back to Step 3, re-verify the release notes name your board explicitly, reflash. `count_asic_chips` matching expectation is the single most reliable post-recovery sanity check.

Burn in at stock for 30 minutes before declaring recovery. Leave the board hashing at stock frequency and voltage. Watch NerdNOS for: stable `Vin`, HW% below `1 - 2%`, no `Power Fault Detected`, steady ASIC temperature, pool worker showing green on the stratum side. A 30-minute burn-in catches any pre-existing hardware fault that the non-functioning firmware was masking. Most post-recovery boards settle in within 10 minutes and run indefinitely; the ones that don't usually reveal marginal hardware needing Tier 4.

Attach a USB serial terminal at `115200 baud` for live target verification. Use PuTTY (Windows), `screen /dev/ttyACM0 115200` (Linux), or Arduino IDE Serial Monitor. Reset the board after flash and watch the cold-boot banner. A correctly-targeted NerdNOS image prints the board config name and ASIC driver family in the first few seconds: `board: bitaxe_ultra_204 / asic: BM1366 / count = 1`. A wrong-target flash prints `unsupported board config`, `ASIC init failed`, `chip detection timeout`, or silently hangs at the board-init stage. Fastest way to confirm target-match without waiting for Wi-Fi + API.

Wipe NVS before reflashing if selftest still loops after a confirmed-target flash. If you flashed the matching-target `.bin` cleanly but the board immediately re-enters selftest loop, a stale NVS entry may be holding bad config from the prior wrong-target firmware. Use `esptool.py --chip esp32s3 --port COMx erase_region 0x9000 0x6000` to wipe NVS only, preserving the application image. Cold-boot - first boot enters wizard mode fresh. Saves a full reflash cycle when only NVS is carrying the problem.

Fall back to stock AxeOS / ESP-Miner if NerdNOS doesn't support your board yet. NerdNOS is optional - a performance-and-monitoring-focused alternative to stock. If the current NerdNOS release matrix doesn't include your board, flashing stock AxeOS (from `bitaxeorg/ESP-Miner releases` for Bitaxe, `bitaxeorg/bitaxeHex` for Hex, `BitMaker-hub/ESP-Miner-NerdAxe` for NerdAxe) returns the board to a known-working state immediately. File or watch a NerdNOS board-support issue for your hardware, and re-flash NerdNOS once official support lands.

Verify the `.bin` source before flashing anything from outside official NerdNOS / AxeOS / ESP-Miner repos. Malicious or tampered firmware for open-source ESP32-S3 miners has been spotted in Discord drops, Telegram channels, random GitHub mirrors. If the `.bin` did not come from github.com/shufps/nerdnos, github.com/bitaxeorg/ESP-Miner, github.com/bitaxeorg/bitaxeHex, or github.com/BitMaker-hub/ESP-Miner-NerdAxe directly, do not flash it. Community forks should publish checksums in release notes; cross-reference. Community best practice; no confirmed NerdNOS malware in the wild as of 2026-04.

Handle mixed Bitaxe / Nerd / NerdNOS fleets with per-target folders. Home miners running a Bitaxe Ultra on AxeOS, a Bitaxe Supra on Public-Pool firmware, a NerdAxe on ESP-Miner-NerdAxe, and a Bitaxe Gamma on NerdNOS end up with five firmware variants across three chip families. Keep folders by target: `~/firmware/bitaxe-ultra-204-axeos/`, `~/firmware/bitaxe-gamma-602-nerdnos/`, `~/firmware/nerdaxe-500g-espminer/`. Label boards with masking tape: `ULTRA-204-AXEOS`, `GAMMA-602-NERDNOS`. Never batch-flash across a mixed-target fleet.

Use `esptool.py` directly when NerdNOS WebSerial flasher fails or is unavailable. `pip install esptool`. Wipe: `esptool.py --chip esp32s3 --port COMx --baud 921600 erase_flash`. Flash: `esptool.py --chip esp32s3 --port COMx --baud 921600 write_flash 0x0 nerdnos-bitaxe-ultra-204-vX.Y.Z.bin`. CLI output tells you exactly what happened: timeout, checksum mismatch, MD5 verify fail, success. Espressif's toolchain is the reference implementation; any browser WebSerial tool wraps it. For stubborn flashes, CLI is always more informative.

Force mask-ROM bootloader for power-loss-mid-flash recovery. If the Web Flasher or `esptool.py` crashed mid-write, Windows ate the USB hub, or the PC slept during flash, the application partition may be corrupted AND the bootloader may fail to hand off. Hold `BOOT` on the board, connect USB-C, tap `RESET`, release `BOOT` - forces mask-ROM bootloader regardless of flash state. Mask-ROM is immutable silicon; no flash event damages it. Then `esptool.py erase_flash`, then `esptool.py write_flash 0x0 <correct-target-bin>`. Canonical unbrick - Solo Satoshi's guide has screenshots that apply identically.

Build NerdNOS from source for your specific board if no stable release exists yet. If NerdNOS supports your board in the `main` branch but hasn't cut a stable release, clone the repo: `git clone https://github.com/shufps/nerdnos`. Read the `README.md` for build dependencies (ESP-IDF version, toolchain). Inspect the `boards/` or equivalent directory for a config file matching your hardware. Build for your target: `idf.py set-target esp32s3 && idf.py build`. Flash the compiled `.bin`. Build-from-source is Tier 3 because toolchain setup is not forgiving; pin your ESP-IDF version to the one the NerdNOS README specifies.

Debug a custom-built NerdNOS `.bin` that produces `unsupported board config` anyway. If you built from source with what you believe is the correct board-config flag and the resulting `.bin` still refuses to init the ASIC, inspect the compiled binary: `esptool.py --chip esp32s3 --port COMx read_flash 0x10000 0x1000 partition-dump.bin` and grep the dump for your expected board-config string (e.g. `bitaxe_ultra_204`). If the string you expected isn't there and a different one is, your build environment picked up the wrong config. Check `sdkconfig.defaults`, `make menuconfig`, fork-specific overrides. `git clean -fdx` + fresh build resolves stale object caches.

Flash from a fresh `esptool` install if verify keeps failing. Old `esptool.py` versions (pre-`4.0`) have known ESP32-S3-specific bugs that can produce false-positive flash-succeeded reports followed by boot failure. Upgrade: `pip install --upgrade esptool`. Retry the full `erase_flash` + `write_flash` sequence on the fresh install. If verify still fails on the third attempt, suspect failing flash memory on the ESP32-S3 module itself (rare but real after many flash cycles) - crosses into Tier 4 hardware territory.

Stop DIY if the ESP32-S3 refuses ROM bootloader even with `BOOT` + `RESET`. A physically-alive ESP32-S3 always responds to the forced-bootloader sequence - that's the whole point of the mask-ROM. If holding `BOOT` and tapping `RESET` does not produce USB enumeration, the MCU has failed: surge damage, ESD, QFN solder-joint fracture, or die failure. No longer a wrong-firmware problem. Ship to D-Central - Tier 4.

Stop DIY if repeated confirmed-target flashes still produce `count_asic_chips = 0`. You've confirmed the board + revision + chip family, confirmed the NerdNOS build target, flashed three times cleanly, and the ASIC still won't enumerate. Wrong-firmware event may have masked a pre-existing ASIC fault: cracked BGA joint, thermal-cycled solder fatigue, ESD damage, die-level failure. Symptom looks identical to wrong-firmware but root cause is now hardware. Ship to D-Central for hot-air reflow or chip replacement.

Ship to D-Central with the exact flash history written out. Pack the board in anti-static, include the main PSU, and include a note listing: every `.bin` filename flashed, in what order, from what source (NerdNOS / AxeOS / ESP-Miner-NerdAxe / community fork), chip marking from Step 2, board product + revision from Step 1, failure mode observed. D-Central's open-source bench pioneered the Bitaxe ecosystem - original Mesh Stand, first heatsinks, every variant and Nerd family variant in stock. Canada-wide shipping; US / international welcomed. Turnaround `5 - 10` business days.

Consider the economics before committing to a full repair or replacement. A confirmed-wrong-firmware bench recovery at D-Central is typically `CAD $35 - $85` - 20 minutes of bench labour plus 30-minute burn-in. Full Bitaxe / NerdAxe replacement: `CAD $130 - $220` depending on variant and current stock. If the incompatibility event also revealed hardware damage, the quote rises to `CAD $55 - $185`. DIY Tier 1 flash with the right `.bin` is `$0 - $15` (USB-C cable), always cheaper than shipping. Bench makes sense only when DIY has hit a wall and the board is worth more than labour.