UART, SPI, and I2C Protocols in Mining Hardware

Introduction

Every ASIC miner depends on reliable serial communication between its components. The control board talks to hashboard chips over UART, configuration data lives in SPI flash, and temperature sensors report over I2C. When any of these communication links fail, the miner loses hashrate, misreads temperatures, or refuses to boot entirely.

This guide covers the three serial protocols you will encounter in mining hardware — UART, SPI, and I2C — with a focus on how they are used in real miners, what signals look like on a logic analyzer, and how to diagnose failures.

Why Serial Communication Matters in Miners

A typical Antminer S19-series machine has three hashboards, each containing 70+ ASIC chips, multiple temperature sensors, an EEPROM chip, and a PIC microcontroller — all of which need to communicate with the control board. The protocols that carry this data are the nervous system of the miner.

Understanding these protocols allows you to:

• Diagnose "missing chips" caused by broken UART chains
• Read temperature sensors directly via I2C when firmware reports wrong values
• Recover bricked boards by reflashing SPI NOR flash
• Verify voltage enable commands sent through PIC I2C bridges
• Capture and decode traffic using logic analyzers for root-cause analysis

UART (Universal Asynchronous Receiver/Transmitter)

UART is the most common protocol for chip-to-chip communication on hashboards. It is asynchronous — there is no shared clock signal. Instead, both the transmitter and receiver agree on a timing parameter called the baud rate.

How UART Works

A UART link uses two data lines:

• TX (Transmit) — data output from the sender
• RX (Receive) — data input to the receiver

Each byte is framed with start and stop bits:

Idle ──┐   ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌───
       │   │D│ │D│ │D│ │D│ │D│ │D│ │D│ │D│ │Stop
       └───┘0└─┘1└─┘2└─┘3└─┘4└─┘5└─┘6└─┘7└─┘
       Start                                   Bit
       Bit        8 Data Bits (LSB first)

Key parameters:

UART in Mining Hardware

Bitmain miners use UART as the primary communication protocol between the control board and ASIC chips on each hashboard. The chips are wired in a daisy chain, where the TX output of one chip connects to the RX input of the next:

Control Board                    Hashboard
┌──────────┐    ┌──────┐    ┌──────┐    ┌──────┐         ┌──────┐
│          │TX→ │Chip 0│TX→ │Chip 1│TX→ │Chip 2│TX→ ... →│Chip N│
│  SoC     │    │      │    │      │    │      │         │      │
│          │←RX │      │←RX │      │←RX │      │←RX ... ←│      │
└──────────┘    └──────┘    └──────┘    └──────┘         └──────┘

The control board sends commands down the TX chain (register writes, job distribution), and chips send responses back up the RX chain (nonce results, register reads).

Baud Rates in Bitmain Miners

Bitmain miners use two different baud rates during operation:

The enumeration phase runs at the slower baud rate for reliability. Once all chips are discovered and configured, the firmware switches to the faster mining baud rate for throughput.

UART Command Frame Format (Bitmain)

Bitmain ASIC chips use a structured command frame:

┌──────┬──────┬──────────┬───────┬──────────────┬──────────┐
│ 0x55 │ 0xAA │ CMD_TYPE │ LEN   │ PAYLOAD      │ CRC      │
│ sync │ sync │ (1 byte) │(1 byte)│ (variable)  │ (2 bytes)│
└──────┴──────┴──────────┴───────┴──────────────┴──────────┘

• 0x55 0xAA — Sync header, marks the start of a frame
• CMD_TYPE — Command identifier (e.g., register read/write, job, nonce response)
• LEN — Total frame length including all fields
• PAYLOAD — Command-specific data (chip address, register values, job data)
• CRC — CRC-5 or CRC-16 for integrity checking (varies by chip generation)

Example: Read register 0x00 (ChipAddress) from all chips
TX: 55 AA 01 05 00 00 1C

Breakdown:
  55 AA     → sync bytes
  01        → CMD_TYPE: register read (broadcast)
  05        → LEN: 5 bytes total payload
  00 00     → register address 0x0000
  1C        → CRC-5

