Skip to content

Si5532 clock enters persistent error state (0x89) on uSDR rev.3 PCIe — requires power cycle #113

Description

@Bulzi-Robb

Environment

  • Board: USDR Board rev.3, HWID 802f0300
  • Firmware: e8b2f023 (20250129150035)
  • RFIC: LMS6002D (0022)
  • Host: Raspberry Pi CM5, Debian Bookworm, aarch64
  • Interface: PCIe (M.2 A+E key via M-key adapter)
  • Software: usdr-lib v0.9.9, usdr-dkms, soapysdr-module-usdr (all bookworm0 packages)
  • Kernel module: usdr_pcie_uram v0.1

Problem

The Si5532 clock synthesizer intermittently enters a persistent error state:

[5532] si5532 state: 0x89 (ERROR)
[5532] The device has not detected an input clock source and can not proceed to ACTIVE state
SoapyUSDR::setSampleRate(0, RX, 2.048 MHz) - error -84

Once in this state, setSampleRate() fails on every attempt. The error persists across:

  • SoapySDR device close/reopen cycles
  • Kernel module unload/reload (rmmod usdr_pcie_uram && modprobe usdr_pcie_uram)
  • PCIe device remove/rescan (/sys/bus/pci/.../remove + /sys/bus/pci/rescan)
  • Software reboots

Only a full power cycle (power off, wait, power on) recovers the device.

Behavior Pattern

  1. After a clean power cycle, the device initializes correctly and setSampleRate() succeeds
  2. The Si5532 warning (state: 0x89) appears in init logs even when the device works — it seems the error is present but non-fatal initially
  3. After some number of operations (tuning, streaming, retuning), setSampleRate() begins failing with error -84
  4. The transition from "warning but functional" to "fatal error" is unpredictable — sometimes after 1 minute, sometimes after 10+ minutes

I2C Bus Corruption

When the Si5532 is stuck, I2C device reads return garbage values:

  • LMK5C33216 DEVID changes from 00 00 00 00 to ff 3f 3f 3f
  • LMK05318 DEVID shows unstable values between reads
  • DACx0501 ID unrecognized (varies: 100, 300, 701, 1f07, ff3f)

This suggests the I2C bus itself becomes corrupted, not just the Si5532 register state.

Accelerating Trigger

Tuning to very low frequencies (~98 MHz, FM band) reliably triggers PCIe streaming errors ([PCIE] RES -1 != 512 OOBLEN) which then corrupt the clock state permanently. However, the error also occurs during normal-frequency operations (700-1900 MHz) without any low-frequency tuning.

Thermal Context

Board temperature was 66-77°C during testing (no heatsink/fan). The LMS6002D is rated to 100°C but clock PLLs may be sensitive. Adding cooling is planned.

Questions

  1. Is there a newer FPGA bitstream in the firmwares repo that addresses this? The usdr-fpga and usdr-lib repos have commits from March/April 2026, well after the v0.9.9 release.
  2. Is the Si5532 warning at init (state: 0x89) expected behavior for boards without an external clock reference?
  3. Is there a recommended recovery mechanism short of power cycling (e.g., FPGA soft reset via a register write)?
  4. Could this be related to the M.2 A+E to M-key adapter used on the CM5-IO-BASE-B carrier board?

Reproduction

import SoapySDR
from SoapySDR import SOAPY_SDR_RX
# After device has been used for some time:
sdr = SoapySDR.Device(dict(driver="usdr"))
sdr.setSampleRate(SOAPY_SDR_RX, 0, 2.048e6)  # RuntimeError: error -84

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions