Avalon Series – 4MHz Crystal Oscillator Y1 Fault
Warning — Should be addressed soon
Symptoms
- AvalonMiner status / `cgminer-api stats` reports one chain at `0` ASICs while remaining chains read normal counts (`0/120/120`, `120/0/120`, `0/108/108`)
- `kern.log` shows repeated `chain X detect 0 asic` or `no asic found on chain X` lines that never progress to `acn=N` enumeration
- Chassis red error LED is lit; AvalonMiner web UI flags a hashboard fault on the affected slot
- Thermal camera on the affected hashboard after `5 min` powered-on shows the entire chip array uniformly cold within `±2 °C` of ambient (no chip ever PLL-locked)
- PSU rails at the hashboard input under load measure clean (`~12.0 V`, `11.8-12.2 V`) yet the chain still reads `0`
- Re-seating data ribbon, swapping the ribbon for a known-good, and slot-swapping the board all leave the `0`-chip count unchanged
- Swapping the affected board to a known-working chassis still produces `0` chips on that board (rules out chassis / `MM3` / `MM4` / `AUC3` faults)
- Visual inspection at `10-20×` magnification near silkscreened `Y1` reveals a small `2-pad` or `4-pad` SMD package (`3.2 × 2.5 mm` or `5.0 × 3.2 mm` typical)
- Scope on `Y1`'s output pin shows zero AC activity — flat DC line at the rail bias point, no `4 MHz` waveform
- Fault appeared suddenly after a power event, thermal cycle, transit damage, mechanical flex, or solder-rework adjacent to `Y1`
- Board has `> 12 months` of deployment, or has seen inrush/transient/drop/flex events, or arrived in this state out-of-box from international shipping
Step-by-Step Fix
Hard power-cycle for `60 s` at the breaker, then boot. Wait `5 min` for the chip-init phase to complete. Re-check the chain count via the AvalonMiner web UI or `cgminer-api stats`. Real `Y1` failures don't return from a cold boot — but transient bus errors and wedged firmware state do. This rules out the cheapest possible cause before committing to anything else and clears about `1-in-10` phantom `0`-chip reports we see in the queue.
Capture the diagnostic baseline. SSH or use the AvalonMiner web UI to record per-chain `chain_acn`, `MM ID0 Ver` firmware version, full `kern.log` snapshot of the boot/chip-init sequence, and a short note describing when the fault appeared (post-power-event, post-shipping, out-of-box, after recent rework). Save to a text file. If you ship the board to D-Central, this snapshot saves us `1-2 hours` of bench diagnostic time and reduces your invoice.
Multimeter on DC at the PSU-to-hashboard connector under boot/init load. Expect `~12.0 V`, accept `11.8-12.2 V`. Probe the affected board's input separately from the working boards — a partially failing PSU branch can deliver clean rail to two boards and starved rail to the third, presenting like `Y1` failure on the dashboard but with a different root cause. If sag is present below `11.6 V` sustained, swap the PSU first.
Re-seat all data ribbons and power leads on the affected board. Power off at the breaker. Disconnect, visually inspect contacts under bright light for blackening, oxidation, bent pins, or dust. Reconnect firmly until you hear/feel the click. Loose ribbon contacts produce intermittent `0`-chip readings that look like `Y1` failure but recover after a clean re-seat. About `5-8%` of `0`-chip tickets are ribbon-only fixes.
Swap the affected hashboard to a known-good slot. Label the slots `0/1/2` (or however many your model has) with tape. If the `0`-chip count follows the board, the board itself is the problem and `Y1` becomes the prime suspect. If the count stays in the slot, the chassis / `MM3` / `MM4` / `AUC3` / cable is the problem — different repair path entirely (see related-errors list).
Thermal-cam the affected board after `5 min` of powered-on time. Open the chassis safely — a board with no chips initialising only draws `~5-15 W` standby, no airflow risk. Sweep a FLIR-class or Hti-Xintai thermal camera across the chip array. Uniformly cold chip array (within `±2 °C` of ambient) plus normal warmth on the PMIC / bus-driver area = `Y1` failure suspect confirmed. Selectively-cold or partially-warm = different fault, different repair path.
Visually inspect `Y1` and surrounding area under `10-20×` magnification. Use a stereo microscope or a phone macro at high resolution. Locate the silkscreened `Y1` reference — package is typically `3.2 × 2.5 mm` (`SMD-3225`) or `5.0 × 3.2 mm` (`SMD-5032`), `2-pad` or `4-pad` footprint, sitting close to the first chip in the daisy-chain. Look for cracked package, lifted pads, cold-joint solder, scorched flux, prior-rework damage, or impact marks. Crystals fail invisibly more often than visibly — proceed regardless of cosmetic state.
Continuity-check the load capacitors flanking `Y1` for shorts or opens. Multimeter on continuity. The load caps are typically `0402` or `0603` SMD ceramics on either side of `Y1` (commonly `12 pF` or `18 pF`). A shorted load cap kills the oscillator just as effectively as a dead crystal. If one reads as a dead short or open, replace the cap before you replace the crystal — cheaper, faster, and addresses the actual fault.
Verify line voltage at the panel under load. On `240 V` split-phase expect `235-245 V`; on `208 V` commercial expect `202-212 V`; on `220 V` European expect `215-235 V`. Persistent low line voltage produces PSU ripple that stresses flanking caps over time and can cause the `Y1` oscillator circuit to fail. If line voltage is the underlying issue, fix it before returning the repaired board to service or you will be repairing the next `Y1` in `6-12 months`.
Reflow `Y1` first as cheapest test before replace. Mask the surrounding area with Kapton tape — especially the first chip in the daisy-chain. Apply a small amount of liquid flux around `Y1`'s pads. Hot-air at `300-320 °C`, narrow nozzle, `~10 mm` standoff, slow circular motion for `15-25 s` until you see the solder reflow settle. Do NOT exceed `60 s` total at `300 °C+` — crystals tolerate brief reflow but degrade under sustained heat. Cool naturally, retest. About `25-35%` of `Y1` failures come back online after reflow alone — solder-joint crack, not dead crystal.
Scope `Y1`'s output to confirm the fault definitively. With a `100 MHz`+ digital scope and a `10×` probe, probe `Y1`'s output pin (or the first chip's `XIN` / `XTAL_IN` pin if more accessible) during chip-init. Healthy: clean `~4 MHz` AC, `~0.5-1.0 Vpp`. Flat DC line = `Y1` is dead, replace it (next step). Distorted / low-amplitude waveform = `Y1` is marginal, replace preventively. Clean `4 MHz` waveform but chain still `0` = downstream fault (chip's `XIN`, local trace, reset line) — Tier 4 bench job.
Replace `Y1` with a known-good `4 MHz` SMD crystal. Match package size — typical Avalon `Y1` is `SMD-3225` or `SMD-5032`, `2-pad` or `4-pad`. Match load-cap spec where readable (commonly `12 pF` or `18 pF`); when in doubt, match the working `Y1` from a healthy hashboard of the same model. Hot-air remove the dead `Y1` (`280-300 °C`, brief), clean pads with solder wick, re-tin lightly, place new crystal with tweezers, hot-air `260-280 °C` for `~15 s`. Cool naturally. Power up, re-check chain count. Total parts cost: `~$1 CAD`.
If `Y1` replacement doesn't restore the chain, replace the load capacitors flanking `Y1`. Hot-air remove, replace with matched-spec `0402` or `0603` ceramics (typically `12 pF` or `18 pF`), retest. If chain still reads `0` after this, the fault is upstream of `Y1` (rare — PCB trace damage, first-chip's `XIN` input dead, or reset-line fault). Stop DIY and ship to D-Central — the next steps need a test fixture and known-good chips for substitution.
Refresh thermal paste and pads on the entire hashboard while you have it open. You did the hard part — opened the chassis, removed the heatsink, ran rework — adding a `15-minute` paste refresh extends every chip on the board's life by `12-18 months`. Arctic MX-6 or Thermal Grizzly Kryonaut on the chips. Replace any thermal pads on PMIC and bus-driver ICs that look glassy, hardened, or compressed-non-rebounding.
Stop DIY and ship to D-Central when: (a) you don't own hot-air rework, microscope, and steady-hand SMD experience; (b) `Y1` reflow + replacement attempted but chain still reads `0`; (c) you see scorching, trace damage, or burnt-component odor near `Y1` from prior rework; or (d) two boards in the same rig develop `Y1` failures within `60 days` of each other (systemic, not isolated). The next step is test-fixture diagnosis and chip-level repair on the first chip in the daisy-chain — bench gear only.
D-Central bench process for `AVALON_XTAL_FAULT`: receipt scan and intake photos; test-fixture confirmation that the chain reads `0` and rails are clean; scope verification of `Y1`'s output; `Y1` reflow first, retest; if reflow fails, `Y1` replacement with a stocked `4 MHz` SMD crystal matched to the original package and load-cap spec; load-cap replacement if scope shows marginal waveform with the new crystal; post-repair `24-hour` burn-in at nameplate frequency; full board re-paste and re-pad while open. Turnaround: `5-10 business days` from receipt.
Forward-looking note: D-Central is exploring DCENT_OS support on Canaan/Avalon hardware as part of our open-source firmware roadmap. Currently DCENT_OS ships only on Antminer (Bitmain) silicon and is NOT an available fix for `AVALON_XTAL_FAULT` today. When/if Canaan support lands, per-board diagnostics including direct reads of `Y1` activity status, PLL lock state, and chain enumeration health will become first-class SSH endpoints. Watch d-central.tech/dcent-os for roadmap updates. Until then: stock Canaan `MM3`/`MM4` firmware and bench-level diagnosis are the toolset.
Ship safely. Pull the affected hashboard if you're confident pulling boards safely; otherwise ship the whole miner. Anti-static bag the board, double-box with `≥5 cm` of foam on every side, include the diagnostic snapshot from earlier steps and any thermal-cam photos you captured. Note specifically that you suspect `AVALON_XTAL_FAULT` / `Y1` failure on the work order — that single line saves us bench triage time, which directly reduces your invoice.
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.
