Avalon 1446 – 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 controller is single-threaded for upgrades and may still be writing to eMMC 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 — `A1446_FW_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. 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 1446 upgrade pipeline is sensitive to packet loss, 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 `A1446_FW_FAIL` on D-Central's intake bench, right after Wi-Fi drops.

Re-download firmware from the official source only — `canaan.io` (support / downloads) or `avalonminer.org/firmware-document/`. Identify your hardware revision from the chassis label or the previous web UI version string, match to the build for the A1446 specifically, download fresh. Do not re-use the file that failed — it may be the corrupted source. Verify file size matches the portal listing. Verify the image is for the 1446 — NOT 1346, 1366, 1466, or 1566. Same control board family, different signed firmware payload.

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). Single browser tab on the upgrade page. Watch the progress bar. If it freezes between 40% and 95%, wait 5 full minutes before deciding it is hung — large eMMC erases can 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, or is for the wrong A14-family model). On `canaan.io` / `avalonminer.org` filter by hardware revision and look for the most recent signed build for the 1446 specifically. Older 2022-2023 stock images may not flash on a 2024+ 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`, `du -sh /tmp /var/log /upgrade 2>/dev/null` to see what is eating space. If `/upgrade`, `/firmware`, or `/var/log` is above 85% full, run `rm -rf /upgrade/*.staging` (verify path against your build) and `truncate -s 0 /var/log/messages`. 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 on the eMMC. Re-set network, re-set pool credentials, then attempt the firmware upgrade. Clean slate eliminates the stale-state category of failure — and is meaningfully different from a soft reboot.

Try the AUC3 USB upgrade path instead of the web UI. Some 1446 hardware revisions support firmware upload over the AUC3 USB interface using Canaan's official AUC3 upgrade utility (Windows-only, downloadable from `canaan.io` / `avalonminer.org`). This bypasses the web upload pipeline entirely, which is useful when the web upload is the failing component (browser TLS quirk, intermediate proxy, web-server staging space). 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 1446 hardware revision from `canaan.io` / `avalonminer.org/firmware-document/` (look for `recovery`, `factory`, or `restore` suffixed builds — naming is inconsistent across the A14 family, read release notes carefully). 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 controller's SD slot. Hold the recovery button (or short the recovery jumper — varies by revision) and power on. Recovery writes the controller eMMC partitions back to factory state in 5-15 minutes. Confirm the recovery image is for the 1446 specifically — wrong-model recovery is a common A14-family mistake.

Connect a USB-to-TTL serial adapter to the controller. 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 controller, RX adapter -> TX controller, 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 `mmc erase` or `mtd erase` against the upgrade-staging partition to clear it without booting all the way into Linux. Verify the partition number against `mtdparts` / `mmc part` first — erasing the wrong region destroys the bootloader and turns Tier 3 into Tier 4. This is the procedure D-Central techs use to clear partial-write damage on the 1446 without going to SD-card 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 on the A14 family — 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 1446 hardware. New release does not equal stable release.

Serial-flash the controller eMMC 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 eMMC, bypassing the in-Linux upgrade utility. Slow (30-90 minutes for a full image) but works when every other path fails. Verify the image matches the 1446 hardware revision before flashing — wrong revision = bricked bootloader, and wrong-model-from-the-A14-family is the same outcome.

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 — controller hardware fault; (c) you've corrupted a partition by erasing the wrong MTD or mmc region; (d) chassis shows no power-on LED activity at all after a failed upgrade — possible controller 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 A14 controller 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 1446 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 controller is the priority — the three 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 was attempted, and whether a cross-flash from another A14-family model is in your history. Each prior step is diagnostic time we don't repeat at the bench, and that is repair dollars off your invoice.