LimeSDR Mini v2: CGEN lock failure caused by dead PCB power rail (software workaround)

Hi everyone,

I recently had a LimeSDR Mini v2 (serial `1DA179B92E03DE`) become completely unusable. Every attempt to use it resulted in the following error:

> `TuneVCO(CGEN) - failed to lock (cmphl!=0)`

This prevented setting any sample rate and made both RX and TX non-functional. The issue occurred consistently on both virtual machines and bare metal.

### What I tried

  • Multiple USB cables and ports (including powered hubs)
  • Gateware update (already on 2.2)
  • Rebuilding LimeSuite from the latest master branch
  • Running on a clean bare-metal Ubuntu installation

None of these resolved the problem.

### Investigation
After doing some low-level register debugging, I discovered that:

- The RX synthesizer (**SXR**) was working normally and could lock.

  • Both **CGEN** and the TX synthesizer (**SXT**) showed completely flat lock comparators across all VCO capacitor codes and bias settings.
  • The 40 MHz reference clock was confirmed to be reaching the chip correctly.

This strongly suggested that the external power rail on the PCB feeding the CGEN and SXT VCO/charge-pump domains had failed, while the rail used by SXR was still working.

### Workaround
The LMS7002M chip contains internal LDO regulators that can power these domains. On Mini v2 boards, these internal LDOs are disabled by default. Enabling them with the following two register writes restored functionality:

{0x0092, 0xFFFF},
{0x0093, 0x03FF},

If anyone is having the same CGEN lock issue on a LimeSDR Mini v2 and wants the full technical write-up + diagnostic scripts, just message me and I’ll send them over.

Important: This is not a permanent fix.

It’s a software workaround that bypasses the dead power rail. I don’t know yet how reliable it will be long-term (especially during long transmissions). I’ll be testing it properly in the coming days. Also, if I move the board to

I’ve already contacted Lime Microsystems about this and I’m waiting for their reply. I don’t know yet if they consider this an acceptable workaround or if they have a better solution / will accept it as supported solution.