Avalon – Firmware Flash via AUC

Identify hardware revision precisely before touching any firmware. Read the MM model (A1246, A1346, A1466) from a physical sticker or probe via `ascset|0,version,0`. Flashing an A1246 build onto A1346 hardware (or any similar cross) is the fastest path to a bricked controller because Canaan's signed-firmware model rejects mismatches without a rollback path. Five minutes of identification prevents days of recovery. Write the revision on a label and stick it to the controller lid for next time.

Bookmark `avalonminer.org/firmware-document/` and download the exact build matching your hardware revision. Save the *previous* build locally as a rollback insurance file — Canaan blocks official downgrades, and a portal URL you relied on today can 404 next year. Name the file with the rev and build number so you can find it under pressure. This is the single highest-ROI Tier-1 step and the one most often skipped by first-time flashers.

Swap the controller to wired Ethernet. Unplug the Wi-Fi dongle if the controller has a USB radio; disable Wi-Fi in the UI if it's a built-in radio. Community threads on `support.canaan.io` consistently flag Wi-Fi drops mid-update as the #1 brick cause on Avalon hardware. Wired-only is not a preference — it's a hard rule on Canaan rigs. Confirm the controller has a DHCP lease before proceeding.

Power-cycle the full rig at the PDU for a full 60 seconds. Not a soft reboot. Let the AUC3 LED settle to steady green before any flash attempt. If the rig boots to blue-stuck or red-flicker after the power-cycle, fix that underlying state first via the diagnostic tree — a pre-stressed bus will not survive a firmware push. If hashrate returns clean and `ECHU`/`ECMM` are near zero, you're ready.

Verify AUC3 LED in steady state is green. Per the 2018 Canaan PDF: blue = initialising or idle, green = working normally, red = communication issues or rejected shares. Note the red state is overloaded — during a flash it's genuinely ambiguous whether it's bus-side or pool-side. If you see red *before* starting, start with the AUC controller failure or AUC USB connection pages; do not begin a flash on a red LED.

Read your current AUC bus tuning via the controller SSH or cgminer config. Stock values for flash are `--avalon7-aucspeed 400000` and `--avalon7-aucxdelay 19200` (use `avalon8` or `avalon10` flag prefixes for newer-gen hardware). If you've tuned aucspeed higher for hashrate gains — 500000, 600000, anywhere above 400000 — revert to stock before flashing. Retune after. This is the single biggest undocumented flash-brick cause in the Avalon ecosystem.

Count MMs on each AUC3. The cgminer `ASIC-README` caps the IIC daisy chain at 5 MMs per AUC3. Canaan community guidance agrees. If you're running 6+ MMs on a single bridge, split the chain across two AUC3 bridges before flashing. A loaded bus under a flash write is an intermittent-corruption signature even Canaan's own firmware doesn't warn about. Oversubscribed bridges flash unreliably — sometimes clean, sometimes silently bricked.

Measure PSU 12 V rail output under full mining load with a Fluke 117 or equivalent multimeter. Rail must hold at or above 12.0 V sustained; anything below 11.8 V is sag territory. A1246-class rigs pull ~3400 W at the wall nominal per Canaan's manual, and aged APW-class PSUs (24+ months) produce rail droop during steady-state load that silently corrupts flash images. If sag detected, fix the PSU before flashing, not after.

Dry-run `ascset|0,version,0` probe against each MM on the chain before flashing. Every MM should return a version string within ~2 seconds. If one MM times out or returns garbage, pull it from the chain or fix it *before* flashing the others. A non-responsive MM on the bus pollutes every flash attempt on the same bridge. Document the pre-flash version strings — you'll compare them to post-flash probes to confirm success.

Replace the USB-B cable between controller and AUC3 with a known-good shielded unit ≤ 1.8 m. Unshielded or long cables inject RF noise into the 400 kHz IIC bus. A $15 quality USB cable is cheap insurance on a 3400 W rig. If the cable is already good, skip. If you inherited the cable with a used rig, replace it on principle — there's no way to visually confirm shielding integrity.

