NerdAxe – Firmware Update Issues

Unplug USB-C, wait 10 seconds to let the bulk capacitors fully drain, then plug back in. ESP32-S3 boards keep their 3V3 rail warm for ~4 seconds after unplug — a quick cycle can leave firmware state wedged. A full 10-second drain ensures a cold boot. Surprisingly common: the OTA actually succeeded, but the device never cleanly rebooted onto the new image. This alone clears a meaningful percentage of reported `NA_FW` cases.

Retry the OTA on a strong WiFi signal. Move the NerdAxe within 2-3 metres of your router, close bandwidth-heavy tabs, and re-upload `www.bin` + `esp-miner.bin` through AxeOS Settings → Update. GitHub Issue #213 identifies weak 2.4 GHz WiFi with packet loss as the single most common OTA failure cause. A stable connection during the 60-120 second upload window resolves roughly 40-50% of reports without touching USB.

Verify the firmware version string in AxeOS Settings → System after a claimed 'successful' update. If it updated, the flash succeeded and your issue is elsewhere. Also hard-refresh the browser (`Ctrl+Shift+R`) or open AxeOS in an incognito tab — stale browser cache of the old `www.bin` UI is a frequent false-positive for 'bricked UI.'

Clear browser cache and reload AxeOS in a clean incognito session. AxeOS serves its UI from the device's `www.bin` partition, and a fresh `www.bin` combined with a cached old HTML/JS can produce a visually broken UI that is in fact fully functional. If the UI renders normally in incognito, the device is fine — you're just hitting a cache mismatch.

