Avalon 1166 Pro – Firmware Upgrade Failure

Stop touching the miner. If the upgrade froze mid-upload, leave it powered and on the network for at least 10 minutes before doing anything else. The MM3 is single-threaded for upgrades and may still be writing to NAND or finalizing the partition table. Power-cycling now turns a stuck upgrade into a bricked controller faster than any other mistake on this list. Patience first, action second.

Note the exact error verbatim — `A1166_FW_FAIL`, `verify failed`, `checksum mismatch`, `signature invalid`, `network timeout`, or whatever the UI presents. The error string is your single best diagnostic asset, and once you reboot it may not surface again. Take a phone photo of the screen if the web UI is still visible. Save logs from the system log page if accessible.

Cable up. Disconnect the miner from Wi-Fi. Use a known-good Cat5e cable directly between your laptop and the miner, or laptop and a dumb switch the miner is also on. Disable Wi-Fi on the laptop entirely. Disable any VPN, container networking (Docker, WSL2), and split-tunnel software. The 1166 Pro upgrade pipeline is sensitive to packet loss, and a physical wire on a flat `/24` subnet eliminates the network category of failure.

Disable laptop sleep before retrying. Windows: Settings > System > Power > Screen and sleep set to never on AC. macOS: System Settings > Battery > Power Adapter > prevent automatic sleeping when display is off. Linux: caffeine or equivalent. A laptop that sleeps mid-upload is the second-most-common cause of `A1166_FW_FAIL` on D-Central's intake bench, right after Wi-Fi drops.

Re-download firmware from `avalonminer.org/firmware-document/` only. Identify your hardware revision from the chassis label or the previous web UI version string, match to the build on the official portal, download fresh. Do not re-use the file that failed — it may be the corrupted source. Verify file size matches the portal listing. Verify checksum if published.

Retry the upgrade with strict conditions: wired Ethernet, laptop sleep disabled, Wi-Fi off, VPN off, browser is Chrome or Firefox (avoid Safari for Avalon — TLS / upload-handler quirks). Watch the progress bar. If it freezes between 45% and 95%, wait 5 minutes before deciding it is hung. Only abort if the chassis status LEDs go fully dark or the upload returns a hard error.

Cross-check firmware signing. If the failure was `signature invalid`, your bootloader is signed and the image is not (or is signed by an old key). On `avalonminer.org/firmware-document/` filter by your hardware revision and look for the most recent signed build. Older 2019-2020 stock images will not flash on a 2022+ controller revision. If you genuinely need an unsigned build, contact D-Central support — bypassing signature checks is not a five-minute fix.

SSH in and check partition space. Default Canaan SSH credentials are documented per-build on the firmware portal. Once in: `df -h`, `cat /proc/mtd`, and `du -sh /tmp /var/log /upgrade 2>/dev/null` to see what is eating space. If `/upgrade` or `/firmware` is above 85% full, run `rm -rf /upgrade/*.staging` (verify path against your build). Reboot, retry upgrade.

Factory-reset before upgrading. Web UI > System > Factory Reset, or hold the chassis reset button for 10 seconds (varies by revision). This nukes running config but also clears staging partitions and orphaned upgrade artifacts. Re-set network, re-set pool credentials, then attempt the firmware upgrade. Clean state eliminates the stale-state category of failure.

Try the AUC3 USB upgrade path instead of the web UI. Some 1166 Pro hardware revisions support firmware upload over the AUC3 USB interface using Canaan's official AUC3 upgrade utility (Windows-only, downloadable from `avalonminer.org`). This bypasses the web upload pipeline entirely, which is useful when the web upload is the failing component. USB-direct flashes are slower but materially more robust on revisions that support them.

Build an SD recovery card. Pull the matching recovery image for your hardware revision from `avalonminer.org/firmware-document/` (look for `recovery` or `factory` suffixed builds — naming is inconsistent, read release notes). Write to a 4-16 GB microSD with Etcher (will not let you write to the wrong drive) or `dd if=recovery.img of=/dev/sdX bs=4M` on Linux. Insert into the MM3 SD slot. Hold the recovery button (or short the recovery jumper — varies by revision) and power on. A successful recovery boot writes the controller partitions back to factory state in 5-15 minutes.

Connect a USB-to-TTL serial adapter to the MM3. Find the UART header on the controller PCB — three pads labelled TX, RX, GND. Use a 3.3 V logic-level adapter (CP2102, FT232RL, CH340 — never 5 V). Wire TX adapter -> RX MM3, RX adapter -> TX MM3, GND -> GND. Open a serial terminal at `115200 8N1`. Power-cycle and watch the boot. Bootloader prompt + kernel messages tell you exactly which partition is failing.

Reset the upgrade staging area from the bootloader. If you reach the U-Boot (or Canaan-equivalent) prompt during boot, run `mtd erase` against the upgrade-staging partition to clear it without booting all the way into Linux. Verify the partition number against `mtdparts` first — erasing the wrong MTD destroys the bootloader and turns Tier 3 into Tier 4. This is the procedure D-Central techs use to clear partial-write damage without going to SD recovery.

Roll back to the previous known-good build. If the failed upgrade was to a brand-new release, the safer move is to flash the previous stable build instead. Canaan's release-note discipline is sparse — community forums (bitcointalk Avalon thread, r/Canaan_Mining, the avalonminer-community GitHub) often document which builds are stable and which shipped regressions. When in doubt, flash the last build that ran for 30+ days on similar hardware.

Serial-flash the controller image directly. With UART connected and the bootloader accessible, Canaan's serial flash utility (Windows + a vendor tool, or sx / bootp flow on Linux for some revisions) can write a controller image directly to NAND/eMMC, bypassing the in-Linux upgrade utility entirely. This is slow (30-90 minutes for a full image) but works when every other path fails. Verify the image is the correct hardware revision before flashing — wrong revision bricks the bootloader.

Stop DIY and ship to D-Central when: (a) SD recovery does not boot — bootloader is dead; (b) serial console shows no output on power-up — MM3 hardware fault; (c) you've corrupted a partition by erasing the wrong MTD; (d) chassis shows no power-on LED activity at all after a failed upgrade — possible MM3 damage from brownout. Book a D-Central ASIC Repair slot at `d-central.tech/services/asic-repair/` — turnaround 5-10 business days, Canada / US / international. We have a JTAG fixture for the MM3 generation that can re-write the eMMC and bootloader directly.

D-Central bench process: controller arrives, we verify chassis power and PSU output independently. Connect fixture UART, capture exact boot state. If bootloader is alive, attempt SD recovery first (cheapest path). If bootloader is dead, JTAG and re-write U-Boot, kernel, and rootfs partitions from a known-good golden image for your hardware revision. After successful flash, run a 24 h burn-in at nameplate hashrate and verify the upgrade utility itself works. Average bench time 2-4 hours software recovery, 4-8 hours hardware-assisted.

Pack hashboards and the controller separately. Anti-static bags for both. The MM3 is the priority — hashboards are usually fine after a failed firmware upgrade because the upgrade only touches the controller. Include a printed note: exact error string, when it failed, what build you were upgrading to, what build you were on, what tiers you've already tried, whether SD recovery has been attempted. Each prior step you've run is diagnostic time we don't repeat at the bench, and that is repair dollars off your invoice.