Skip to content

We're upgrading our operations to serve you better. Orders ship as usual from Laval, QC. Questions? Contact us

Bitcoin accepted at checkout  |  Ships from Laval, QC, Canada  |  Expert support since 2016

ERR_NO_HASHBOARD Critical

Antminer L7 – Hashboard Not Detected

Hashboard not found — `check_asic_number_with_power_on: Chain[X]: find 0 asic`. One of three L7 hashboards fails to enumerate at boot; miner runs at ~66% of nameplate Scrypt hashrate.

Critical — Immediate action required

Affected Models: Antminer L7 (all revisions: 8.0 Gh/s, 8.3 Gh/s, 8.8 Gh/s, 9.05 Gh/s, 9.3 Gh/s, 9.5 Gh/s)

Symptoms

  • Dashboard shows 2 of 3 chains hashing; one chain reads `X` / missing / offline in the miner status table
  • `kern.log` contains `check_asic_number_with_power_on: Chain[0|1|2]: find 0 asic`
  • Log shows `Chain X only find 0 ASICs, will power off hash board X` shortly after boot
  • Realized Scrypt hashrate reads roughly 66% of nameplate (approximately 6.0-6.3 Gh/s on a 9.05-9.5 Gh/s L7)
  • Wall-draw drops from ~3425 W (stock 9.5 Gh/s) to roughly 2.2-2.4 kW — the dead board is not pulling current
  • `fail to read pic temp for chain X` appears alongside the `find 0 asic` line in the log
  • Control-board red LED or solid red abnormal indicator on the front panel
  • Pool dashboard shows the miner online but persistently underhashing — no downtime, just a steady deficit
  • After a cold boot, the board is sometimes seen briefly and drops out once the chassis warms (thermal-cycle ribbon fault)
  • Failing chain consistently reports `0` ASICs across reboots — not an intermittent partial count like 20 or 25

Step-by-Step Fix

1

Hard power-cycle the miner at the wall or breaker for 60 seconds. Not a soft UI reboot — a full disconnect that drains residual rail charge and forces `bmminer` to cold-start the chain enumeration. This clears wedged states from a prior firmware update, voltage brown-out, or failed OTA. If the chain comes back, note the event and schedule a cable re-seat at your next maintenance window. A self-clearing event almost always returns within 30 days if the underlying cause is ribbon creep — don't ignore it.

2

Check the miner's log via the web UI. Log in to the L7's IP, open Miner Status / Kernel Log, and search for `find 0 asic`, `fail to read pic temp`, and `Chain X`. Screenshot the log. Note which chain (0, 1, or 2) is failing and whether a PIC-read error appears on the same boot cycle — the PIC error is a specific branch that saves you opening the chassis if the root cause is firmware-level. Missing this detail costs real bench time later.

3

Verify ambient intake temperature and airflow. Use an IR thermometer at the L7's front grille. Ambient above 35 °C or obstructed airflow (filter clog, stacked miners, dust within 15 cm of the front) can cause a marginal hashboard to drop at boot and mis-report as `ERR_NO_HASHBOARD`. Clear the airflow path, shop-vac the filter, wait for intake to drop below 30 °C, then reboot. A 5-minute check that has resolved genuine board-drop events on hot summer days.

4

Verify the PSU is delivering rated power. L7 stock is ~3425 W at the wall for a 9.5 Gh/s unit. Check the UI's power consumption readout. If it reads roughly two-thirds of expected (~2.2-2.4 kW), a chain is simply dead. If it reads normally but a chain is missing, the dead chain may be drawing through a short — power off immediately and escalate to Tier 2 before you damage the PSU or an adjacent hashboard.

5

Check Bitmain's firmware portal for a known-good image. Find your L7 hardware revision (9.05 / 9.3 / 9.5 Gh/s, or earlier 8.x). A stock recovery flash via SD card or USB can resolve a corrupted `bmminer` install that manifests as `find 0 asic`. Verify the firmware matches the hardware revision before flashing — a wrong image on a late-revision board produces stranger failures than you started with.

6

Remove the L7 top cover. Phillips #2 for cover screws, Torx T10 for chassis. Work on an ESD mat with a grounded wrist strap. Take photos of the interior before disconnecting anything: ribbon routing, cable colours, slot orientation. Photos save debugging time on reassembly — especially at 11 PM when your eyes are tired and the three heatsinks all look identical. Respect the fan blades on the way in and out.

7

Re-seat both ends of the failing chain's ribbon cable. ZIF-style connectors: flip the black latch 90 degrees, slide the ribbon straight out with no lateral force, inspect the gold fingers for blackening, green oxidation, or bent contacts. Wipe with 99% isopropyl on a lint-free swab. Reseat fully to the stop, close the latch firmly. Do both the hashboard and the control-board end. This single step resolves roughly 40% of L7 `ERR_NO_HASHBOARD` cases on the D-Central repair bench.

