Skip to content

How to fix “bad clock counter” on Bitmain Antminer S17 ASICs

Start with safety and logs

Power down before opening a miner, label cables before moving boards, and capture logs before repeated reboots erase useful evidence. Record model, firmware, pool, uptime, fan speed, temperature, reject rate, chain count, and the exact error text.

Confirm the fault class

Separate configuration faults from hardware faults first. Pool errors, DNS failures, bad worker names, overheating, weak power, fan faults, and missing hashboards can look similar from the dashboard but require different fixes.

Document the test path

Change one variable at a time and keep the before/after result. Note cable swaps, PSU swaps, firmware changes, pool changes, fan replacements, ambient temperature, and whether the fault follows a hashboard, control board, network, or power source.

When to escalate

Escalate to professional repair when there is a burned smell, melted connector, breaker trip, corrosion, repeated hashboard loss, liquid exposure, or a board-level fault that returns after a basic cable, power, firmware, and airflow check.

After the fix

Run the miner long enough to confirm stable accepted hashrate, fan behavior, chip temperature, reject rate, and pool-side reporting. A dashboard that looks normal for five minutes is not enough evidence for a recurring power, heat, or hashboard fault.

· D-Central · ⏱ 6 min read

Last updated:

“Bad clock counter” is not a counter overflowing — it is bmminer refusing to certify that your S17 hashboard runs at the frequency it was told to. During ramp-up the firmware gates the hash clock, reads back a cycle count from a sample of cores, and compares it against a threshold derived from the target frequency. If the count falls short, the chain fails validation and bmminer drops it. On a 3-chain S17 that is a third of the machine gone: an S17 Pro on profile_550_53T loses ~17.7 TH/s.

What the error actually reports

The miner reports this as a bad clock counter / clock-count-check failure on the affected chain in the kernel log. The routine behind it is the BM1397 firmware’s hash-clock-counter check — quick_dump_core_hash_clock_counter in the reverse-engineered BM1397 register map.

The BM1397 exposes eight indirect core registers reached through register 0x3C. Two matter here: Core Reg 5, Hash Clock Ctrl gates the hash clock; Core Reg 6, Hash Clock Counter is the value read back. Reverse-engineering of the T17/S17-era firmware puts the bar at ((freq << 3) / 50) × 0.8 — a sampled core must return at least ~70 at 550 MHz and ~51 at 400 MHz. The exact scaling matters less than its shape: the bar rises with the frequency you ask for.

That is why a marginal board passes at 400 MHz and fails at 650 MHz. It is also not an enumeration failure — the chips answered the set-address command (0x40) and the chain counted out — and a reboot will not clear it, because the check re-runs on every start.

Likely causes, most common first

  1. Domain voltage sag. An S17 board is 48 BM1397 chips in 12 voltage domains, 4 chips per domain, at roughly 1.55 V per domain and ~18.5 V across the string. Voltage is regulated per domain, never per chip: one leaky chip drags its rail down, the four chips sharing it cannot hold the target clock, and the count comes back short.
  2. A PSU that cannot hold the rail under ramp. The APW9 (S17, S17 Pro, T17) is rated 14.5–21 V DC at 170 A; the APW9+ (S17+, S17e, T17+, T17e) at 200 A. A tired supply sagging while the machine pulls 3,240 W on profile_750_72T (~1,080 W per board) shows up as a clock-counter retry loop long before it throws a power fault.
  3. Frequency above what aged silicon still validates. Boards lose headroom: one that was fine at 550 MHz two years ago can fail there now.
  4. Thermal. Dried paste, a lifted heatsink clip, or packed fins push chips past the point where they hold the requested clock. Check fans, fins and heatsink seating first.
  5. Clock distribution damage. Y1 is a 25 MHz crystal; CLK is forwarded chip to chip (CLKI in, CLKO out) across domain boundaries through coupling components. A cold joint there degrades the clock downstream: enumeration passes, the count check does not.

