Avalon Series – E: no asics!! Error

Hard-power-cycle at the PDU or breaker for a full 60 seconds. Not a Web UI reboot — a true AC disconnect. Wait the full minute for PSU bulk caps to discharge and the MM state machine to flush, then power back up and watch the dashboard for the missing chain to come back. The Avalon MM can wedge after a brownout, a network hiccup, a reboot storm, or a Web-UI reboot during a flash, and a cold boot recovers a meaningful fraction of E: no asics!! events with zero tools and zero spend. While you wait, note any red LEDs, unusual PSU fan behaviour, or burnt smell — those observations steer the rest of the triage. Log the event so you can spot a recurring pattern across days or weeks.

Confirm the AUC and Web UI are reachable before chasing the chain. Browse to `http://<miner-ip>/`, ping the miner IP from a laptop on the same subnet, and check the AUC LED colour (green = working). If the Web UI is unreachable or the AUC LED is dark, the root cause is NOT chain-side — it is an AUC / network fault and the correct playbook is the AUC USB Connection Lost, AUC Controller Failure, or AUC Controller Network Loss page. Only continue here if the control side is alive and reporting telemetry.

Read SYSTEMSTATU, PS[0..2], ECMM, ECHU[0..2] via the cgminer JSON API on port 4028. `curl http://<ip>:4028 -d '{"command":"estats"}' -H "Content-Type: application/json"` returns the full telemetry surface that the Canaan Web UI hides. Identify which chain index is failing (0, 1, or 2). If PS[0..2] are all zero, PSU comms are dead — branch to the PSU playbook. If ECHU[x] is zero on one chain and the other two are normal, this IS a No-ASICs / CHAIN_FAIL and you are on the right page. Screenshot the full response before continuing — D-Central's bench will want it if the miner ships.

Review service history and physical-event history. Was the miner opened, reseated, paste-refreshed, or had a hashboard swapped in the last 30 days? Did a storm, brownout, breaker trip, or PDU event happen recently? E: no asics!! right after service is almost always mechanical (ribbon, power-sequence reversal, loose connector); right after a power event is almost always electrical (U1/U2/R8/R9 burn, PMIC damage, chip surge); out of the blue on a stable miner is most often ribbon wear or connector oxide from chassis-fan vibration. Service history is the single highest-value piece of context — log it before touching a screwdriver.

Confirm intake ambient temperature with an IR thermometer at the intake grille (NOT room-middle). Canaan A1066 envelope (which inherits across the A11/A12/A13/A14 family with minor adjustments) calls for inlet ≤ 35 °C. A Canadian basement in February is never the problem; a garage in July or a closed utility closet with bad return-air flow can hit 40 °C+ at intake and stress the PSU and per-board regulators hard enough to drop the weakest chain intermittently. Fix airflow first — a No-ASICs that is really a thermal-overload-masking-as-enumeration-fail will fight you forever otherwise.

DMM-verify PSU output at the control-board harness, first open-circuit and then under boot load. Kill AC. Disconnect the PSU-to-control harness. Probe DC at the harness tip: expect 12.0-12.6 V open-circuit on A11/A12/A13 PSU envelope (verify against your specific PSU spec sticker for A14/A15). Reconnect firmly. Power up and re-probe at the same point during the boot window: expect ≥11.8 V sustained on A11-A13. A PSU that reads 12.3 V open-circuit and sags to 9 V under three-board load is tired; the longest-ribbon chain is typically first to drop. This is the cheapest Tier-2 diagnostic that separates PSU faults from downstream faults definitively.

Swap to a known-good Canaan PSU from the documented compatibility envelope. A11/A12/A13 chassis use the A1056 / A1066 / A1066 Pro / A1126 Pro-S / A1146 Pro / A1166 Pro / A1246 / A1266 family per Canaan shop listings; A14/A15 chassis use their own family — verify against your model spec. Do NOT cross-connect a Bitmain APW-series PSU. Canaan and Bitmain pinouts differ and cross-brand PSU connection is a documented control-board-killer. Power up, observe the chains return within 90 seconds. If the chain comes back, the fault was PSU; build a maintenance plan to age out the original.

Re-seat every ribbon, harness, and signal cable in the chassis — focus on the failed chain. Kill AC. Open the chassis. Unplug the AUC-to-hashboard ribbon for the specific failing chain, inspect under bright light for blackening, green oxide, corrosion, bent or recessed pins, cracked housings, heat damage near the crimp. Clean dirty contact surfaces with 99% isopropyl alcohol and a lint-free swab; let evaporate fully. Re-seat firmly — feel and hear the click. Same for the PSU-to-control harness. Chassis-fan vibration on the A12/A13/A14 cooling hardware is the dominant cause of intermittent E: no asics!! on otherwise-healthy boards across all A-series generations.

