Avalon 1466 – Firmware Flash 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 MM3v2 is single-threaded for upgrades and may still be erasing or programming eMMC blocks. 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 — `A1466_FLASH_FAIL`, `verify failed`, `checksum mismatch`, `signature invalid`, `network timeout`, `partition full`, 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 entirely. 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 at the OS level. Disable any VPN, container networking (Docker, WSL2), and split-tunnel software. The MM3v2 upgrade pipeline is bytestream-sensitive, and a physical wire on a flat `/24` subnet eliminates the network category of failure outright.

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 `A1466_FLASH_FAIL` on D-Central's intake bench, right after Wi-Fi drops.

Re-download firmware from `canaan.io/product-support-firmware` 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. Throw away third-party mirror copies; they are not worth the supply-chain risk on signed-bootloader hardware.

Drop the miner to idle, then retry under strict conditions: stop hashing via the web UI before clicking upgrade. 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 — large eMMC erases stall the UI without actually failing. 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 `canaan.io` filter by your hardware revision and look for the most recent signed build. Older 2022-2023 stock images may not flash on a late-2024+ controller revision. If you genuinely need an unsigned build, contact D-Central support — bypassing signature checks is not a five-minute fix and tampered Avalon firmware is a documented pool-credential theft vector.

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`, `mount | grep mmc`, 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 before deleting). 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 — bigger than most operators expect on a 12-month-old A1466.

Try the AUC3 USB upgrade path instead of the web UI. Some A1466 hardware revisions support firmware upload over the AUC3 USB interface using Canaan's official AUC3 upgrade utility (Windows-only, downloadable from `canaan.io`). 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 A1466 hardware revision from `canaan.io/product-support-firmware` (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 MM3v2 SD slot. Hold the recovery button (or short the recovery jumper — varies by revision; consult the schematic) 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 MM3v2. 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, you will damage the UART pins). Wire TX adapter -> RX MM3v2, RX adapter -> TX MM3v2, 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 — far more diagnostic signal than the web UI gives you.

Reset the upgrade staging area from the bootloader. If you reach the U-Boot (or Canaan-equivalent) prompt during boot, run `mmc erase` against the upgrade-staging partition to clear it without booting all the way into Linux. Verify the partition number against `mmc part` first — erasing the wrong eMMC partition 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, and it is the difference between a $0 self-rescue and a $200+ bench ticket.

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 on A1466 / A1566 hardware. When in doubt, flash the last build that ran for 30+ days on similar hardware.

Reflash the eMMC directly via serial console. 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 eMMC, bypassing the in-Linux upgrade utility entirely. Slow — 30-90 minutes for a full image at 115200 baud — but works when every other path fails. Verify the image is the correct hardware revision before flashing; wrong-revision flashes brick 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 — MM3v2 hardware fault; (c) you've corrupted an eMMC partition by erasing the wrong block at the bootloader prompt; (d) chassis shows no power-on LED activity after a failed upgrade — possible MM3v2 damage from brownout during write; or (e) you've lost confidence in your hardware revision. 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 MM3v2 generation that re-writes 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, highest success rate). If bootloader is dead, JTAG and re-write U-Boot, kernel, and rootfs partitions from a known-good golden image for your A1466 hardware revision. After successful flash, run a 24 h burn-in at nameplate hashrate and verify the upgrade utility itself works before shipping back. Average bench time 2-4 hours software recovery, 4-8 hours hardware-assisted JTAG.

Pack hashboards and the controller separately. Anti-static bags for both. The MM3v2 is the priority — hashboards are usually fine after a failed firmware flash 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 have run is diagnostic time we don't repeat at the bench, and that is repair dollars off your invoice.