LimeSDR Mini 2.0 not detected after LimeUtil --update (LED on, no USB enumeration)

Projects LimeSDR
1

Hello guys, i got an issue with my limeSDR.. here’s the detail :

Device: LimeSDR Mini 2.0

Issue: Device no longer detected after firmware update

Description:
After running LimeUtil --update which completed successfully (100%), I physically disconnected and reconnected the device as instructed. Since then, the device is completely undetectable:

LED is on (VBUS power present)
Does not appear in lsusb on Linux (tested on multiple machines)
Does not appear in Windows Device Manager when plugged/unplugged
Does not appear in LimeSuite GUI → Connection Settings on Windows native (no VM)
Zadig shows no LimeSDR entry even with “List All Devices” enabled
Prior to the firmware update, the device was connecting successfully (Make connection: ‘LimeSDR Mini [USB 2.0] 1DA1542270731D’) but was producing VCO lock errors:

[ERROR] TuneVCO(CGEN) - failed to lock (cmphl!=0)
[ERROR] SetFrequencyCGEN failed
[ERROR] setSampleRate(Rx, 0, 2 MHz) Failed
The firmware update was intended to resolve these errors. The update completed at 100% but the device became undetectable after the subsequent reconnect.

do you guys have any idea what’s going on with my device? is there still a way to recover from this?

Thank you!

2

The FT601 USB bridge does not have firmware, hence the update will have been to the FPGA gateware and/or its soft-core CPU firmware. As such I’m not sure how updating these could result in it no longer enumerating.

Tagging @VytautasB

4

Thank you for the clarification about the FT601. I have additional diagnostic data that may help:

USB packet capture (Wireshark/USBPcap) confirms the FT601 is completely silent, no enumeration packets at all when the device is plugged in. Captured before and after plugging in the LimeSDR, and there is zero difference. The device does not appear on the USB bus whatsoever, even though the LED is on (VBUS present).

Given that the FT601 has no firmware and should enumerate independently of the FPGA, what could cause the FT601 to stop responding entirely?

A few questions:

  1. Is there a JTAG recovery option for LimeSDR Mini 2.0 that bypasses USB?
  2. Could the VCO lock errors (TuneVCO(CGEN) - failed to lock) that were present before the update indicate an underlying hardware failure that eventually caused this?
  3. Is there any power rail or component between VBUS and the FT601 that could fail and prevent enumeration while still allowing the LED to stay on?

Happy to share the pcapng files if helpful.

5

Yes, there is FPGA JTAG and this requires soldering a header.

@Zack would be the best person re the hardware design, but he’s on vacation until next week. You can also find schematics here:

7

Thank you! I’ve reviewed the v2.4 schematics from the GitHub repository and found the JTAG header (J5).

