"chain[1] get pll config err" — Root Cause Analysis

Summary

The chain[1] get pll config err, times N error indicates that ASIC chips on hashboard chain 1 are not responding to SPI register read commands during the PLL frequency ramping phase of initialization. This is a communication timeout — the control board sends a command to read PLL registers, but the chips never reply.

Error Source

The error originates from bmminer (/usr/bin/bmminer), not cgminer. Specifically from function sub_252f0 in the binary (sha256: c1c3952edb7b774446e7405c64e846d9c1c75a654ab76bda04d1d824c4b56a8b).

Log Breakdown

opt_multi_version = 65536, interval timeout = 3188016
freq = 485, percent = 90, hcn = 5404, timeout = 3188016
get min sweep matrix freq min=420,max:485
start inc freq,temp min:24,max:24
fixed step freq_start = 50, freq_end = 485, freq_step = 6.25
chain[1] get pll config err, times 2    ← 1st attempt, 2 retries left
chain[1] get pll config err, times 1    ← 2nd attempt, 1 retry left
chain[1] get pll config err, times 0    ← 3rd attempt, retries exhausted
chain[1] get pll config err, times 2    ← next freq step, retry counter reset
chain[1] get pll config err, times 1
chain[1] get pll config err, times 0

The miner is sweeping PLL frequency from 50 MHz → 485 MHz in 6.25 MHz steps. At each step it programs the PLL and then reads back the configuration to verify. Chain 1 fails verification at every step, exhausting all 3 retries before moving to the next frequency increment and failing again.

Code Path

sub_252f0 — PLL Configuration Verification

This function is called during hashboard initialization to verify PLL register programming:

1. Iterates over hash chains (0–3)
2. For the target chain (or all chains if param_1 == 0xFF):
   • Sends an SPI command via sub_73a18() → sub_72c98() to request PLL register values from all ASIC chips
   • Masks out reserved bits from the expected response
   • Calls sub_36d18() to collect and validate actual ASIC responses
3. Retries up to 3 times per frequency step (the times countdown in the log)
4. Between retries, sleeps for 100ms (usleep(0x186A0))

sub_36d18 — PLL Register Read-Back (the function that fails)

This is the response collector. It:

1. Verifies the chain exists (sub_23a88())
2. Acquires a mutex lock
3. Sends a register read command to the hashboard: sub_24dd0(chain, 1, 0, register_addr)
4. Polls a shared ring buffer at 0x5bd1c0 for individual ASIC chip responses
5. For each response, validates:
   • The chain ID matches
   • The ASIC index is within range
   • The register address matches the expected one
6. Stores each ASIC's PLL register value in an output array
7. Returns 1 (success) when ALL ASICs on the chain have responded
8. Returns 0 (failure) when:
   • Timeout: Total polling cycles exceed num_asics × num_domains × 5 without collecting all responses
   • No data: After 60 iterations (0x3C) of getting zero responses from the ring buffer

When sub_36d18 returns 0, sub_252f0 logs: chain[%d] get pll config err, times %d

All Three PLL Error Messages

Message	Condition	Meaning
get pll config err	sub_36d18() returns 0	ASIC chips timed out — did not respond to the SPI register read command at all
pll not the same	sub_36d18() returns 1, but ASIC values differ	ASICs responded but report inconsistent PLL values across chips
check pll config err	sub_36d18() returns 1, values match each other but not expected	All ASICs agree, but the value doesn't match what was programmed

The log shows only get pll config err — the most severe case: complete communication failure with chain 1 ASICs.

Cross-Reference with Other Firmware Versions

The same logic is confirmed in two other bmminer builds from the HashSource S19x repository:

• bmminer_81ec4af93dc2e6f2 — function sub_27E18 (equivalent to sub_252f0), calls sub_384FC (equivalent to sub_36d18)
• bmminer_1e47f3a45f6ff37c — function sub_283A0 (equivalent to sub_252f0), calls sub_38B38 (equivalent to sub_36d18)

All three firmware versions share identical logic: send PLL register read → poll ring buffer for responses → timeout = error.

Root Cause

SPI communication failure between the control board and the ASIC chips on hashboard chain 1. The chips are not responding to register read commands within the timeout window.

Likely Hardware Causes

1. Loose or damaged ribbon cable — The flat flex connector between the control board and chain 1 hashboard has poor contact, oxidized pins, or physical damage. This is the most common cause.
2. Dead ASIC chip breaking the daisy chain — BM1397 chips are daisy-chained on the SPI bus. One dead or unresponsive chip blocks communication to all downstream chips, preventing complete responses.
3. Power delivery issue — Chain 1 hashboard is not receiving stable voltage during PLL programming, causing ASICs to be unresponsive or unstable during register operations.
4. Damaged PCB traces — Physical damage to the hashboard's SPI data/clock traces interrupting the communication chain.

Supporting Evidence

• The error is isolated to chain 1 — chains 0, 2, and 3 are not reported, indicating a localized hardware issue rather than a systemic firmware or control board problem.
• The error is get pll config err (total timeout), not check pll config err (wrong value) or pll not the same (inconsistent values) — this means zero or insufficient responses are received, pointing to a communication-level failure rather than a PLL programming issue.
• Board temperature is very low (temp min:24, max:24 = 24°C), consistent with startup. Cold solder joints or marginal connections can be more problematic at lower temperatures.

Sources

• https://github.com/HashSource/hashsource_antminer_S19x/blob/master/bitmain_firmware/_binaries/bmminer_81ec4af93dc2e6f2.dec/sub_27E18%4027E18.c
• https://github.com/HashSource/hashsource_antminer_S19x/blob/master/bitmain_firmware/_binaries/bmminer_1e47f3a45f6ff37c.dec/sub_283A0%40283A0.c