8

Swap the ribbon cable from the failing chain with a known-good ribbon from a working chain. Label them with tape first. Reboot. If `find 0 asic` now appears on the chain you moved the ribbon *to*, the ribbon itself is bad — order a replacement (D-Central stocks L7-compatible ribbons, $10-$30 CAD). If the fault stays on the original chain, the ribbon is fine, move on to Step 9.

9

Swap the entire hashboard into a different slot. Disconnect the suspect board, move it mechanically to a different slot, reconnect with that slot's known-good ribbon. Reboot and re-read the log. Fault follows the board = bad board (Tier 3). Fault stays in the slot with a different board = control board or slot-path fault (Tier 3/4). This single swap collapses the fault tree from six possible causes to two.

10

Measure PSU output under load at the board connector. Multimeter on DC, probe at the PSU-to-board connector while the two working chains are hashing. Verify the boost-input rail matches your L7's spec (check your hardware table — this is NOT a 12 V rail; L7 boost-input is revision-specific). If the rail sags more than 0.5 V under load vs at-rest, the PSU is tired. Swap with a known-good APW12-class PSU. Tired PSUs cause exactly this symptom.

11

Visually inspect the failing hashboard for burn marks, bulged capacitors, or discoloured MOSFETs. Look especially at the boost stage (large MOSFETs near power input) and the first/last BM1496 positions on the chain. Burn marks mean stop — rework station required, do not re-power without bench diagnosis. Bulged electrolytics: replace cap first, then retest. Cracked or discoloured MOSFET package: boost stage is dead, Tier 3 territory.

12

Flash DCENT_OS (D-Central's own open-source Antminer firmware — the Mining Hackers' option, recommended) for per-chip BM1496 diagnostics, per-domain voltage telemetry, and PIC-communication status. Alternatives: Braiins OS+, LuxOS, Vnish. All four expose the truth behind `find 0 asic` — which specific chip position didn't respond, or whether the PIC itself is offline. Let the miner stabilize 20 minutes. This is the single most valuable diagnostic step on an L7 after ribbon re-seat — DCENT_OS is open-source, Mining-Hacker-maintained, with all the diagnostic and tuning features of commercial alternatives and no vendor lock-in.

13

Reflow the first or last BM1496 chip on the failing chain if diagnostics isolate chip 0 or chip 29. Remove heatsink (L7 pads tear — have replacements ready). Clean old interface with 99% IPA. Flux the BGA joints of the target chip. Preheat board ~150 °C bottom-side, top with hot air at 310-330 °C for ~30 seconds, let cool naturally (do not force-cool — cracks solder). Re-paste with Arctic MX-6, reassemble. First-reflow success ~60-70% for chain-communication faults.

14

Replace a visibly-failed boost MOSFET if the failing chain's boost-stage MOSFET is discoloured, cracked, or reads short/open gate-to-source with the board depowered. L7 boost MOSFETs are typically TO-263 / DPAK packages — cross-reference the part number from working boards on the same miner. Soldering-iron + hot-air job, not a reflow job. Test the boost stage's domain output under no-load before reconnecting the data path.

15

Attempt full firmware re-flash or EEPROM recovery. Download the latest stable firmware for your specific L7 hardware revision from Bitmain, or flash DCENT_OS / Braiins OS+ / LuxOS / Vnish. Flash via SD card or the control board's recovery method. This repairs corrupted EEPROM identifiers that make a healthy hashboard look dead to the control board. Verify the hardware revision before flashing — wrong image on a late-rev L7 produces stranger failures than you started with.

16

Stop DIY and ship to D-Central when: a reflowed chip returns to `find 0 asic` within 30 days, multiple BM1496 chips dead on the same chain, boost stage faulty beyond MOSFET replacement (inductor / trace damage), capacitor bulging, burnt-component smell, or PCB delamination visible. Do not keep reflowing a non-responding board — each cycle degrades adjacent joints and turns a $120 repair into a $600 replacement.

17

Ship to D-Central ASIC Repair. We put the suspect L7 hashboard on a test fixture, run chip-by-chip isolation with a controlled load, measure every domain voltage under spec load, and identify the exact failure point. Repair options: chip replacement with graded BM1496 stock, MOSFET / PMIC replacement, PIC reflash, full board reflow. 24-hour burn-in at nameplate before ship-back. Turnaround 5-10 business days, Canadian repair bench, Canada / US / international accepted.

18

Ship safely. Remove the hashboard from the chassis, ESD bag it (proper anti-static bag, not a grocery bag), double-box with ≥5 cm foam on every side — BM1496 corner joints are the first casualty of a dropped parcel. Include a note: observed symptoms (chain number, `find 0 asic`, PIC status), any DCENT_OS / Braiins / LuxOS / Vnish diagnostic output, miner firmware version, your contact info. Skipping the note costs us diagnostic time, which costs you repair dollars.

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.