Force ROM download mode. Unplug the device. Press and hold the `BOOT` button (tactile pad near the ESP32-S3 module — check your board's silkscreen; NerdNOS may use a solder jumper). While holding `BOOT`, plug in USB-C. Release after 2 seconds. The ESP32-S3 is now in its ROM bootloader, which lives in mask silicon and cannot be overwritten by software — you are now flash-able no matter how corrupt the app partition is.

Flash `factory.bin` via the Web Flasher over USB-C. Use Chrome or Edge (Firefox and Safari do not implement WebSerial). Navigate to `shufps.github.io/ESP-Miner-NerdQAxePlus/` for NerdQAxe+ or the BitMaker-hub NerdAxe release page for NerdAxe. Click Connect, select your serial device, upload the `factory.bin` that matches your exact ASIC (`BM1366`, `BM1368`, or `BM1370`) and board revision. Flash takes 60-120 seconds. Device auto-reboots at the end.

If Web Flasher fails, fall back to `esptool.py` directly. Install Python 3.8+ and run `pip install esptool`. Command: `esptool.py --chip esp32s3 --port COM4 --baud 921600 write_flash 0x0 factory.bin` (swap `COM4` for your serial port; Linux/Mac use `/dev/ttyUSB0` or `/dev/cu.usbserial-XXXX`). `esptool.py` is exactly what the Web Flasher wraps — going direct eliminates any browser-side WebSerial quirks.

Re-run onboarding. After a clean `factory.bin` flash, power cycle once more. The device will broadcast AP SSID `NerdAxe_XXXX` (or fork-specific equivalent). Join from a phone, open `http://192.168.4.1`, enter WiFi credentials and pool details, save. Watch for the first accepted share on your pool's dashboard within 5-10 minutes at stock frequency.

If the latest firmware is broken for your model, revert to a known-good prior release. Check the fork's GitHub release notes — several AxeOS-derived builds have shipped regressions (`v2.1.5` reboots, `v2.7.1` fan curve on Gamma 601, `v2.11.0` temp regression, `v2.12.2+` Ultra 205/207 selftest). Download the last-known-good `factory.bin` and flash. This is a standard community workaround, not a hack.

If the device refuses to onboard after a factory flash, erase NVS entirely and re-flash. Command: `esptool.py --chip esp32s3 --port COM4 erase_flash`, then immediately `write_flash 0x0 factory.bin` again. This wipes any leftover WiFi credentials, pool config, stuck `overheat` flags, and corrupted NVS entries for a guaranteed clean boot. You will lose device-specific settings — a fair trade for a known-good starting point.

Dump and inspect the partition table to diagnose obscure boot failures. `esptool.py --chip esp32s3 read_flash 0x8000 0x1000 partition.bin` then `gen_esp32part.py partition.bin`. A healthy NerdAxe has `nvs`, `otadata`, `phy_init`, `ota_0`, `ota_1`, and `www` partitions. Corrupt `otadata` is a common subtle brick — the bootloader cannot decide which OTA slot to boot. Fix: full `factory.bin` flash at offset `0x0` which rewrites the partition table cleanly.

Bypass a stuck selftest by flashing an older pre-selftest build, letting it boot once, then flashing forward. For `v2.1.2`/`v2.1.3` Supra-derived and `v2.12.2+` Ultra-derived NerdAxe firmware with selftest false-negatives (GitHub #145, #516, #1600), this sequence clears the `selftest-required` flag in NVS without manually writing to NVS. Document your steps — the community workflow is evolving as upstream patches land.

Measure the 5 V USB rail under flash load with a multimeter. Probes at the USB-C shield pin (GND) and the 5 V test pad. Expected: ≥ 4.75 V sustained during a flash operation. Cheap USB hubs and 5 V / 1 A phone chargers sag below this under the NerdAxe's peak flash current (~700 mA). Swap to a wall-wart 5 V / 2 A or higher PSU and retry. Rail instability during flash is a commonly-overlooked root cause.

Inspect ESP32-S3 module and USB-C solder joints under 10× magnification (loupe or USB microscope). Look for hairline cracks at the module's corner solder, lifted pads around the USB-C connector (frequent after cable yanks), or flux/solder residue shorting adjacent pins. Any visible defect is a reflow candidate — hot air at 320 °C with a small volume of fresh solder paste. If you are not set up for rework, stop here and route to Tier 4.

Cross-check alternative firmware forks for your hardware. The NerdAxe ecosystem has active forks at `BitMaker-hub/ESP-Miner-NerdAxe`, `shufps/ESP-Miner-NerdQAxePlus`, and occasional NerdAxe patches in the upstream `bitaxeorg/ESP-Miner`. If your current fork's latest build is broken for your ASIC + board revision, a sibling fork may have the fix. Always confirm the target ASIC before flashing — `BM1366` vs `BM1368` vs `BM1370` mismatch bricks immediately.

Monitor boot via `idf.py monitor` from the ESP-IDF toolchain for deep debugging. Beyond raw 115200 serial, `idf.py monitor` decodes stack traces from the panic handler, formats backtraces with symbol resolution, and provides debug command input. This is how upstream devs triage, and the level at which OSMU Discord will ask for logs before giving fix advice on stubborn cases.

Stop DIY when the ESP32-S3 will not enter ROM download mode across multiple cables and PSUs, when visible board damage is present, or when a correctly-flashed `factory.bin` still produces `ASIC init failed` in logs. At this point the fault is hardware — ESP32-S3 module damage, USB-C connector failure, power-path component failure, or ASIC failure — and further DIY risks additional collateral damage. Book a D-Central ASIC Repair slot: we carry ESP32-S3-WROOM-1-N16R8 modules in stock and have a test fixture ready.

D-Central bench process: hot-air rework at 320-330 °C for module or USB-C replacement, fresh solder paste, full `factory.bin` re-flash with current stable fork firmware, 24-hour burn-in on a test pool at nameplate frequency, visual and electrical confirmation before ship-back. Typical turnaround 3-7 business days from receipt. We can also perform a non-repair firmware upgrade on a working NerdAxe if you've been putting one off from brick anxiety.

Ship safely to D-Central. Wrap the board in an anti-static bag (or a freezer bag as a workable fallback). Bubble-wrap around the bag. Small box with ≥ 3 cm of foam or crumpled paper on every side. Include a written note with: observed symptoms, firmware version attempted, whether the device enters ROM download mode with BOOT held, and your contact. That note saves us 20-30 minutes of diagnostic time and saves you repair dollars. Address is on the D-Central repair service page.