Avalon 1366 – Control Board Not Booting
Critical — Immediate action required
Symptoms
- Power LED on the controller board is completely dark — not blinking, not dim, not red. Off.
- No `ping` reply from the configured miner IP, and no DHCP lease appears in your router's lease table after a 5-minute boot wait.
- `cgminer` JSON API at port `4028` is unreachable — `curl http://<miner-ip>:4028 -d '{"command":"version"}'` returns connection refused or times out.
- No SSH to the controller — `ssh root@<miner-ip>` times out at the TCP handshake (not at password prompt).
- Web UI is unreachable — browser shows "site can't be reached" rather than a timeout-on-load.
- PSU is alive — fan spins, output `12V` measured at the PSU-to-chassis harness reads `12.0 – 12.6 V`, but the controller is still dark.
- Hashboards never spin up — no audible chip-init click on the AUC3 enumeration sequence, no fan ramp past the BMC's `30%` start cycle.
- Front-panel LCD is dark or showing artifacts — black screen, garbled characters, or stuck on the splash glyph.
- Front-panel button feels stuck — physically depressed, sticky, or won't return after press.
- Burnt smell from the controller-board area — discoloured silkscreen near the SoC, the `5V` buck inductor, or the input-protection MOSFET.
- Visible damage on the controller board — cracked SMT package, missing component, swollen capacitor, melted connector.
- The fault appeared after a power event — utility brownout, lightning, generator transfer, or PDU swap.
- The fault appeared after a firmware update — last action before darkness was an MM firmware flash that may have been interrupted.
- Recent service event — chassis opened in the last `30` days for paste refresh, hashboard swap, or PSU replacement.
Step-by-Step Fix
Hard-power-cycle at the PDU / breaker for a full `60` seconds. Wait for PSU bulk caps to discharge fully — not a Web UI reboot, not a power-button press. Power back up and watch the controller LEDs specifically for any activity in the first `90` seconds. While the chassis sits dark, sniff for burnt-component smell near the controller and inspect connectors under bright light for blackening, oxide, or bent pins. Cheapest possible fix; recovers wedged-state controllers without further intervention.
Open the chassis. Disconnect the LCD ribbon cable at the controller-side header. Disconnect the front-panel push-button cable at its header. Power up with both cables disconnected and the chassis open. If the controller's power LED comes alive bare, you've isolated the fault to the front-panel harness — inspect the LCD ribbon for crimps or punctures, press-test the button for stuck behaviour, and replace whichever cable shows the fault. This `30`-second test resolves a meaningful fraction of dark-controller tickets on the 1366.
Inspect the controller board under bright light with a `10x` loupe. Look for: blackened silkscreen, swollen electrolytic capacitors, cracked SMT package faces, melted connectors, or a burnt-component smell. Visible damage points to a specific repair category before you reach for the DMM, and saves you DMM-probing healthy components.
Reseat the PSU-to-controller harness firmly at both ends. Listen for the click. Inspect the harness pins for blackening or recession before reseating. Chassis-fan vibration over months works connectors loose; reseating is free and sometimes definitive on controllers that have been running `1+` year.
Confirm the `microSD` slot is empty before further triage. A leftover card from a previous recovery attempt — or a card with a wrong-model image — may be holding the boot ROM in a bad state. Eject any card present, then retry power-up.
Multimeter on DC, probe the `5V` test point on the controller board against chassis ground while AC is applied. Expect `4.95 – 5.10 V` sustained. Anything below `4.5 V` and the SoC will not release reset. If the rail is healthy, jump to Step 11 (UART capture) — fault is downstream of the regulator. If collapsed, continue to Step 7 to isolate.
Disconnect the controller's `12V` input from the PSU harness. Probe the PSU output side: expect `12.0 – 12.6V` open-circuit, sagging no more than `0.5V` under load. PSU-side dead = swap to a confirmed-working 1366-compatible Canaan PSU. Do NOT cross-connect Bitmain `APW9 / APW12` PSUs — pinouts differ and wrong-brand PSU is a documented controller-killer in the A-series.
With the `12V` rail confirmed at the controller's input but `5V` dead, isolate downstream short vs buck failure. Disconnect the USB peripheral header, the LCD ribbon, and the front-panel button cable one at a time. Re-probe `5V` after each disconnect. If `5V` recovers when a specific peripheral is unplugged, that peripheral has a `5V`-to-ground short and is the root cause; replace the affected harness.
Flash a `microSD` recovery image — model-specific for `1366` only. Verify the image identifier before flashing; cross-flashing a `1246` or `1266` image bricks the controller via Canaan signature mismatch. Insert into the controller's `microSD` slot, power up, and watch for boot. The boot ROM falls back to `microSD` when `eMMC` is corrupted; recovery images reflash `eMMC` automatically. This is the single highest-value Tier 2 procedure and resolves the entire `eMMC` corruption fault category without bench tooling.
Replace the controller-board `CR2032` RTC battery if present. A dead RTC battery on some A-series revisions causes the boot ROM to stall waiting for valid time before handing off to U-Boot. Cheap test, cheap part, definitive when it's the cause.
Connect a USB-TTL adapter (FT232 / CH340 / CP2102) to the controller's UART header at `115200 8N1` (verify baud and pinout against your specific revision's silkscreen). Capture serial output during a cold-boot attempt. Boot-ROM banner, U-Boot stage, kernel handoff, and any error strings appear on this console. If the boot-ROM banner appears, SoC is alive — fault is bootloader / kernel / `eMMC`. If zero serial output with `5V` confirmed healthy = SoC is dead, bench territory.
DMM diode-mode check the input-protection MOSFET on the `12V` side of the controller board. Damage from a surge event reads dead-short or open. Replace with a matching part — verify the package, voltage rating, and current rating against a parts-donor board or the silkscreen. Hot-air rework job, surface-mount work; achievable at home with a Quick 861DW-class station and steady hands.
DMM check the `5V` buck inductor and FETs. An open inductor or a shorted buck FET kills the `5V` rail with no visible damage. Component-level work; match exact part numbers from a donor board. If you don't have a donor 1366 controller and the buck is the failure point, ship — D-Central keeps matching graded parts on hand.
If `eMMC` corruption is confirmed via UART (U-Boot reports partition table errors) and `microSD` recovery doesn't take, the `eMMC` chip itself may be at end-of-life. eMMC replacement is hot-air rework on a fine-pitch BGA (`153`-ball typical). Possible at home with the right tooling; tight tolerances, post-install reflashing required.
Replace the SoC as a last DIY step only if you have a graded donor SoC and BGA rework experience. Most operators ship at this point. The SoC's BGA pitch is unforgiving — a misaligned reflow turns a controller-only repair into a full controller-board replacement, doubling the repair cost.
Stop DIY when UART confirms SoC death (no boot-ROM banner with `5V` healthy and no peripheral holding reset). SoC replacement requires a graded donor chip from a parts inventory and a BGA rework station with proper preheat. D-Central carries graded 1366-class controllers and SoC packages on the bench specifically for this fault category.
Stop DIY when surge damage extends beyond the input MOSFET. A clean lightning event sometimes takes out the `12V → 5V` chain entirely — input MOSFET, buck FETs, and downstream `3.3V` regulator all dead simultaneously. Shotgun-replacing rarely lands; bench-level isolation against a programmable load is the right answer.
Stop DIY when `eMMC` is dead and `microSD` recovery doesn't resolve. `eMMC` chip replacement requires the matching part graded against the controller's revision, hot-air rework on a `153-ball` package, and re-flashing the correct image post-installation. Achievable at home with a Quick 861DW or equivalent and steady hands, but most operators ship.
Ship safely. Pack the controller (or full chassis if you're not sure where the fault is) double-boxed with `5 cm+` of foam on every side. Include: serial number, observed symptoms, UART capture if you have one, photos of any visible damage, service history (last open, last firmware flash, recent power events), and contact info. That note saves D-Central's bench hours of reproduction time, which translates directly into lower repair cost for you.
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.