Example: Read register 0x00 (ChipAddress) from all chips
TX: 55 AA 41 05 00 00 0A

Breakdown:
  55 AA     → sync bytes
  41        → CMD_TYPE: register read (broadcast)
  05        → LEN: 5 bytes total payload
  00 00     → register address 0x0000
  0A        → CRC-5

Nonce Response Frame

When a chip finds a valid nonce, it sends a response back up the chain:

┌──────┬──────┬──────────┬───────┬──────────┬────────┬──────────┬──────────┐
│ 0xAA │ 0x55 │ CMD_TYPE │ LEN   │ NONCE    │ JOB_ID │ CHIP_ADDR│ CRC      │
│ sync │ sync │ (1 byte) │(1 byte)│ (4 bytes)│(varied)│ (varied) │ (2 bytes)│
└──────┴──────┴──────────┴───────┴──────────┴────────┴──────────┴──────────┘

Note: Response sync bytes are reversed (0xAA 0x55) compared to commands (0x55 0xAA)

UART for Debugging: Serial Console Access

Beyond chip communication, UART is used for debug console access on control boards. Most control boards expose a 3.3V UART header that gives you a Linux serial console:

Control Board Debug Header:
┌─────┬─────┬─────┬─────┐
│ GND │ TX  │ RX  │ 3V3 │
└─────┴─────┴─────┴─────┘

Connection: USB-to-UART adapter (e.g., CP2102, FT232, CH340)
Settings:   115200 baud, 8N1, no flow control

This gives you direct terminal access to the miner's Linux operating system — invaluable for debugging firmware issues, reading kernel logs, or recovering from network configuration mistakes.

SPI (Serial Peripheral Interface)

SPI is a synchronous protocol — it uses a shared clock signal, so both sides agree on exactly when to sample data. SPI is faster than UART and supports full-duplex communication (data flows in both directions simultaneously).

How SPI Works

SPI uses four signals:

          Master                      Slave
       ┌──────────┐               ┌──────────┐
       │          │──── SCK ─────→│          │
       │          │──── MOSI ────→│          │
       │   SoC /  │←─── MISO ────│  Flash / │
       │   FPGA   │──── CS ─────→│  ASIC    │
       └──────────┘               └──────────┘

The master controls the clock and pulls CS low to select which slave device it is talking to. Data is shifted out on MOSI and simultaneously shifted in on MISO — one bit per clock cycle.

SPI Timing and Modes

SPI has four modes defined by clock polarity (CPOL) and clock phase (CPHA):

Most SPI devices in mining hardware use Mode 0 (CPOL=0, CPHA=0).

SPI in Mining Hardware

SPI serves several roles in ASIC miners:

1. Boot Flash (SPI NOR)

The control board's SoC boots from an SPI NOR flash chip (typically 16–32 MB). This contains the bootloader, Linux kernel, rootfs, and miner firmware.

Control Board:
┌──────────┐         ┌───────────┐
│          │── SCK ─→│           │
│  Allwinner│── MOSI→│  SPI NOR  │
│  H3 / H6 │←─ MISO─│  Flash    │
│  SoC     │── CS0 ─→│  (W25Q128)│
└──────────┘         └───────────┘

2. FPGA Communication

Some mining hardware (especially Avalon miners and older Whatsminer models) uses FPGAs as an intermediary between the control SoC and ASIC chips. The SoC communicates with the FPGA over SPI:

SoC ←──SPI──→ FPGA ←──UART/Custom──→ ASIC Chip Chain

The FPGA handles clock generation, job distribution fan-out, and nonce collection — offloading the time-critical work from the Linux-based SoC.

3. SPI Daisy Chain on Hashboards

Some ASIC chip architectures support SPI daisy-chaining, where the MISO output of one chip connects to the MOSI input of the next:

                CS (active low, active for all chips)
                │
Master ── SCK ──┬──────────┬──────────┬──────────┐
                │          │          │          │
          MOSI ─→ Chip 0   → Chip 1   → Chip 2   │
                │  MISO out│  MISO out│  MISO out│
                │    │      │    │      │    │    │
                │    └──MOSI┘    └──MOSI┘    └──→ MISO back to master