Cable-tie the AUC ribbon and PSU harness to the chassis frame. If Step 7 or 8 resolved the fault and you found wear or oxide at a connector, secure the affected cable to the chassis frame with a zip-tie so chassis-fan vibration cannot work it loose again. Zeus Mining documents this fix-and-prevent pattern explicitly on the A1246 and it applies identically across the rest of the A-series. One-dollar fix that prevents the same miner from landing on the bench again next quarter.

Swap the AUC IIC ribbon for the failing chain with a known-good spare. A cracked conductor inside the ribbon flex section does not show on visual inspection — the only reliable isolation is a swap test. Ribbons are cross-compatible across A12 (1246/1266) and A13 (1326/1346/1366); A11 ribbons are sometimes compatible but verify pinout before crossing generations; A14/A15 use their own ribbons. Pull a known-good spare from a parts-donor chassis or buy from a parts supplier. If the chain enumerates after the swap, you have confirmed a dead ribbon; zip-tie the new one per Step 9 and call it done.

Slot-swap the hashboards in the chassis to isolate board vs. slot. Move the failing chain's board into a known-good slot; move a known-good board into the failed slot. Power up. If the failure follows the board, the board is the fault — Tier-3 rework or ship. If the failure stays with the slot, the AUC / control-board side of that chain is the fault — Tier-3 or ship. This single bisection cuts diagnostic time in half and is the single best argument for keeping at least one parts-donor chassis on the bench.

Isolate one hashboard at a time by unplugging the other two. Kill AC. Disconnect two of three hashboard ribbons. Power up with only one board connected. Read SYSTEMSTATU — does it show board_count: 1? Repeat for each of the three boards individually. All three pass alone but fail together = PSU cannot carry full three-board rail current (replace PSU). One specific board fails alone = that board has localized damage (U1/U2/R8/R9, PMIC, A32xx chip short) and is Tier-3 or Tier-4 repair. None enumerate alone = AUC / control-board fault, Tier-3 or Tier-4.

Re-flash the factory MM firmware via the AUC Web UI specifically for your model. Cross-flashing a 1246 image onto a 1346, or a 1366 image onto a 1446, will brick the control board because Canaan signs per-model and blocks downgrade. Pull the correct factory image from the Canaan firmware portal at avalonminer.org/firmware-document/, follow the Avalon Firmware Flash via AUC procedure, do not interrupt the flash once it has started. A failed MM flash turns E: no asics!! into a full dead-chassis ticket only recoverable with a JTAG or a donor control board.

Capture the control-board serial log at boot via USB-TTL adapter. Connect an FT232 / CH340 / CP2102 USB-TTL adapter to the control-board UART header (silkscreen varies by AUC revision — check the board). Capture the full boot log. MM boot sequence, MMCRCFAILED bursts tied to a specific chain index, asic_init_fail: chip N no ACK lines naming a specific A32xx position, IIC init failures, chain-discovery handshake timeouts all appear here. The serial log is the single highest-value diagnostic on a No-ASICs miner where the Web UI is alive but a chain is silent — it tells you whether the failure is bus-level, chip-level, or power-sequence-level in one capture.

DMM diode-check the hashboard's local power-sequence parts on the failing board. Per the Zeus Mining A11/A12 repair guide (pattern applies cross-A-series), U1 and U2 are the local power-sequence MOSFETs and R8 / R9 are the companion sense / gate resistors on A11/A12 boards; A13/A14/A15 have equivalents with revised part numbers. A burnt local sequence MOSFET from a reversed install sequence (negative-first on connect, negative-last on disconnect; reverse it and they burn instantly) reads dead-short or open in diode mode. All four parts are cheap to replace if you have SMD rework skill. If you find dead local sequence parts on the failing board, replace and re-test; if multiple boards share the same damage, a feeder event took them all out — stop and ship.

Bench-probe the four chain-discovery signals at the hashboard input — CK, D, R, C. Per the Zeus Mining repair-bench reference, when E: no asics!! is the fault you measure each group of signals in sequence at the board input. CK is the chain clock at 4 MHz square wave, D is data, R is reset, C is control. Any one dead means the bus never reaches the chip chain. CK dead at the board input = AUC clock-out trace or driver dead. D dead = data-side level-shifter or buffer. R stuck = reset latched and the board never released from reset. C dead = enable line not asserted. This isolates the signal-chain failure to a specific pin and from there to the part driving it.

Tune CGMiner --avalon7-aucspeed and --avalon7-aucxdelay if serial logs show intermittent MMCRCFAILED. Per the cgminer source, defaults are aucspeed 400000 (IIC bus clock in Hz) and aucxdelay 19200 (transfer delay). If the IIC bus is marginal — worn ribbon, vibration-stressed connectors, mixed-vendor ribbon stock — halving aucspeed to 200000 or doubling aucxdelay to 38400 brings marginal chains back. This tuning knob is undocumented in Canaan materials and lives only in the cgminer CLI — a hallmark of A-series diagnostic lore that survives in the community and in repair-shop notebooks. If the tune restores stability, schedule a ribbon replacement at next maintenance — don't leave the tune as your permanent fix.