Diagnose before you desolder anything

  • Pull a clean kernel log. Note which chain fails and whether it is always the same one: reading the S17 kernel log.
  • Rotate the board. Move it to a different chain position with a different 18-pin ribbon cable. Error follows the board → the board; stays with the slot → control board or cable.
  • Drop the profile. Set profile_450_43T (450 MHz, 1,210 W, 43 TH) or profile_400_38T (400 MHz, 960 W, 38 TH) on an S17 Pro. S17-era profiles set frequency only — board voltage is fixed in cgminer.conf — so a lower profile lowers the bar the counter must clear. If the error clears, the board or supply is marginal, not dead.
  • Swap the PSU for a known-good APW9/APW9+. Field reality: the APW9 label says 200–240 V, and it does run on 110/120 V — at reduced output, so a high-power profile can leave the rail short during ramp. On 120 V stay on the low profiles above.

Electrical measurements

Safety, stated correctly: the hashboard rails are low-voltage DC — ~1.55 V per domain, ~18.5 V end to end — and are not a shock hazard. The PSU is: an APW9 holds several hundred volts on its PFC capacitors after you unplug it — do not open it. Keep the black probe on board ground, never the heatsink — it shorts a domain if it slips.

  1. Unpowered short check. Board off, 30 s for caps to discharge. Low-ohms or diode mode, black on board ground, red on each of the 12 domain test points. Compare all 12 against each other and a known-good board: the domain reading markedly lower than its neighbours is the shorted one. Do not use a high resistance range; healthy domains sit in the low single-digit ohms.
  2. Powered domain sweep. On a fixture, wait 2–5 minutes to stabilise, then read all 12. Healthy: every domain within ±50 mV of the others. 100 mV or more below average = partial short; well above = open. The string should land near 18.5 V: sagging under load but present (chips still enumerating) points at the boost stage — MOS, inductor, boost IC. Absent entirely is a different fault; the chain would not enumerate and you would be reading a “find 0 asic” error instead.
  3. Clock at the head of the chain. Scope CLKI at chip 1: a clean 25 MHz square wave. Absent = crystal Y1 or a broken trace. Ringing or collapsing amplitude along the domain boundaries means the clock is dying down the chain — what the counter reports. Documented S17e levels: CLK ~0.8 V ±0.1 V; CI/CO, RI/RO, RST swinging 0–1.55 V.
  4. Thermal camera (heatsink off, brief run): a cold chip among hot neighbours is dead; a hot spot is your short.

Board-level repair

  • Cold joints first. Reflow the clock and command coupling components at the domain boundary nearest the failing region before touching a chip.
  • Chip replacement. If a domain measures low unpowered and thermal imaging fingers one chip, replace it. Find the short before you power the board at profile frequency. Parts: ASIC repair parts.
  • Retest from the start: PT1 (enumeration), PT2 (pattern test), PT3 (frequency sweep). PT3 is the bench analogue of this error: it steps the clock up and verifies hash output at each step.

Verify the fix

  1. Re-run at the frequency you intend to mine at. A pass at 400 MHz proves nothing about 650 MHz.
  2. Confirm 48 chips on each chain, 144 total, then soak the unit 24 hours.
  3. Pull a fresh kernel log: zero recurrences of the clock-counter failure. A retry that succeeds on attempt three is still a failing board.
  4. Check per-chain hashrate: profile_550_53T should give roughly 17.7 TH per chain. A chain 20% under is not fixed.

Common mistakes

  • Declaring victory after PT1. Enumeration and clock validation are separate tests: a board that counts out all 48 chips can still fail the counter check.
  • Replacing chips before measuring domains. The sweep tells you which of the 12 rails to look at.

Related

D-Central

Bitcoin Mining Experts Since 2016

ASIC Repair Bitaxe Pioneer Open-Source Mining Space Heaters Home Mining

D-Central Technologies is a Canadian Bitcoin mining company making institutional-grade mining technology accessible to home miners. Thousands of miners repaired, 490+ products shipped from Canada.

About D-Central →

Related Posts

Start Mining Smarter

Whether you are heating your home with sats, building a Bitaxe, or scaling up — D-Central has the hardware, repairs, and expertise you need.

Browse Products Talk to a Mining Expert

Editorial review and limitations

Reviewed by D-Central's mining hardware and ASIC repair editorial team for practical accuracy, buyer risk, repair context, and operational assumptions. Verify current hardware price, stock, network difficulty, BTC price, power rate, shipping, tax, firmware, and device condition before buying, hosting, repairing, or retiring mining hardware.