From the schematic (page 8 - FPGA):

  • FPGA: Lattice LFE5U-45F (ECP5)
  • Gateware stored in external SPI flash (W25Q128JVSIQ)
  • J5 JTAG header pinout (0.1" / 2.54mm pitch):
    • Pin 1: VCC3P3
    • Pin 2: TDI
    • Pin 3: TMS
    • Pin 4: TCK
    • Pin 5: TDO
    • Pin 6: GND

I plan to use an FT232H breakout board with OpenOCD to reflash the gateware via JTAG.

A few questions before I proceed:

  1. 1.Where can I find the correct gateware .bit file for LimeSDR Mini 2.0 v2.4?
  2. 2.Is there a recommended OpenOCD config for this board?
  3. 3.Should I erase the flash first, or just overwrite it?

Happy to wait for Zack if needed, just want to make sure I use the correct files to avoid making things worse

8

Hi @bonbonz000,

First check FT601 configuration:

https://github.com/myriadrf/LimeSDR-Mini-v2/blob/main/docs/documentation/faq.rst#how-to-configure-ft601-usb30-chip

here is the link for JTAG connection with FT2232H mini module:

https://github.com/myriadrf/LimeSDR-Mini-v2/blob/main/docs/documentation/jtag-programming.rst#connecting-limesdr-mini-v2-board-to-ft2232h-mini-module

For programming i would suggest to follow flashing instructions:

9

Thank you for the guidance!

First check FT601 configuration:
i am unable to find the device while it’s plugged in, it is not detected by the host (windows)

Question:
Before I do Step 2 JTAG Connection with FT2232H, is my device could be saved at this point using this method?

10

Sorry, I missed that the board does not appear in Device Manager when plugged in. If it does not appear in Device Manager at all, even as an Unknown Device, there may be something wrong with the FT601 IC.

I noticed that you previously wrote:

Prior to the firmware update, the device was connecting successfully (Make connection: ‘LimeSDR Mini [USB 2.0] 1DA1542270731D’) but was producing VCO lock errors.

Are you connecting the LimeSDR Mini v2 board to a USB 3.0 or USB 2.0 port? Are you using any USB extension cables or hubs?

Try a different host PC and connect the board directly to a USB 3.0 port, if you have not already tried that.

If the board still does not appear in Device Manager under any name, try reflashing the FPGA gateware as a last resort.

11

it was connected directly to usb 3.0 when it was working fine, then after this incident i tried using different machine,using usb extention, using usb hubs, no luck at all, same thing indicator on but no sign of connection, check from windows device manager and linux lsusb

is it time to do the last resort using your last guidance, is it enough to carry the operation?

12

Something was wrong already if board was connected directly to USB3.0 port and was detected as USB2.0.

Yes there is no point on trying to configure FT601 if it is not detected. You can try to reflash FPGA gateware.

13

understood, is there alternative that i can use besides FT2232H mini module? excuse my lack of knowledge i’m no familiar with such module

thank you

14

FT2232H mini module is the one that we use with openFPGAloader, it supports other cables also but i have not tried those or checked their compatibility with the board.

15

Anyway still looking for alternative, can i use this module ?

  • MCU FT232H high-Speed Multi-Functional USB to JTAG UART FIFO SPI I2C Module Type-C IIC Connection

image
image700×700 50.7 KB

16

Hi again!

I have been attempting JTAG recovery using an FT232H connected to the J5 header. IDCODE reads correctly (0x41112043, LFE5U-45), so the JTAG connection is good. The status register always returns 0xFFFFFFFE (BUSY=1, FAIL=1) indicating the ECP5 is stuck in a failed-boot error state.

The problem is that ISC_ENABLE (0xC6) is always rejected. I have tried:

  • -Standard LSC_REFRESH + ISC_ENABLE flow (ecpprog and openFPGALoader both hang at “Enable configuration:”)
    -A batched single-USB-write approach where REFRESH and ISC_ENABLE are sent together with FT232H-internal clock delays (MC_CLK_N8) from 2ms to 10ms to try to catch the ECP5 POR window after REFRESH

None of these work. The status register never changes regardless of what is sent.

Reading the FEABITS register returns 0xFFFE, which maps to PWD_EN=1 and PWD_ALL=1. My questions:

  1. -Is the FEABITS reading trustworthy when the ECP5 is in this failed-boot error state, or is 0xFFFE likely a garbage reading caused by the error state?

  2. -have you ever successfully recovered an ECP5 from erased flash where ISC_ENABLE is permanently rejected via JTAG? Is there a known working procedure?

  3. -Is direct SPI flash programming via SOIC-8 clip (with the board powered off) the correct path forward at this point?

The target gateware file I have is lms7_trx_impl1_dualboot.mcs.

Thank you very much!
looking forward for your answer

17

Hi @bonbonz000 ,

At this point I would recommend stopping the experiments with JTAG sequences and direct SPI flash programming.

For troubleshooting it is important that we first reproduce the recovery using a known configuration.

I am not familiar with FT232 so I cannot comment on its compatibility or wiring. If you can detect FPGA and read ID code probably FT232 will work also.

  • Here is the wiring diagram for FT2232H Mini Module for reference:

  • image
    image739×599 92.7 KB

  • Use the latest LimeSDR_GW gateware release bitstream files:
    Download LimeSDR_GW_v3.11_bitstream.zip, required files are stored in /LimeSDR_GW/bitstream/LimeSDR_Mini_V2/ folder)

  • Use openFPGAloader commands to program user and gold images:

  • If you will be using ft232 instead of ft2232 mini module use --cable ft232 argument

  • openFPGALoader --cable ft2232 --write-flash --bitstream ./limesdr_mini_v2.bit

  • openFPGALoader --cable ft2232 --write-flash --bitstream ./limesdr_mini_v2_golden.bit --offset 1310720