Scope the rail at the failing hashboard's input during boot. A 50 MHz handheld scope captures the rail-up ramp during the MM power sequence. Healthy: clean step from 0 V to nominal in tens of milliseconds, flat thereafter with less than 200 mV of ripple. Damaged PSU or cable: oscillation, overshoot, or an incomplete ramp that never settles. Damaged per-board power sequence: rail comes up and immediately collapses as the local sequence MOSFET fails to latch. Compare the failing chain's rail capture side-by-side against one of the known-good chains — one scope capture separates PSU faults from per-board faults more reliably than DMM averaging.

Identify the failing A32xx chip position via serial log plus per-chip PVT telemetry. Each Avalon hashboard hosts a long string of Canaan A32xx chips in series on the IIC chain. The serial log's asic_init_fail: chip N line names the specific position that is not ACKing; PVT_V and PVT_T arrays from the cgminer API corroborate (the position reports zero voltage / zero temperature while its neighbours report nominal). A single dead chip position stops the entire chain because the chain is serial. If you can narrow the failure to one or two specific chip positions, the board is a candidate for bench-reflow; if the failure is spread across many positions, the board is likely a parts-donor.

Reflow the identified A32xx chip position on a preheat + hot-air rework station. This is the hard-end of Tier 3 and demands real skill: pre-heat the bottom side of the hashboard to roughly 150 °C to avoid thermal shock, top-side hot air at approximately 320 °C with a fine nozzle centred on the failing chip, pull just enough heat to remove the chip without lifting neighbouring pads, clean the board pads with braid and fresh flux, place a replacement A32xx (donor chip from a dead-board parts pool — these are not available retail), and reflow down. Re-check continuity with DMM diode mode before re-installing the board. If any of that sentence sounded hostile, skip to Step 22.

Inspect the AUC / control-board chain side for surge damage if Step 12 localized the fault to the control-board side. A surge event often takes out the control-board's input MOSFET or the per-chain I2C level-shifter / buffer. Signature: no per-chain data on a known-good hashboard placed in the affected slot, or flicker-then-dark LED behaviour on the AUC itself. Under magnification, look for hairline cracks in MOSFET packages, discolouration of solder pads, or cooked silkscreen near the chain socket. Replacement is a hot-air rework job on the control board. D-Central stocks parts-graded AUC3 and AUC4 boards and keeps failure-pattern logs across the A11/A12/A13/A14/A15 fleet — when component-level rework on a control board doesn't pencil out, a graded-salvage swap is a faster path back to mining.

Stop DIY and ship to D-Central when a single chain persistently fails after a confirmed PSU swap, a confirmed ribbon swap, and a confirmed MM firmware re-flash, and your Tier-3 tool chest (preheater, hot-air station, DMM diode mode, scope) does not include the skill to work at A32xx-class silicon level. Shotgun reflowing chip positions at home without a preheater or a controlled-temperature station lifts pads, damages adjacent traces, and turns a single-chip fault into a dead board. The economics rarely work out. D-Central's bench isolates each board on a programmable load, verifies each A32xx's PVT against a known-good baseline, and only returns boards that pass 24-hour burn-in. You mail us a board that is recoverable, you get back a board that hashes.

Ship the miner properly. Pack the chassis in its original Canaan box if you still have it, or double-box with 5 cm or more of foam on every side. Include the PSU so our bench can test your exact stack — a tired PSU that mostly works on your bench may be the real root cause of what looks like a chain-level fault. Include a note listing serial number, observed symptoms (screenshots of the failing SYSTEMSTATU and any captured PS / ECMM / ECHU / MWx / PVT_* values from the cgminer API, asic_init_fail: chip N lines from the serial console if you grabbed any), service history (when was it last opened, what was done, what was swapped), and contact info. Saves bench diagnostic time and saves you money. Canada-wide shipping standard, US / international welcomed.

Discuss the repair-vs-replace economics up front before committing bench hours. Per-board component-level repair plus burn-in at D-Central runs CAD $150-400 per board depending on generation and complexity. Full chassis bench rebuilds (PSU plus three-board plus control plus 24-hour burn-in) run CAD $800-1,800 depending on generation. Used A11/A12/A13/A14/A15 chassis prices on the secondary market move with BTC; for any specific generation we will quote honestly before committing bench hours. Sometimes the right answer is salvage the PSU, list the healthy boards, and put the cash toward newer silicon. Pleb mining is about survival and sovereignty over time, not defending every piece of silicon you have ever owned.