In this configuration, data shifts through the entire chain. The master sends N bytes (one per chip) and simultaneously receives N bytes of response data. This allows reading from or writing to all chips in a single transaction, but requires precise framing — the master must know exactly how many chips are in the chain.

SPI Clock Speeds in Miners

I2C (Inter-Integrated Circuit)

I2C (pronounced "I-squared-C") is a two-wire synchronous bus protocol designed for low-speed communication with multiple devices. It is the standard protocol for sensors, EEPROMs, and auxiliary controllers in mining hardware.

How I2C Works

I2C uses just two signals, both open-drain with external pull-up resistors:

        VCC (3.3V)
         │    │
         Rp   Rp       Rp = Pull-up resistors (typically 4.7kΩ)
         │    │
    SDA ─┴────┴─────┬─────────┬─────────┬──────
                     │         │         │
    SCL ─────────────┼────┬────┼────┬────┼──────
                     │    │    │    │    │
                  ┌──┴──┐ │ ┌──┴──┐ │ ┌──┴──┐
                  │Sensor│ │ │EEPROM│ │ │ PIC │
                  │0x48  │ │ │0x50  │ │ │0x20 │
                  └─────┘ │ └─────┘ │ └─────┘
                          │         │

I2C Transaction Format

Every I2C transaction follows this sequence:

START → ADDRESS (7 bits) + R/W (1 bit) → ACK → DATA → ACK → ... → STOP

Detailed bit-level view:
┌─────┬────────────────┬───┬─────┬────────────────┬───┬─────┬──────┐
│START│ A6 A5 A4 A3 A2 │A1 │A0 RW│ ACK │ D7 D6 D5 D4 │D3 │D2 D1 │D0 ACK│STOP │
└─────┴────────────────┴───┴─────┴─────┴────────────┴───┴─────┴──────┘
  SDA   ←── 7-bit address ──→ 0=W  Slave  ←── 8-bit data ──→  Slave
  falls                       1=R  pulls    (register or     pulls
  while                            SDA low  payload)         SDA low
  SCL high

Key concepts:

• START condition — SDA falls while SCL is high
• STOP condition — SDA rises while SCL is high
• ACK — Receiver pulls SDA low during the 9th clock cycle
• NACK — Receiver leaves SDA high (indicates end of read or error)
• Addresses — 7-bit (0x00–0x7F), with some reserved. Device addresses are set by hardware pins or fixed in silicon

I2C in Mining Hardware

I2C is used extensively on hashboards for non-chip-chain peripherals:

1. Temperature Sensors (LM75A)

LM75A temperature sensors are placed across the hashboard to monitor chip temperatures. Each sensor has a configurable 3-bit address:

Reading temperature from an LM75A:

Write phase (set register pointer to temp register 0x00):
START → [0x48 << 1 | 0] → ACK → [0x00] → ACK → STOP

Read phase (read 2 bytes of temperature):
START → [0x48 << 1 | 1] → ACK → [MSB] → ACK → [LSB] → NACK → STOP

Temperature decode:
  MSB = 0x1A, LSB = 0x80
  Raw = 0x1A80 >> 5 = 0x0D4 = 212
  Temp = 212 × 0.125 = 26.5°C

2. EEPROM (AT24C02)

Each hashboard contains an AT24C02 EEPROM (2 Kbit / 256 bytes) that stores board identification data:

Reading EEPROM byte at address 0x10:
START → [0x50 << 1 | 0] → ACK → [0x10] → ACK →
  RESTART → [0x50 << 1 | 1] → ACK → [DATA] → NACK → STOP

The EEPROM stores critical calibration data. If it is corrupted or erased, the miner will fail to initialize the hashboard or may apply incorrect voltages.

3. PIC Microcontroller Bridge (Antminer Hashboards)

Antminer hashboards use a PIC16F1704 microcontroller as an I2C bridge between the control board and the hashboard's on-board I2C devices (temperature sensors, voltage regulators). The PIC acts as a gateway — you send it commands, and it relays operations to devices on its local bus.

PIC I2C Addresses:

PIC Command Frame Format:

TX (Master → PIC):
┌──────┬──────┬───────┬─────────┬────────────┬──────────┐
│ 0x55 │ 0xAA │  LEN  │   CMD   │  PARAMS    │ CHECKSUM │
│ sync │ sync │(1 byte)│(1 byte)│ (variable) │ (1 byte) │
└──────┴──────┴───────┴─────────┴────────────┴──────────┘

RX (PIC → Master):
┌───────┬─────────┬──────────┬────────────┬──────────┐
│  LEN  │   CMD   │  STATUS  │   DATA     │ CHECKSUM │
│(1 byte)│(1 byte)│ (1 byte) │ (variable) │ (1 byte) │
└───────┴─────────┴──────────┴────────────┴──────────┘

Checksum = (sum of bytes from LEN to last param) & 0xFF
Note: The 0x55 0xAA sync bytes are NOT included in the checksum calculation.

Critical PIC Commands:

I2C Address Scanning

When diagnosing a hashboard, the first step is often an I2C bus scan to see which devices respond:

I2C Bus Scan Results (typical healthy Antminer hashboard):

     0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- 21 -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Devices found:
  0x21 = PIC16F1704 microcontroller
  0x51 = AT24C02 EEPROM (PIC address + 0x30)

Note: Temperature sensors (0x48-0x4B) are BEHIND the PIC bridge
      and will NOT appear in a direct bus scan.

If you see no devices responding, check:

• Pull-up resistors on SDA/SCL (should be 4.7k to 3.3V)
• SDA or SCL shorted to ground (stuck bus)
• Connector pin damage between control board and hashboard

Protocol Debugging Tools

Effective diagnosis of communication failures requires the right tools. Here is what professional mining hardware technicians use.

Logic Analyzers

A logic analyzer captures digital signals and decodes them into human-readable protocol data. This is the single most important tool for diagnosing serial communication issues.

Recommended hardware:

What to capture:

• UART chip chain: Connect to TX/RX between control board connector and first chip. Decode at 115200 baud for enumeration, 1.5 Mbaud for mining.
• I2C bus: Connect to SDA and SCL on the hashboard connector. Decode with I2C analyzer, watch for NAK responses.
• SPI flash: Connect to SCK, MOSI, MISO, CS. Useful for capturing boot sequences.

Saleae Logic 2 Setup for UART capture:

1. Connect Ch0 → TX line, Ch1 → RX line, GND → board ground
2. Add "Async Serial" analyzer:
   - Input channel: Ch0 (or Ch1)
   - Bit rate: 115200 (enumeration) or 1500000 (mining)
   - Bits per frame: 8
   - Stop bits: 1
   - Parity: None
   - Bit order: LSB first
3. Set sampling rate ≥ 4× baud rate (6 MS/s minimum for 1.5 Mbaud)
4. Trigger on falling edge of TX (start bit)

PulseView Setup for I2C capture:

1. Connect Ch0 → SCL, Ch1 → SDA, GND → board ground
2. Add protocol decoder: I2C
   - SCL: Ch0
   - SDA: Ch1
   - Address format: shifted (shows 7-bit address)
3. Stack additional decoders if needed:
   - "eeprom24xx" for AT24C02 EEPROM reads
   - "lm75" for temperature sensor data
4. Set sampling rate ≥ 10× bus speed (1 MS/s for 100 kHz I2C)

Oscilloscopes

While logic analyzers show you decoded digital data, an oscilloscope shows you the analog signal quality. Use it when you suspect hardware-level issues:

• Rise/fall times — Slow edges indicate weak pull-ups or excessive capacitance
• Voltage levels — Should be clean 0V / 3.3V swings (or 0V / 1.8V for some ASIC chips)
• Ringing and overshoot — Signal integrity problems that cause bit errors
• Bus contention — Two devices driving the bus simultaneously (shows intermediate voltage levels)

Good I2C signal:               Bad I2C signal (weak pull-ups):

3.3V ─┐     ┌─┐   ┌──         3.3V ─╮      ╭─╮    ╭──
      │     │ │   │                   ╲    ╱   ╲  ╱
      │     │ │   │            1.8V    ╲  ╱     ╲╱     ← never reaches 3.3V
      │     │ │   │                     ╲╱
  0V ─┘     └─┘   └──           0V ─────╯
      ↑ clean     ↑ clean             ↑ slow   ↑ rounded
        edges       edges               edges    corners

