LimeSDR USB - LEDs are not blinking, no communication and update fails

Projects LimeSDR
1

Everything was going well where I installed the driver, opened Lime Suite GUI, read the clk, temperature and updated the driver using LimeUtil --update in a cmd. I was using a usb 2 port. Unfortunately, I was exploring the menus in the GUI where I hit program button in automatic mode (Module > programming) by mistake. I quickly canceled it and went back to the cmd to update the board using LimeUtil --update where it went fine.

Suddenly after that, the LEDs stopped blinking where two are yellow and the other two are red and the fan is on all the time. I guess that means no communication over the USB?. The device name in the device manager suddenly changed from Myriad-RF LimeSDR-USB to Cypress FX3 USB Bootloader Device. I tried to unplug and plug the USB port several times but nothing changed. I tried to connect and read the clk in the GUI but I found the board was detected as Westbridge [USB2.0] 4BE and the clk freq is 0.0 Hz. I tried to do the update again in the cmd and it failed giving the following message in the cmd:
Connected to [WestBridge [USB 2.0] 4BE]
TransferPacket: Write failed (ret=0)
TransferPacket: Write failed (ret=0)
TransferPacket: Write failed (ret=0)
Update not supported: UNKNOWN[HW=0]

Programming update failed!

I read several thread talking about similar issues and here is what I tried:
1)Tried to reset the USB on the board: removed the jumper, connect the USB port, returned the jumper back ==> no blinking, nothing changed
2)Tried to increase the power supply: used a variable supply for different level 8.4V, 9V and 12V ==> no change
3)Tried a USB 3 port on another laptop: no difference, I even don’t know why the LimeUtil commands were not recognized in the cmd of the other laptop

I don’t know what happened, why it happened and how to solve it and avoid it in the future. Any help is much appreciated.

Best Regards,
Ash

2

This does not update the driver — it updates the firmware/gateware on the device.

This should do the same as the LimeUtil --update command.

I’m not sure it’s a good idea to try and cancel mid-update.

LimeSuiteGUI is really meant for design engineers and I’d avoid using this unless you have good reason to. May even be that just clicking around in it and twiddling settings could even cause permanent (physical) damage, since there are all sorts of obscure settings on the RFIC that can be prodded.

In any case, sounds like you’ve managed to zap the FX3 firmware. Would suggest stopping experimenting with random power supply voltages and instead plugging the board into a known good USB 3.0 port. Then use the Cypress software to program the FX3 controller. For details, see:

https://wiki.myriadrf.org/LimeSDR-USB_User_Guide#Flashing_the_USB_3.0_microcontroller

You can download an FX3 firmware image from:

E.g. assuming it’s a LimeSDR USB v1.4 board, the file will be called LimeSDR-USB_HW_1.4_r4.0.img.

Then once the FX3 is programmed and the jumpers set as normal, you should be able to use LimeUtil --update again to make sure the FPGA is up-to-date.

This all assumes you have Lime Suite v20.01 installed and if not already, make sure you do.

3

Hi andrewback,

Thanks for your reply, it was really helpful. I applied all the previous successfully and tried to do the board test by by typing “LimeQuickTest” in a cmd. Unfortuantely, the RF loopback test failed as shown below. Could you please help me understand what does this test mean and how how to fix this issue?.

Microsoft Windows [Version 10.0.18362.720]
© 2019 Microsoft Corporation. All rights reserved.

C:\Users\ashrafm>LimeUtil
Usage LimeUtil [options]
Options summary:
–help Print this help message
–info Print module information
–find[=“module=foo,serial=bar”] Discover available devices
–make[=“module=foo,serial=bar”] Create a device instance
–force Force operaton

Advanced options:
–args[=“module=foo,serial=bar”] Arguments for the options below
–update Automatic firmware sync + flash
–fpga=“filename” Program FPGA gateware to flash
–fw=“filename” Program FX3 firmware to flash
–timing Time interfaces and operations

Calibrations sweep:
–cal[=“module=foo,serial=bar”] Calibrate device, optional device args…
–start[=freqStart] Frequency start for the sweep(Hz)
–stop[=freqStop] Frequency stop for the sweep(Hz)
–step[=freqStep, default=1MHz] Frequency step for the sweep(Hz)
–bw[=bandwidth, default=30MHz] Desired calibration bandwidth(Hz)
–dir[=direction, default=BOTH] Calibration direction, RX, TX, BOTH
–chans[=channels, default=ALL] Calibration channels, 0, 1, ALL

C:\Users\ashrafm>LimeUtil -find

  • [WestBridge , media=USB 2.0, module=FX3, serial=0000000004BE, index=0]