Flash one MM at a time, not the full chain concurrently. The web UI will happily attempt parallel flashes across all MMs on the AUC3; resist. Serial flashes keep bus contention out of the failure surface. Push the flash, watch the AUC3 LED cycle blue momentarily then return to steady green, and probe the newly-flashed MM with `ascset|0,version,0` before queuing the next MM. Rinse and repeat. This takes longer but brick rates plummet.

Monitor the controller's cgminer log (not just the web UI) during the final 30 seconds of each MM flash. The web UI's progress bar will happily show 95% while the in-flight write is already hung. The cgminer log shows the truth. If a chunk write exceeds ~90 seconds without acknowledgement, the subsequent chunks will fail too — wait a full 5 minutes for genuine timeout, then power-cycle before any retry.

Post-flash, verify each MM by probing `BIN`, `MW0-MW2`, `ECHU`, `ECMM`, and `SYSTEMSTATU` via the controller shell or cgminer API (port 4028 TCP). `BIN` must read non-zero (Zeus Mining's A11/A12 guide flags `BIN reads 0 efuse readable` as a firmware-write failure). `MW0-MW2` must populate. `ECHU`/`ECMM` should stay at or near zero. `SYSTEMSTATU` should transition to `Work`. Give the rig 15-30 minutes of steady-state before declaring victory.

If the controller web UI is unreachable post-flash, reimage the controller from a fresh Class 10 MicroSD card using Balena Etcher or `dd`. Pull the controller image from `avalonminer.org/firmware-document/` matched to your hardware revision, FAT32 where the bootloader requires it. This bypasses whatever state the controller got wedged into mid-flash and gives you a clean starting point for the MM-level recovery pass.

For stuck-bootloader MMs that still enumerate on the IIC bus but refuse to hashrate, connect a Linux bench PC directly to the AUC3 USB port, launch cgminer locally with the appropriate `--avalon8` or `--avalon10` flag at stock aucspeed, and re-push the MM firmware via scripted `ascset|0,<cmd>` sequences per `Canaan-Creative/avalon10-docs`. This bypasses whatever the original controller's web UI is choking on — sometimes the controller image itself is the problem.

If `BIN reads 0 efuse readable` persists on an MM post-reflash, stop. Attempt exactly one more controlled flash under ideal conditions (stock aucspeed, wired Ethernet, verified PSU, matched build). If it still persists, do not continue reflashing — further attempts can corrupt neighbour chips' one-time-programmable eFuses, and you've moved from a recoverable firmware state to an irrecoverable hardware state. This is the Tier-3-to-Tier-4 threshold.

Scope the `CK` (~4 MHz), `C` (6.097 MHz), `D`, and `R` signals on the affected MM per Zeus Mining's A11/A12 repair guide. Clean `CK` and `C` clocks with no stretching; `D` signal swinging between rails; `R` held high. Abnormal traces mean the fault is hardware — bad solder joint on a chip's clock/reset line, aged silicon drift, or a corrupted eFuse — not firmware. At this signature, stop flashing and ship. This step is Tier 4; it exists here so you know what you're handing D-Central.

Archive your successful flash: save the build file locally, note the hardware revision, note the cgminer aucspeed/aucxdelay values, and document the per-MM pre- and post-flash version strings. This archive becomes your rollback insurance (Canaan blocks official downgrades, but an archived local image gives you options) and your baseline for future flash diagnostics. A ten-minute documentation habit saves hours when the next firmware drops.

If you want a second opinion before pulling the flash trigger on a valuable rig, book a D-Central Mining Consulting remote diagnostic session. A Mining Hacker on screen-share can read your cgminer log, verify your aucspeed config, confirm your hardware-rev match, and walk you through the flash in real time. Pricing sits in the $75–$150 CAD range per session — cheaper than a bricked MM and measurably cheaper than a bench repair.

Ship to D-Central ASIC Repair at `d-central.tech/services/asic-repair/` when Tier 4 thresholds hit: three controlled reflashes failed, `BIN reads 0` persistent across attempts, controller refuses any image, abnormal scope traces on `CK`/`C`/`D`/`R`, visible component damage, or silent MMs that previously enumerated. Include your cgminer log, flash transcript, AUC3 LED sequence observations, and hardware rev. Mining Hackers, built by plebs for plebs — recovery at component level, not replacement fees.