Antminer S21 Control Board Diagnostics

Step 1: Power and Boot Verification

Check if the control board is receiving power:

1. With the PSU connected and AC power on, measure the 3.3V rail on the control board (test point near the SoC or at the voltage regulator output)
2. Expected: 3.3V ±0.1V
3. If 0V: the onboard voltage regulator has failed, or 12V input is not reaching the board

Check boot progress:

1. After powering on, the green LED should start blinking within 5–10 seconds
2. The boot process takes 60–120 seconds
3. If the LED never illuminates, the SoC may not be booting — this could indicate NAND corruption, dead SoC, or power rail failure

Serial console debugging (advanced): If the board does not boot, connect a USB-to-TTL adapter to the UART pads on the control board:

• Baud rate: 115200
• Data: 8N1 (8 data bits, no parity, 1 stop bit)
• Voltage: 3.3V — do NOT use a 5V serial adapter

The serial output will show the U-Boot bootloader messages and Linux kernel boot log, which can identify where the boot process fails.

Step 2: Network Diagnostics

If the miner boots but is unreachable on the network:

Physical layer:

1. Check the Ethernet cable — try a known-good cable
2. Verify the network LED on the control board blinks when the cable is connected
3. Try a different port on your switch/router
4. Check if the switch port shows link activity

IP address discovery:

1. Check your DHCP server's lease table for new devices
2. Use an IP scanner tool (e.g., nmap -sn 192.168.1.0/24) to find the miner
3. Press the IP Report button on the control board — it will announce its IP via the IPReporter protocol (requires Bitmain's IP Reporter tool on the same network)

SSH access:

# Default SSH credentials
ssh root@<miner-ip>
# Default password: (varies by firmware version, commonly blank or "admin")

# If SSH is not responding, try:
ping <miner-ip>
nmap -p 22,80,443,4028 <miner-ip>

Common network issues:

• No DHCP lease: The miner's Ethernet controller may have failed. Check for physical damage to the RJ45 jack or the PHY chip.
• IP conflict: Two devices with the same static IP. Reset the miner to DHCP mode via SD card recovery.
• Wrong subnet: If the miner was configured with a static IP on a different subnet, it will not respond. Use serial console to check and change the network configuration.

Step 3: Hashboard Detection Issues

The control board communicates with each hashboard through the 18-pin connector via UART. If one or more hashboards are not detected:

Check the physical connection:

1. Power off and reseat the 18-pin data cable on both the control board and hashboard ends
2. Inspect the connector for bent, oxidized, or damaged pins
3. Try swapping cables between working and non-working hashboard slots
4. Try connecting the suspect hashboard to a known-good slot

Software-side diagnostics:

# SSH into the miner
ssh root@<miner-ip>

# Check detected hashboard chains
cat /tmp/freq.txt

# Check kernel log for chain detection
dmesg | grep -i "chain"

# View mining software status
cgminer-api devs

# Check UART communication
cat /proc/tty/driver/serial

Interpreting chain detection results:

• "chain 0: 129 chips" — hashboard in slot 0 is fully detected
• "chain 1: 0 chips" — hashboard in slot 1 not communicating
• "chain 2: 80 chips" — hashboard in slot 2 has a partial chain break (see Hashboard Repair Guide)

If no hashboards are detected on any slot:

• The issue is likely the control board itself — the UART transceivers or FPGA logic may have failed
• Check the 1.8V I/O voltage rail that powers the UART level shifters
• Verify the FPGA is programmed correctly (NAND corruption can cause this)

Step 4: NAND Flash and Firmware Issues

The NAND flash stores the Linux operating system, mining software, and configuration. Corruption can cause boot failures, erratic behavior, or hash rate issues.

Symptoms of NAND corruption:

• Miner boots to a blank or partial web interface
• Mining software crashes and restarts repeatedly
• Settings do not persist after reboot
• Boot loop (LED cycles through patterns repeatedly)
• "NAND error" or "UBI error" in kernel log

Recovery via SD card:

1. Download the correct S21 firmware image from Bitmain's support page
2. Format a microSD card (2–16GB) as FAT32
3. Extract the firmware archive — you should have files like upgrade.bin or a filesystem image
4. Copy the firmware files to the root of the SD card
5. Power off the miner completely
6. Insert the SD card into the control board's slot
7. Power on — the LEDs should indicate recovery mode (red + green alternating)
8. Wait 5–10 minutes for the flash process to complete
9. The miner will reboot automatically when done
10. Remove the SD card after successful boot

See Firmware Recovery Guide for detailed step-by-step instructions.

Step 5: Fan Controller Diagnostics

The control board manages fan speed via PWM signals based on temperature readings from the hashboards. Fan issues can cause thermal shutdowns.

Common fan-related control board issues:

1. "Fan speed error" — the control board is not receiving the fan's tachometer signal

   • Check the 4-pin fan connector on the control board for bent pins
   • Verify the fan spins when manually powered (connect to 12V directly)
   • Check the tachometer pull-up resistor on the control board (4.7kΩ to 3.3V)

2. Fans at 100% constantly — temperature sensor failure or firmware issue

   • Check if temperature readings are abnormal in the web dashboard
   • SSH in and check: cat /tmp/temp.txt
   • If temperatures show -1 or 999, the sensor communication has failed

3. Fans not spinning at all — PWM output failure or fan connector damage

   • Check for 12V at the fan connector power pins
   • Check for PWM signal at the fan connector (use oscilloscope — should see 25kHz PWM)
   • Try a known-good fan in the same connector

# Check fan status via SSH
cgminer-api fans

# View temperature readings
cat /tmp/temp.txt

# Check fan speed settings
cat /config/cgminer.conf | grep fan

Step 6: Component-Level Repair

If the control board has a specific component failure (uncommon but possible):

Voltage regulator replacement: The control board has multiple voltage regulators (12V→5V→3.3V→1.8V→1.0V). If one fails:

1. Identify the failed regulator by measuring output voltages
2. Check for shorts on the output rail
3. Replace the regulator IC and test

Ethernet PHY replacement: If network hardware has failed (no link, no LED activity even with good cable):

1. Check the Ethernet PHY chip for physical damage
2. Measure the 3.3V supply to the PHY
3. Check the 25MHz crystal oscillator near the PHY (should show oscillation on scope)

NAND flash replacement (advanced): If the NAND flash is physically damaged and SD card recovery fails:

1. Desolder the NAND flash using hot air
2. Solder a replacement NAND of the same type and capacity
3. Program the NAND via SD card boot
4. This requires BGA rework skills and exact part matching