Passer au contenu

Nous améliorons nos opérations pour mieux vous servir. Les commandes sont expédiées normalement depuis Laval, QC. Questions? Contactez-nous

Bitcoin accepté au paiement  |  Expédié depuis Laval, QC, Canada  |  Soutien expert depuis 2016

CTRL_FAIL Critical

Goldshell – Control Board Failure (No Web UI Response)

control board dead | no boot | SoC failure

Critical — Immediate action required

Affected Models: KD5 - KD6 - KD-MAX - KD6 SE - LT5 - LT5 Pro - LT6 - LT-LITE - CK5 - CK6 - HS5 - HS-LITE

Symptoms

  • No DHCP lease appears in your router for the miner's MAC address (typical Goldshell ranges: `C8:3F:26:*`, `D4:5D:64:*`, `00:E0:4C:*`)
  • `find.goldshell.com` returns zero devices on the LAN, even after a 2-minute scan with the laptop on the same subnet
  • `ping 10.10.10.10` (Goldshell's documented default fallback IP) times out
  • No web UI loads on `http://<any-IP>:80` to the miner's last-known IP - connection refused, never even a TCP handshake
  • SSH on port 22 to the miner's last-known IP returns 'Connection refused' with no banner (no `dropbear` running)
  • Status LED on the control-board face is solid red at the power port (per BT-Miners' indicator-light reference - this is the documented 'control board issue' pattern), or no status LED at all
  • Hashboard LEDs may still illuminate when the miner is powered (hashboard 12V is supplied directly from the PSU, not gated by the control board on most stack-series models)
  • Fans spin at base RPM but never ramp - they're hardwired to 12V via the PSU on stack series, and never receive PWM commands because the control board is dead
  • Factory reset via the `RST` pinhole (5-10 s hold) produces no LED change and no DHCP lease afterwards
  • Issue began after a power surge, a lightning storm, a PSU swap, prolonged operation in a damp / dusty environment, or a previous firmware brick where SD-card recovery failed
  • Ethernet activity LEDs on the rear RJ45 port are dark, or stuck on, or flicker erratically without traffic - the Microchip LAN8720 / LAN8742-class PHY is not negotiating link
  • No serial-console output on the on-board UART pads (if you have a USB-TTL adapter and have probed) - confirms the SoC itself is not running

Step-by-Step Fix

1

Cold-boot with Ethernet unplugged for 15 full minutes. Pull all cables. Wait 30 seconds. Plug PSU only. Wait 15 minutes. Watch the control-board status LED. The board may be in a slow-fsck state from a prior dirty shutdown and just need time. If after 15 minutes the LED still shows the dead pattern (solid red at power port, or fully dark), you've ruled out a slow-boot. Plug Ethernet last and watch for DHCP for another 5 minutes. No lease = proceed.

2

Try a different Ethernet cable into a different switch port. Goldshell PHYs are particular about cable quality and Auto-MDIX behaviour. A Cat5 cable that works fine on a laptop can fail to negotiate link with a Goldshell PHY that's already partly stressed. Use a known-good Cat5e or Cat6 patch cable, plug into a switch port you've verified working with another device, and recheck the rear link LED on the miner. Bypass any PoE injectors, mesh WiFi extenders with Ethernet ports, or VLAN-aware managed switch ports - put the miner on a flat L2 segment with your laptop and the router for testing.

3

Hold the `RST` pinhole for 30 seconds while powered. Most Goldshell stack-series miners have an `RST` pinhole on the rear panel near the network port. The documented procedure is 5-10 seconds, but a longer hold doesn't hurt - if the reset partition is going to load, it'll do so. Watch for any LED change. After release, wait 2 minutes, then check `find.goldshell.com` and your router DHCP table again. If still nothing, the reset partition is either unwritten (common on miners that were never properly initialized) or the corruption has reached the reset config too. Move on.

4

Try a different known-good 12V or 220V PSU. This is the cheapest test before opening the case. KD-BOX / Mini-DOGE / smaller BOX miners run on a 12V barrel - any quality 12V / 5A+ brick will substitute. Stack-series (KD5 / KD6 / LT5 / LT6 / CK5 / CK6 / HS5) run on a fan-cooled 220V PSU - if you have a spare from a parted-out unit, swap it. 30% of 'dead control boards' in the D-Central support inbox are actually starved control boards being fed by a sagging or dead PSU.

5

Open the case. Visually inspect the control board. Remove the 4-8 Phillips screws on the top cover. Disconnect any ribbon cables to the hashboards (mark orientation with a Sharpie BEFORE you pull). Look at the control board with a bright light and a magnifier. Check for: bulged or leaking electrolytic capacitors, scorched ICs (especially the regulators, the PHY, and the SoC), burnt traces, solder bridges, liquid residue, insect / rodent damage, missing components knocked off in shipping. Photograph anything suspicious. Visible damage = Tier 4 board swap, don't waste time on rail probes.

6

Probe the 12V input rail at the control-board side of the input connector. Multimeter on DC volts. Probe between the 12V pad and the GND pad on the input. With the miner powered: `12.0 ± 0.2 V` expected, stable, not wandering. If the input rail is at 0V or sagging, the issue is the cable from PSU to control board, not the board itself. Reseat the connector or replace the cable.

7

Probe the 3.3V rail at the eMMC chip's VCC pin OR a labelled test point. With miner powered. Expected: `3.3 ± 0.1 V`. The 3.3V rail feeds the eMMC and the Ethernet PHY - if it's down, both subsystems will fail. If the rail is at 0V, the 3.3V regulator IC has failed (typically a small 8-pin SOT-23 or QFN package near the eMMC chip) - this is a Tier 3 component-level fix or a Tier 4 board swap.

8

Probe the 1.35V rail near the DDR3 RAM IC. With miner powered. Expected: `1.35 ± 0.05 V`. The 1.35V rail feeds the MPU and the DDR3 RAM. If this rail is at 0V or wandering, the SoC cannot run. The 1.35V regulator typically fails when its output capacitors age out or when its inductor saturates from prolonged high-load operation. Tier 3 component-level fix or Tier 4 swap.

9

Reseat all internal cables and the eMMC SD card if present. Power off. Disconnect the 12V input. Disconnect every ribbon cable, the fan connector, the power-button cable, the SD card if you'd previously inserted one for recovery. Inspect each connector for bent pins or oxidation. Re-seat each one fully - listen for the click on push-push connectors. Re-power, watch the control-board LED for 5 minutes, then check DHCP. Sometimes a control board that's been 'dead' for a week comes back from a clean re-seat because a connector was 99% seated and the boot sequence was racing the contact.

10

Test the Ethernet PHY by plugging into a managed switch and inspecting the port stats. Plug the miner into a managed switch port (Mikrotik, Ubiquiti, anything with per-port stats). Power the miner. Look at the switch port's link state, negotiated speed, FCS error counter, and packet counter. Expected (healthy): link up at 100 Mbit full-duplex, zero FCS errors in 60 seconds, packet counter ticking up if the SoC is sending DHCP requests. If link won't come up at all: PHY is dead or the on-board cable from PHY to RJ45 is broken. If link comes up but packet counter never advances: PHY is alive, SoC is not reaching network init.

11

UART console: capture the SoC's boot output. USB-TTL adapter at 3.3V, 115200 8N1. Solder fine wires to the four UART pads (TX / RX / GND / VCC) - cross-reference with Braiins' BCB100 notes for pad identification on your specific board revision. Power the miner with the UART connected. Capture the boot log. A healthy boot shows: STM32 ROM banner -> U-Boot stages -> kernel decompression -> kernel boot messages -> userland scripts. Silent UART = SoC dead, board swap. U-Boot prints but kernel panics on rootfs mount = eMMC corruption, try SD recovery. Kernel boots but `eth0` shows `NO-CARRIER` = PHY dead, PHY chip swap.

12

PHY chip replacement (if isolated to PHY). With the SoC confirmed alive via UART and the only failure being `NO-CARRIER` on the Ethernet interface, the Microchip PHY chip is the issue. The chip is a QFN-32 or QFN-48 package. Hot-air rework station at `350 °C` / medium airflow, flux the pads, lift the dead chip. Place a known-good replacement (LAN8720A or LAN8742A - cross-check the original part number under magnification) and reflow. Reflux, clean with isopropyl, retest with UART and link-LED checks. A slipped placement bridges the QFN pads - if you don't have a hot-air bench, skip to Tier 4.

13

eMMC replacement (if isolated to eMMC wear). SoC alive on UART, U-Boot prints but kernel panics on rootfs mount. Replace the 4 GB eMMC with a known-good pre-programmed part (or an unprogrammed part flashed via in-system programming). The eMMC is BGA-153 - rework requires preheat, careful reflow, BGA reballing if reusing, and a genuine `burn-<model>.img` to write to the new chip. This is at the edge of DIY territory; even D-Central's bench prefers a full board swap unless we're recovering a board for which no replacement exists.

14

Regulator IC replacement (if isolated to a single rail). When Tier 2 rail probing identified a single dead rail (3.3V, 1.35V, or 0.65V), the regulator IC for that rail can be desoldered and replaced. The regulators are typically SOT-23-5, DFN, or QFN-12 packages. Cross-reference the silkscreen marking with a parts catalog (TI, Diodes Inc., ON Semi) to identify the exact P/N. Source from Digi-Key or Mouser. Hot-air swap. Probe the rail post-repair before reconnecting the rest of the miner. Cost: $2-15 CAD per IC; success rate at the bench: ~70% if the failure was clean, much lower if the failed regulator damaged downstream caps or ICs.

15

eMMC recovery via SD-card flash, last resort. Even if you suspect SoC death, try one SD-card recovery cycle before declaring the board dead. Email `hello@goldshell.com` for the `burn-<model>.img`, flash a quality 16 GB Samsung EVO Plus or SanDisk Industrial card with balenaEtcher, insert in the SD slot, cold-boot. If the SD-card boot path still produces no LED activity beyond the static red-at-power, the SoC isn't running anything - confirmed dead. Go to Tier 4.

16

When to stop DIY. Stop and ship to D-Central if: (a) UART is silent under all conditions (SoC dead - no DIY path), (b) you've replaced the PHY or a regulator and the symptoms haven't changed, (c) you've damaged a pad or trace during rework, (d) the board has visible burn damage spanning multiple components, (e) you're past the 2-hour mark and still not converging on a single failure mode, or (f) you don't have hot-air rework, magnification, and UART tools. Math is simple - a Zeus Mining replacement control board is $150 USD, D-Central swaps it for a labour fee, total turnaround is 5-7 business days. Burning your weekend chasing a $0.40 regulator IC isn't worth it.

17

What D-Central does at the bench. We confirm the diagnosis with UART and rail probes (the same Tier 2-3 procedure on bench gear), source the correct replacement control board for the exact model (KD5, KD6, KD-MAX, KD6 SE, LT5, LT5 Pro, LT6, CK5, CK6, HS5, HS-LITE - they're not interchangeable), swap the board, transfer pool config and worker name to the new board's eMMC via the web UI on first boot, run a 24-hour burn-in at nameplate hashrate, and ship back. Replacement boards sourced from Zeus Mining, LYS-SZ, Vipera Tech, and parted-out donor miners as needed. Canadian repair shop, no China round-trip.

18

Ship safely. Anti-static bag the control board if you're sending the control only; otherwise foam-cradle the whole miner in a rigid double-walled box. Include a note: model, serial number, exact symptoms ('no DHCP, fans spin, status LED solid red at power port'), what you've tried (PSU swap? RST hold? UART probe?), and whether the miner was ever port-forwarded to the public internet (relevant for the malware-rule-out). Ship to D-Central HQ - we'll send you a return label and a tracking number once the board arrives.

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.