Software Tools for Serial Communication

# Scan I2C bus 0 on a Linux-based control board
i2cdetect -y 0

# Read temperature from LM75A at 0x48
i2cget -y 0 0x48 0x00 w

# Open serial console to miner control board
minicom -D /dev/ttyUSB0 -b 115200

# Read SPI flash chip for firmware backup
flashrom -p ch341a_spi -r firmware_backup.bin

Common Communication Failures

Understanding what goes wrong with serial communication is just as important as understanding how it works. Here are the most frequent failure modes seen in mining hardware repair.

UART Failures

SPI Failures

I2C Failures

Stuck Bus (SDA Held Low)

The most common I2C failure. A slave device holds SDA low indefinitely, blocking all communication on the bus.

Normal bus (idle):
SCL: ───────────────────── HIGH
SDA: ───────────────────── HIGH

Stuck bus:
SCL: ───────────────────── HIGH
SDA: _____________________ LOW (stuck!)
     ↑ slave holding SDA low — no other device can communicate

Cause: A slave device got into a bad state mid-transaction (due to power glitch, noise, or master reset during transfer) and is waiting for clock cycles that will never come.

Recovery procedure:

1. Toggle SCL manually (9+ clock pulses) while SDA is released — this lets the stuck slave finish its byte
2. Send a STOP condition (SDA rising while SCL is high)
3. If toggling fails, power-cycle the board
4. If power-cycling fails, the slave device may be damaged

Address Conflicts

Symptom: Wrong data returned, or a device responds intermittently.

Cause: Two devices on the same bus have the same address. This can happen with temperature sensors that have address pins left floating.

Diagnosis: Check the schematic for address pin configuration. Use a logic analyzer to see if multiple devices ACK the same address.

Pull-Up Resistor Failures

Symptom: I2C communication intermittent or completely fails. Oscilloscope shows SDA/SCL signals not reaching VCC properly.

Typical pull-up values for mining hardware:

Diagnosis: Measure resistance from SDA to VCC and SCL to VCC with the board powered off. Should match the pull-up resistor value. If open, the resistor is damaged or desoldered.

Key Takeaways

1. UART is the primary chip-chain protocol in Bitmain miners. A break anywhere in the daisy chain silences all downstream chips. Always check for broken traces when you see "missing chips" in miner logs.

2. SPI connects the SoC to boot flash and (in some designs) FPGAs. SPI flash corruption during firmware updates is a common cause of bricked miners — always have an external programmer ready.

3. I2C connects temperature sensors, EEPROMs, and PIC microcontrollers on hashboards. The PIC bridge is a critical intermediary — understanding its command protocol (especially CMD 0x15 for voltage enable) is essential for hashboard diagnostics.

4. Logic analyzers are indispensable. You cannot effectively diagnose serial communication issues without one. Invest in a Saleae or equivalent tool — it will pay for itself on the first board you save.

5. Most communication failures are physical. Broken traces, cold solder joints, damaged pull-up resistors, and corroded connectors account for the vast majority of serial communication issues in mining hardware.

Apply This Knowledge

Now that you understand the three core serial protocols, put this knowledge to work:

• Diagnose a "missing chips" error: Follow the Hashboard Repair Guide to trace UART chain breaks using a logic analyzer
• Read hashboard EEPROM data: Use the I2C tools and address information from this guide to extract board configuration data for analysis
• Set up a serial debug console: Connect a USB-UART adapter to your miner's control board and access the Linux terminal for advanced diagnostics
• Understand signal integrity: Continue to Signal Integrity Basics to learn how trace routing, impedance, and noise affect the protocols covered here
• Learn chip-specific details: See the ASIC chip documentation for protocol specifics:
  • BM1366 — S19 XP series
  • BM1368 — S21 series
  • BM1398 — S19 series
• Explore the control board: Read Control Board Architecture to understand how the SoC orchestrates all three protocols during miner operation