C:\Users\ashrafm>LimeUtil -find

  • [WestBridge , media=USB 2.0, module=FX3, serial=0000000004BE, index=0]

C:\Users\ashrafm>LimeUtil --find

  • [WestBridge , media=USB 2.0, module=FX3, serial=0000000004BE, index=0]

C:\Users\ashrafm>LimeUtil --update
Connected to [WestBridge [USB 2.0] 4BE]
TransferPacket: Write failed (ret=0)
TransferPacket: Write failed (ret=0)
TransferPacket: Write failed (ret=0)
Update not supported: UNKNOWN[HW=0]

Programming update failed!

C:\Users\ashrafm>LimeUtil --upgrade
LimeUtil: unknown option – upgrade
Usage LimeUtil [options]
Options summary:
–help Print this help message
–info Print module information
–find[=“module=foo,serial=bar”] Discover available devices
–make[=“module=foo,serial=bar”] Create a device instance
–force Force operaton

Advanced options:
–args[=“module=foo,serial=bar”] Arguments for the options below
–update Automatic firmware sync + flash
–fpga=“filename” Program FPGA gateware to flash
–fw=“filename” Program FX3 firmware to flash
–timing Time interfaces and operations

Calibrations sweep:
–cal[=“module=foo,serial=bar”] Calibrate device, optional device args…
–start[=freqStart] Frequency start for the sweep(Hz)
–stop[=freqStop] Frequency stop for the sweep(Hz)
–step[=freqStep, default=1MHz] Frequency step for the sweep(Hz)
–bw[=bandwidth, default=30MHz] Desired calibration bandwidth(Hz)
–dir[=direction, default=BOTH] Calibration direction, RX, TX, BOTH
–chans[=channels, default=ALL] Calibration channels, 0, 1, ALL

C:\Users\ashrafm>LimeQuickTest
[ TESTING STARTED ]
->Start time: Mon Mar 30 18:48:11 2020

->Device: LimeSDR-USB, media=USB 2.0, module=FX3, serial=0009081C05C42738, index=0
Warning: USB3 not available
Serial Number: 0009081C05C42738

[ Clock Network Test ]
->FX3 GPIF clock test
Test results: 17467; 21223; 24979 - PASSED
->Si5351C test
CLK0: 17554 / 17554 - PASSED
CLK1: 17554 / 17554 - PASSED
CLK2: 17554 / 17554 - PASSED
CLK3: 17554 / 17554 - PASSED
CLK4: 17554 / 17554 - PASSED
CLK5: 17554 / 17554 - PASSED
CLK6: 17554 / 17554 - PASSED
->ADF4002 Test
Result: 10 - PASSED
->VCTCXO test
Results : 5112932 (min); 5113065 (max) - PASSED
->Clock Network Test PASSED

[ FPGA EEPROM Test ]
->Read EEPROM
->Read data: 13 02 19 13 02 19 02
->FPGA EEPROM Test PASSED

[ LMS7002M Test ]
->Perform Registers Test
->External Reset line test
Reg 0x20: Write value 0xFFFD, Read value 0xFFFD
Reg 0x20: value after reset 0x0FFFF
->LMS7002M Test PASSED

[ RF Loopback Test ]
Note: The test should be run without anything connected to RF ports
->Configure LMS
->Run Tests (TX_2-> LNA_L):
CH0 (SXR=800.0MHz, SXT=805.0MHz): Result:(-14.4 dBFS, 5.00 MHz) - PASSED
CH1 (SXR=800.0MHz, SXT=805.0MHz): Result:(-16.1 dBFS, 5.00 MHz) - PASSED
->Run Tests (TX_1 -> LNA_W):
CH0 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-18.6 dBFS, 5.00 MHz) - PASSED
CH1 (SXR=1800.0MHz, SXT=1805.0MHz): Result:(-21.6 dBFS, 5.00 MHz) - FAILED
->Run Tests (TX_2-> LNA_H):
CH0 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-16.9 dBFS, 5.00 MHz) - PASSED
CH1 (SXR=2500.0MHz, SXT=2505.0MHz): Result:(-15.6 dBFS, 5.00 MHz) - PASSED
->RF Loopback Test FAILED

=> Board tests FAILED <=

Elapsed time: 5.80 seconds

20200330_185615
20200330_1856153024×4032 3.56 MB

4

Why are you using a USB 2.0 port? LimeSDR USB needs a USB 3.0 ports and 2.0 is unlikely to provide sufficient power.

That looks like it’s not too far out of spec and, once again, it’s on USB 2.0, so may not have sufficient power.

Note also that LimeQuickTest should only be run when the board is cold and if it’s warmed up, performance will be slightly lower and tests may fail, given pass/fail params assume it’s cold.