Avalon 1166 Pro – ASICCRC Error
Warning — Should be addressed soon
Symptoms
- `kern.log` / serial console shows repeated `asic crc error`, `ASICCRC`, `crc err chain X`, or `MM3 rx crc` lines
- CGMiner API `estats` returns non-zero `ECHU[...]` bits on the same chain as the `ASICCRC` events
- Dashboard hashrate reads 5-25% below SKU nameplate (68T / 72T / 75T / 78T / 81T)
- `GHSmm` (measured) drifts below `GHSavg` (average) by more than 3 TH/s sustained
- `MW0` / `MW1` / `MW2` arrays on the affected chain show fewer than 26 even entries or entries below 3000
- Chassis status LED alternates red/green (intermittent) rather than holding sustained red
- Pool-side rejected share rate climbs above 1.5% while stratum connection stays stable
- `SYSTEMSTATU` still reports all 3 chains active — the chain is not dropping, it is returning corrupted data
- `ASICCRC` events cluster around a temperature threshold (e.g. only appear when `PVT_T` crosses ~80 C)
- Error rate worsens after profile changes (frequency bump, PSU swap) or environmental changes (warmer intake, circuit load)
- Time-of-day pattern: `ASICCRC` spikes during evening neighbourhood peak load (voltage sag signature)
- Problem appeared after a firmware flash or cgminer config import from another unit
Step-by-Step Fix
Hard power-cycle at the breaker for a full 60 seconds, not a soft dashboard reboot. The MM3 firmware's CRC-error state can wedge after a firmware update or an unclean shutdown, and a full cold-boot clears it more reliably than a soft restart. Count to 60 so the bulk capacitors fully drain before you power back up.
Visually inspect the chassis: confirm all three hashboard status LEDs on the MM3 are solid green at idle, verify no debris has worked into the air intake during transport or install, and listen for ticking or buzzing from the PSU during steady-state hashing. These give you a baseline before any further change.
Clean the air intake filters with a shop-vac and wipe the front grille with a lint-free cloth. Dust on the intake raises inlet temp 2-6 C, and `ASICCRC` rates on 1166 Pro units track with chip junction temperature — a cleaner intake can clear a marginal CRC warning on its own, especially during late-spring or early-fall transition weather.
Verify intake ambient with an IR thermometer at the front grille (not room-middle). Target ≤ 30 C for a Canadian home/garage install, ≤ 35 C absolute max for any install. Above 35 C the A3206 bus margin closes and `ASICCRC` becomes progressively more likely — the data-centre-only assumption in Canaan's docs does not hold in a residential environment.
Check your MM3 firmware build at avalonminer.org/firmware-document/. If your build is older than the current stable for your hardware revision, plan a firmware upgrade — but only after you have cleared the hardware-side causes in Tiers 2 and 3. Flashing while a hardware fault exists means diagnosing two problems instead of one.
Power off at the breaker. Re-seat both ribbon cables on the hashboard flagged in diagnostics. Pull each connector fully, inspect the IDC contacts for blackening or oxidation, wipe with 99% isopropyl alcohol on a lint-free wipe if needed, then reseat until the latch clicks. This step alone clears roughly 60% of 1166 Pro `ASICCRC` tickets in D-Central's repair queue.
Multimeter on DC, probe at the PSU-to-hashboard connector while the miner is hashing at full nameplate power. Expect ~12.0 V sustained; anything below 11.6 V under load indicates a tired PSU or an undersized circuit. If the rail is borderline, swap the PSU with a known-good Canaan-spec APW-series unit — never a generic PC PSU, the current delivery envelope is wrong.
Measure line voltage at the service panel under full miner load. Expect 235-245 V on 240 V split-phase and 202-212 V on 208 V commercial. Low line voltage forces the PSU to draw more current, which amplifies rail sag, which amplifies bus ripple, which drives `ASICCRC`. If line voltage is low, stop — this is an electrical-panel problem before it is a miner problem.
Label the three hashboard slots 0, 1, 2 with tape. Swap the suspect board into a different slot and boot; monitor `kern.log` for 15 minutes. If `ASICCRC` follows the board, the board is the problem. If it stays in the original slot, the MM3 control board, the AUC3 interface, or the slot-specific wiring is the problem — escalate to Tier 3.
If you are running a non-default cgminer configuration (inherited unit, custom overclock, imported profile), reset the AUC3 flags to Canaan stock: `--avalon7-aucspeed=400000 --avalon7-aucxdelay=4000`. Aggressive AUC3 tuning is an undocumented failure mode after a profile import and is common enough in the D-Central queue to be worth checking before you touch hardware.
Connect to the miner's API on port 4028 or SSH in, and dump per-chain `ECHU`, `MW`, and `PVT` arrays with `echo -n '{"command":"estats"}' | nc 127.0.0.1 4028`. Save the output to a file before you change anything else. This snapshot is what D-Central's repair bench will ask for if the fix ends up shipping to us — it saves diagnostic time and your repair cost.
Replace the data ribbon cable on the affected chain with a known-good or new cable. Canaan IDC-style ribbons are available as spares from D-Central parts, aftermarket from Zeus, or can be re-crimped locally with a proper IDC press. A vise-grip re-crimp is a gamble — order a proper cable unless you are in a genuine emergency.
Remove the heatsinks from the affected hashboard. Inspect for dried thermal paste and crumbled thermal pads, especially on the PCH and voltage-domain ICs. Re-apply Arctic MX-6 or Thermal Grizzly Kryonaut in a thin uniform layer. Dried pads under the PCH are a silent cause of `ASICCRC` on 1166 Pros older than 18 months — the bus driver sits directly under that package.
Reflow the single worst-performing chip from diagnostic Step 5 with preheat plus hot-air: preheat bottom at 150 C, top-side 310-330 C for ~30 s, natural cool-down, fresh paste on reassembly. The A3206 BGA tolerates one reflow cycle well. A second reflow on the same chip within 90 days rarely holds — at that point replace the chip, do not reflow again.
If your MM3 build is known to exhibit strict-CRC behaviour (check release notes on the Canaan firmware portal — they are sparse but dated), roll back one build using the AUC3 interface and Canaan's official flash utility. Verify your board hardware revision against the firmware compatibility table before flashing. Wrong firmware for a late-rev board can brick the control board.
Inspect capacitors and MLCCs near the PMIC and AUC3 interface IC on both the hashboard and the MM3 control board. Bulging electrolytics, cracked MLCCs, or discolored board near a passive component means stop and replace before running the miner again. A failing cap near the bus driver shows up as `ASICCRC` long before it manifests as a hard fail.
Stop DIY and ship to D-Central when any of these are true: per-chip PVT isolates the same chip position on two different 1166 Pro boards; a chip has been reflowed once and `ASICCRC` returned within 30 days; the MM3 control board is suspected; or you see capacitor damage near the AUC3 interface IC. Book a D-Central ASIC Repair slot at d-central.tech/services/asic-repair/ — turnaround 5-10 business days, Canada / US / international.
Pack hashboards in anti-static bags, double-box with ≥ 5 cm of foam on every side, and include a printed note with: the exact `ASICCRC` lines from `kern.log`, MM3 firmware build, PSU model and measured rail voltage, ambient at install, and Tier 1-3 steps already run. This saves D-Central bench diagnostic time, which saves you repair dollars. D-Central bench process: AUC3 bus isolation, chain-by-chain CRC replay, chip replacement with graded A3206 parts, reflow and re-seal, 24 h nameplate burn-in.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
