Avalon 1366 – 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 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 — `A1366_FLASH_FAIL`, `verify failed`, `checksum mismatch`, `signature invalid`, `network timeout`, `mtd write failed`, 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 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, podman), and split-tunnel software. The A1366 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 `A1366_FLASH_FAIL` on D-Central's intake bench, right after Wi-Fi drops.

Re-download from `avalonminer.org/firmware-document/` only. Identify your A1366 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. Avoid third-party mirrors entirely — tampered Avalon firmware has been used as a pool-credential malware vector.

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 full minutes before deciding it is hung. Only abort if the chassis status LEDs go fully dark or the upload returns a hard error. The 76% window is normal for the kernel-partition write — slowest erase block, not a freeze.

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 a different revision). On `avalonminer.org/firmware-document/` filter by your hardware revision and look for the most recent signed build. Older 2022-2023 stock images will 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` for filesystem usage, `cat /proc/mtd` for raw partition layout, `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 first — wrong path can clobber active firmware). 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 slate eliminates the stale-state category of failure and is the cheapest fix in the list above Tier 1.

Try the AUC3 USB upgrade path instead of the Web UI. Some A1366 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 UI upload pipeline entirely, which is useful when the Web UI upload is the failing component. USB-direct flashes are slower but materially more robust on revisions that support them. Watch the AUC3 LED throughout: solid green = comm healthy.

Build an SD recovery card. Pull the matching recovery image for your A1366 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 (refuses to 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) and power on. Successful recovery writes the controller partitions back to factory state in 5-15 minutes.

Connect a USB-to-TTL serial adapter to the MM3v2 UART. Find the UART header on the controller PCB — three pads labelled TX, RX, GND (some revisions add a 3V3 pad you do not connect — that is reference voltage, not power). 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. Slow, careful, irreversible if you typo.

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 A1366 hardware. Caveat: signed-bootloader units may block downgrades by enforcing monotonic version numbering — check release notes.

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, 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 — MM3v2 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 MM3v2 damage from brownout; (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 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. Bootloader alive -> attempt SD recovery first (cheapest path). Bootloader 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 against a known-good payload. Average bench time 2-4 hours software recovery, 4-8 hours hardware-assisted.

Pack the controller and hashboards separately for shipping. Anti-static bags for both. The MM3v2 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, target build, prior build, tiers already tried, whether SD recovery was attempted. Each prior step you've already run is diagnostic time we don't repeat at the bench, and that is repair dollars off your invoice.