NerdAxe – BM1366 vs BM1368 Firmware Mismatch

Identify the ASIC chip family on your NerdAxe before flashing anything. Power down. Remove any fan, shroud, or heatsink covering the top of the BGA. Under good light, read the lasered marking on the chip: `BM1366` or `BM1368`. Photograph it for reference. If marking is obscured, default to BM1366 only for stock NerdAxe 500G — for any community-sourced or custom NerdAxe variant, confirm with the vendor's order email or product listing. The chip-family marking is the single most important input to this recovery; guessing wrong wastes 30 minutes and costs you another flash cycle.

Connect USB-C to a PC with no main PSU attached. Unplug the NerdAxe's main barrel / 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 NerdAxe. 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.

Locate the chip-family-matched factory `.bin` from the authoritative source. For NerdAxe 500G (BM1366): BitMaker-hub/ESP-Miner-NerdAxe releases. Pick the latest release tagged for BM1366 — read the release notes / asset description explicitly for chip-family target. For any BM1368 NerdAxe variant: verify a BM1368-tagged branch exists in the same repo, or locate the specific community fork that targets BM1368. Do NOT flash a `.bin` whose release notes are silent on chip target — BitMaker-hub has historically shipped both targets from the same repo and asset filenames alone are not enough to confirm.

Flash the correct `.bin` over USB-C. If the NerdAxe fork ships a WebSerial flasher, use it — Chrome or Edge (WebSerial is not in Firefox or Safari). 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-correct-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 NerdAxe's main power source. Wait: OLED splash with NerdAxe logo within `~3 s`, Wi-Fi AP `nerdaxe_xxxx` on your phone within `~15 s`. Connect to the AP, complete first-boot wizard — Wi-Fi SSID/password, pool URL, worker name, stock frequency/voltage. The factory flash wiped NVS, so you will re-enter all of this. Write down your pool URL and worker name before flashing next time.

Validate `count_asic_chips` on the AxeOS status page. Once AxeOS is on Wi-Fi, open the status page. Confirm `count_asic_chips = 1` for NerdAxe 500G single-chip. For multi-chip NerdAxe variants, confirm the documented chip count. If count is wrong (typically still `0`), you grabbed the wrong-family `.bin` again in Step 3 — go back, re-verify the release asset explicitly names your chip family, reflash. `count_asic_chips` is the single most reliable post-recovery sanity check.

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

Attach a USB serial terminal at `115200 baud` for live flash verification. Use PuTTY (Windows), `screen /dev/ttyACM0 115200` (Linux), or Arduino Serial Monitor. Reset the NerdAxe after flash and watch the cold-boot banner. Correctly-flashed image prints chip family target: `ESP-Miner-NerdAxe vX.Y.Z` / `ASIC: BM1366` / `count_asic_chips = 1` within first few seconds. Still-mismatched flash prints `BM1366 timeout` or `BM1368 no response` — telling you the driver was compiled for the wrong chip family. Fastest way to confirm driver-vs-silicon match without waiting for AxeOS.

Use `esptool.py` directly when a WebSerial flasher fails or the NerdAxe fork doesn't ship one. `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 esp-miner-nerdaxe-bm1366-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.

Verify the `.bin` source before flashing anything from outside `BitMaker-hub/ESP-Miner-NerdAxe`. Malicious or tampered firmware for open-source miners has been spotted in Discord drops, Telegram channels, random GitHub mirrors. If the `.bin` did not come from the BitMaker-hub release page directly, do not flash without checksum verification. Community forks (e.g. BM1368 experimental) should publish checksums in release notes; cross-reference. A bricked NerdAxe from a confirmed-bad `.bin` is Tier 3 recoverable, but it's wasted time. Community best practice; no confirmed NerdAxe malware in the wild as of 2026-04.

Confirm `CONFIG_ASIC_MODEL` if you have access to the source and build toolchain. If you compiled the `.bin` yourself from BitMaker-hub/ESP-Miner-NerdAxe, inspect `CMakeLists.txt` or `sdkconfig` for the `CONFIG_ASIC_MODEL` flag — it should read `BM1366` for NerdAxe 500G, `BM1368` for a BM1368-variant build. Wrong flag at build time produces this exact failure mode. Rebuild with the correct flag, reflash. Custom-build mistakes are the #1 cause of mismatch events on enthusiasts' benches. Verify exact flag name against current ESP-Miner-NerdAxe main branch.

Handle multi-device NerdAxe / Bitaxe fleets carefully. Home miners who own a NerdAxe alongside a Bitaxe Supra (BM1368) and a Bitaxe Ultra (BM1366) have three different chip families in the same house, with `.bin` files sorted by filename in a flat folder. Keep factory `.bin` files in folders named by chip family and revision: `~/firmware/nerdaxe-bm1366/`, `~/firmware/bitaxe-supra-401-bm1368/`, `~/firmware/bitaxe-ultra-204-bm1366/`. Label the boards themselves with masking tape: `NERDAXE-BM1366`. Never batch-flash across a mixed-chip fleet.

Erase NVS and force clean first-boot if selftest still loops after a confirmed-correct flash. If you flashed the matching chip-family `.bin` cleanly but the board immediately re-enters selftest loop, a stale NVS entry may be holding bad config from the prior wrong-family firmware. Use `esptool.py --chip esp32s3 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 carries the problem. NVS corruption is a common side effect of repeated failed selftest loops.

Force mask-ROM bootloader for power-loss-mid-flash recovery. If 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`, connect USB-C, tap `RESET`, release `BOOT` — forces mask-ROM regardless of flash state. Mask-ROM is immutable silicon; no flash event damages it. PC will enumerate ESP32-S3 JTAG/serial device. Then `esptool.py erase_flash`, then `esptool.py write_flash 0x0 <correct-bin>`. Canonical unbrick procedure — Solo Satoshi's guide has screenshots that apply identically to NerdAxe.

Debug a custom-built `.bin` that still produces chip mismatch after multiple rebuild attempts. If you're building from source and `count_asic_chips = 0` persists through rebuilds with what you believe is the correct `CONFIG_ASIC_MODEL`, inspect the compiled binary: `esptool.py --chip esp32s3 --port COMx read_flash 0x10000 0x1000 partition-dump.bin` and grep the dump for `BM1366` / `BM1368` string markers. Compiled driver name should appear as a string literal. If dump reads `BM1368` but you set `CONFIG_ASIC_MODEL=BM1366`, your build environment isn't picking up the flag. Check `sdkconfig.defaults`, `make menuconfig`, fork-specific overrides. A `git clean -fdx` + fresh build sometimes 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. 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-correct-chip-family flashes still produce `count_asic_chips = 0`. You've confirmed the chip marking, confirmed the `.bin` 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 NerdAxe in anti-static, include the main PSU, and include a note listing: every `.bin` filename flashed, in what order, from what source, with your chip marking from Step 1, and the failure mode observed (serial console output if captured). D-Central's open-source bench runs flash forensics, mask-ROM recovery, and BGA rework on NerdAxe alongside Bitaxe and NerdQAxe — same silicon family, same toolchain. Canada-wide shipping; US / international welcomed. Turnaround `5 - 10` business days. D-Central pioneered the Bitaxe ecosystem — original Mesh Stand, first heatsinks — and stocks every Nerd / Bitaxe variant.

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 NerdAxe replacement: `CAD $140 - $200` depending on variant and current stock. If the mismatch event also revealed hardware damage, 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.