Bitaxe Max – New Firmware Not Yet Supporting Chip

Re-flash the official factory `.bin` for your exact Bitaxe Max revision. Open Chrome or Edge (WebSerial is not in Firefox or Safari). Navigate to bitaxeorg.github.io/bitaxe-web-flasher. Pick your specific Max revision from the dropdown — do not pick `latest` if your revision is brand-new and the flasher hasn't been updated yet; in that case, use the asset attached to your revision's release on github.com/bitaxeorg directly. Connect USB-C with no main PSU attached. Click Flash. Wait `45 – 90 s` for write + verify. Watch the progress bar to completion.

Reconnect main PSU and complete first-boot wizard. Unplug USB-C. Connect main power. OLED splash within `~3 s`. Wi-Fi AP `bitaxe_xxxx` within `~15 s`. Connect from your phone, enter Wi-Fi SSID/password, pool URL, worker name. AxeOS reboots into operating mode. Confirm `count_asic_chips` matches your variant's documented value, hashrate climbs to nameplate within `~5 min`. If you reach this point, recovery is complete; stop here and stay on official firmware.

Stop flashing community forks until upstream supports your chip family. This is the discipline. A new Bitaxe Max revision is not a place for `let me try this tuned build` until upstream `bitaxeorg/ESP-Miner` `main` has tagged a release that explicitly lists your chip family in the changelog. Bookmark github.com/bitaxeorg/ESP-Miner/releases and check it monthly. Wait an additional `2 – 4 weeks` after the upstream tag for community forks to rebase before evaluating them on production hardware.

Document your specific revision before flashing anything else. Write down: PCB silkscreen series number, chip-family laser marking from the BGA, exact firmware filename and version that came pre-flashed (read from AxeOS About / System Info before any flash event). Tape this note to the underside of the board. Future-you, six months from now, recovering after a power event, will need this exact information — sometimes `latest official` carries regressions for brand-new chips and you'll need the recorded version, not the freshest one.

Verify the firmware's chip-family banner over USB serial. Install PuTTY (Windows) / `screen /dev/ttyACM0 115200` / `minicom` / Arduino Serial Monitor. Connect at `115200 baud`. Reset the board and watch the cold-boot output. Correct firmware on a correctly-supported chip prints the chip family target as a string literal within the first few seconds (e.g. `ASIC: BMxxxx`, `count_asic_chips = 1`). If the banner names a chip family that doesn't match the laser marking on the BGA, the firmware is wrong-family — pick the correct revision from the flasher dropdown and retry Step 1.

Erase NVS only and re-run first-boot. If the official `.bin` flashes cleanly but selftest still loops or AxeOS hangs at first boot, a stale NVS entry from a prior community-fork flash may be holding bad config. `esptool.py --chip esp32s3 --port COMx erase_region 0x9000 0x6000` wipes 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.

Check `Vin` at the board input under load. Multimeter on DC. Probe the input pads / barrel jack / USB-C `VBUS` pin during boot and during attempted hashing. Expect the documented spec for your variant — read the silkscreen near the input or the project's hardware repo for the exact number (typical Bitaxe `Vin` is `5 V` for some boards, `12 V` for others). Anything more than `±5%` off spec means PSU or upstream wiring problem, not firmware.

Check `VCORE` at the TPS546 output during chip init. Probe the TPS546 output rail (silkscreen `VCORE` near the chip). It should rise to the chip's documented `Vcore` window during the first few seconds of init. If `VCORE` stays at `0 V`, the TPS546 isn't enabling — suspect missing `EN` signal from the ESP32-S3 (rare but real) or a faulty TPS546. If `VCORE` rails high above spec, also TPS546 fault. Crosses into Tier 3 / Tier 4 hardware territory.