If you get any errors, post results and will see from there.

Regards,
Vytautas

18

Hi @VytautasB

Update on progress:

Hardware note: FT232H has D1–D2 bridged on PCB (hardware short), so openFPGALoader and ecpprog -X don’t work - TDO always mirrors TDI. SRAM load (ecpprog -S) works fine.

Flash programming - fixed: LimeUtil --force --fpga=limesdr_mini_v2.bit worked via USB. Board now boots green LED from flash after power cycle (GW=3.11, HW=7, USB 3.0).

Still failing -CGEN VCO:

TuneVCO(CGEN) - failed to lock (cmphl!=0)
VCTCXO test: 0 (min); 0 (max) — FAILED

Root cause: LMS_GetClockFreq(dev, 0) returns 10.000 MHz as reference clock. LimeSDR Mini V2 VCTCXO should be 40 MHz - the 4× mismatch makes PLL dividers wrong > VCO out of lock range at all CSW values.

Questions:

  1. - Is ref clock 10 MHz (instead of 40 MHz) a known issue with v3.11 on HW=7?
  2. - Is there a correct gateware build for HW_2.4 / HW=7?
  3. - How to flash golden image to offset 0x140000 without openFPGALoader?

LimeSDR Mini v2.4 | HW=7 | GW=3.11 | LimeSuite v23.11 | Linux USB 3.0

19

Hi @bonbonz000,

From the recovery sequence, it looks like the FPGA image was corrupted or invalid, causing the FPGA to keep the FT601 in reset. That would explain why the board was not detected by USB at all.

Programming a valid image into FPGA SRAM with ecpprog -S restored USB enumeration, which then allowed the FPGA to be flashed normally through LimeUtil. If FPGA gateware is loaded after power cycle then we can say that recovery was successful at this point.

- Is ref clock 10 MHz (instead of 40 MHz) a known issue with v3.11 on HW=7?

No, I don’t see such issue at my side with GW 3.11 on LimeSDR-Mini v2.4 (HW=7). Can you run LimeQuickTest and post results here? Also run LimeSuiteGUI connect board (Options → Connection Settings → Select board → Connect) and post a screenshot of main window, specially bottom part where board info is reported)

- Is there a correct gateware build for HW_2.4 / HW=7?

Gateware which i provided in my previous post is the correct one, you already programmed it.

- How to flash golden image to offset 0x140000 without openFPGALoader?

With ECP5, the external SPI flash is not directly part of the JTAG chain, so the FPGA first has to be put into a mode which allows SPI flash access through JTAG. This is similar in principle to the indirect SPI programming procedure used by Lattice Diamond.

openFPGALoader handles this ECP5 SPI-access sequence automatically: it prepares the FPGA for indirect SPI access, programs the external flash through the FPGA, and supports writing to a specified flash offset.

There are probably several ways to program the SPI flash, including other indirect-access methods. However, openFPGALoader is the method we have tested and currently support for programming both the user and golden images, so this is the procedure I would recommend following.

Regards,

Vytautas

20

Hi @VytautasB

Thanks for the explanation. Recovery confirmed, board boots from flash (GW=3.11, USB 3.0) after power cycle.

Here is the LimeQuickTest output:

[ TESTING STARTED ]
->LimeSuite version: 23.11.0+dfsg-4
->Device: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1DA1542270731D, HW=7, GW=3.11
Chip temperature: 45 C

[ Clock Network Test ]
->REF clock test
Test results: 57120; 57691; 58258 - PASSED
->VCTCXO test
Results : 0 (min); 0 (max) - FAILED

[ FPGA EEPROM Test ]
FPGA EEPROM not supported in v2 - PASSED

[ LMS7002M Test ]
->Registers test - PASSED
->External Reset line test - PASSED

[ RF Loopback Test ]
TuneVCO(CGEN) - failed to lock (cmphl!=0)
SetFrequencyCGEN(61.44 MHz) failed
SetFrequencyCGEN(122.88 MHz) failed
Failed to set sample rate
->RF Loopback Test FAILED

=> Board tests FAILED <=

LimeSuiteGUI screenshot attached below.

image
image1325×850 78.4 KB

One thing we noticed during testing: when reading register 0x8C (VCO comparator status) after writing different CSW values to 0x86, bit 13 of the 0x8C readback appears to track bit 2 of the CSW field from the previous write. Not sure if this is expected, just sharing in case it is helpful.

Regards

21

Hi @bonbonz000,

It looks like the board is now back to essentially the same state as before the unsuccessful gateware update: USB is working again, but the original CGEN/reference clock issue remains.

Before update:

Prior to the firmware update, the device was connecting successfully (Make connection: ‘LimeSDR Mini [USB 2.0] 1DA1542270731D’) but was producing VCO lock errors:

[ERROR] TuneVCO(CGEN) - failed to lock (cmphl!=0)
[ERROR] SetFrequencyCGEN failed
[ERROR] setSampleRate(Rx, 0, 2 MHz) Failed

After GW recovery:

[ RF Loopback Test ]
TuneVCO(CGEN) - failed to lock (cmphl!=0)
SetFrequencyCGEN(61.44 MHz) failed
SetFrequencyCGEN(122.88 MHz) failed
Failed to set sample rate

This does not look like a gateware issue, since I tested the same GW 3.11 build on the same HW=7 revision on my side and do not see this behavior.

Please provide more details about the board history before the update: when the CGEN issue first appeared, whether the board was working normally before that and whether any hardware modifications, external clock experiments or other low-level work had been done.

Regards,

Vytautas

22

Hi @VytautasB

Thanks for checking your side, that’s really helpful context.

To answer your questions: the board never worked from the very first time I used it. The CGEN lock failure was there immediately on first connection, no prior normal operation to compare against. There were no hardware modifications made (no soldering, no external clock injection, nothing). The only thing done to the board physically was attaching JTAG wires to the J5 header for the recovery process after the failed update.

Timeline:

  • - First power-on: USB 2.0 connected, but immediately TuneVCO(CGEN) failed to lock (cmphl!=0) and SetSampleRate failed
  • - Ran LimeUtil --update trying to fix it >>>> board went completely undetectable
  • - Recovered via ecpprog SRAM load of GW 3.11 >>>> USB 3.0 now, but same CGEN error persists

While investigating, I did some low-level SPI register analysis and noticed that reading 0x8C (VCO comparator) after LMS_Init always returns bit13=0 regardless of CSW. I found the value of bit13 correlates with the last write to 0x86: specifically 0x8C_bit13 = (0x86_bit10) AND (0x86_bit0). After LMS_Init, 0x86=0x4101 (bit10=0), so cmphl=0 always. Forcing bit10=1 makes TuneCGENVCO select CSW=127 and “succeed”, but downstream LML PLL then fails, so the VCO isn’t actually locking.

Also noted: LimeQuickTest VCTCXO test always returns 0(min);0(max) on both GW 3.11 and the golden GW 0.31.

Given that the board was never operational, and your GW 3.11 works fine on your HW=7, is there any chance this could be a factory defect? Or is there a specific hardware check (VCTCXO power, component check) I could do to narrow it down?