Capture full serial-console output during failed init. Save the cold-boot through first `60 s` log to a text file. Error vocabulary tells you exactly which init step failed: `BMxxxx no response` (chip never ACKed), `BMxxxx handshake timeout` (chip ACKed but didn't complete address assignment), `Unsupported chip family` (firmware probed and gave up). Each has a different upstream issue thread on github.com/bitaxeorg/ESP-Miner/issues and a different escalation path. The captured log is also what you attach to a new bug report.

Use `esptool.py` directly when WebSerial fails or you need fine control. `pip install --upgrade esptool`. Force mask-ROM: hold `BOOT`, tap `RESET`, release `BOOT`. 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-factory-<revision>.bin`. CLI output tells you exactly what happened: timeout, checksum mismatch, MD5 verify fail, success. Espressif's toolchain is the reference; any browser WebSerial wraps it.

Verify the `.bin` checksum against the official release's published hash. Brand-new Bitaxe Max revisions sometimes ship with a tampered or partial `.bin` mirrored on a third-party download site. Always pull the `.bin` from the github.com/bitaxeorg release page directly. Compute the SHA-256 locally — `sha256sum esp-miner-factory-<revision>.bin` (Linux / WSL / git-bash) or `Get-FileHash -Algorithm SHA256` (PowerShell) — and compare against the release notes' value. If no checksum is published, file an issue requesting one before flashing anything outside the project's web-flasher.

Check upstream for a draft / WIP PR adding your chip family. Brand-new Bitaxe Max revisions sometimes have an open PR against `bitaxeorg/ESP-Miner` adding the chip-family driver before it's merged to `main`. Search github.com/bitaxeorg/ESP-Miner/pulls for `BM1xxx` / `Max` / your revision's series number. Do NOT flash a draft PR's build on a production miner — but reading it tells you how close the merge is and what testing the maintainers want from the community.

File a clean upstream issue if your symptom isn't already tracked. Title format: `BMxxxx init fails on Bitaxe Max revision <X>`. Body includes: chip-family laser marking (photograph), PCB silkscreen series number, official firmware version that came pre-flashed and worked, the community-fork build that reproduced the failure, full serial-console output captured in step 9, your `esptool.py` flash log. Link to github.com/bitaxeorg/ESP-Miner/issues. Good bug reports accelerate the merge window.

Do not custom-build with a guessed `CONFIG_ASIC_MODEL` value. If you pull `bitaxeorg/ESP-Miner` and try to set `CONFIG_ASIC_MODEL=BM1xxx_GUESS` for an enum value that doesn't yet exist in upstream's `Kconfig`, your build will either fail to compile or compile to a `.bin` that targets the closest existing chip family — guaranteeing the same `count = 0` symptom. Custom builds only make sense once the new chip family enum is upstream and you're testing tuning patches on top of merged support.

Roll back to the exact pre-flashed firmware version, not `latest official`. When a Bitaxe Max ships, the firmware burned into it at the factory is sometimes one specific build vetted against that batch of silicon. Even a later official release can carry init regressions for a brand-new chip if testing coverage hasn't caught up. Read AxeOS System Info on a fresh unit before doing anything; record that exact version string. If a `latest official` flash misbehaves later, roll back to the recorded version, not `latest minus one`.

Force mask-ROM bootloader for power-loss-mid-flash recovery. If WebSerial 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 the ESP32-S3 JTAG/serial device. Then `erase_flash` + `write_flash 0x0 <correct-bin>`.

Subscribe to Bitaxe project channels for new chip-family merge notifications. Watch github.com/bitaxeorg/ESP-Miner releases (RSS feed available), join the official Bitaxe project Discord, follow the Open-Source Miners United (OSMU) wiki updates. The merge-to-main event is what unlocks community fork compatibility — your wait window ends the moment a tagged release explicitly mentions your chip family in the changelog. Don't chase pre-merge fork claims; wait for the upstream tag.

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 factory `.bin` flashes still produce `count_asic_chips = 0` after clean `erase_flash` + `write_flash` cycles AND PSU / `Vin` / `VCORE` all measure healthy. The NDA-driver-gap explanation no longer fits — 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 NDA gap but root cause is hardware. Ship to D-Central for hot-air reflow or chip replacement.

Ship to D-Central with the exact flash history and chip-family documentation. Pack the Bitaxe Max in anti-static, include the main PSU and USB-C cable. Include a printed note listing: chip-family laser marking from Step 5 (with photograph if possible), PCB silkscreen series, every `.bin` filename flashed in what order from what source URL, the failure mode observed, and the serial-console output from Step 9. D-Central pioneered the Bitaxe ecosystem — original Mesh Stand, first heatsinks for Bitaxe and Bitaxe Hex — and stocks every Bitaxe / Nerd-family variant as it ships. Canada-wide shipping; US / international welcomed. Turnaround `5 – 10 business days`.