Frequent errors while initializing any app with particular LimeSDR board

ccsh · 1 October 2017 20:15

Hi all,

I got two LimeSDR boards. One is working quite well, but I frequently struggle with strange initialization-related problems on the other one. Sometimes it works like a charm and nothing wrong is happening, other time I got USB-related errors like “No transfer from device”, but most frequently I got errors like “ResetChip() failed” or some sampling rate- or bandwith-related errors. It does not really matter what application I am trying to use, it happens e.g. when trying to run GNU Radio flowgraph or run custom C++ application based on SoapySDR etc. At the same time I don’t have any of those problems with the first board, so it is clearly hardware-related issue, not a software thing nor USB power supply or host machine issue. I hope you will be able to provide some hints what is happening.

Below I have posted example errors (lines which begins with timestamp are coming from my app, while other are coming from SoapySDR or underlying LMS7 driver):

Problem with setBandwidth() function right at the beginning, even before I try to set anything on my own:

2017-10-01 19:55:16.838314 INFO -     sdr: Creating the SDR device with: args=type=soapy,driver=lime,soapy=0,cacheCalibrations=0
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.002.HEAD-0-gbd6e21dc

[INFO] Make connection: 'LimeSDR-USB [USB 3.0] 9062000C4220F'
[INFO] Reference clock 30.720 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 30.72 MHz
[INFO] Init LMS7002M(0)
[INFO] Ver=7, Rev=1, Mask=1
[INFO] LMS7002M calibration values caching Disable
[ERROR] 
[WARNING] SoapyLMS7::setSampleRate(): not a power of two factor: TSP Rate = 15.36 MHZ, Requested rate = 10 MHz
[ERROR] 
[ERROR] 
[ERROR] setBandwidth(Rx, 0, 30 MHz) Failed - 

2017-10-01 19:55:17.561692 ERROR -    sdr: Following exception occurred during initialization of the SDR device:

After that, it does not detect gateware etc. and it constantly gives me ResetChip() error message and the only way to avoid that is to unplug and plug USB cable again. Then it may work fine or go into any of 1. 2. or 3. states.

2017-10-01 19:56:15.950352 INFO -     sdr: Creating the SDR device with: args=type=soapy,driver=lime,soapy=0,cacheCalibrations=0
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.002.HEAD-0-gbd6e21dc

[INFO] Make connection: 'LimeSDR-USB [USB 3.0] 9062000C4220F'
[WARNING] Gateware version mismatch!
  Expected gateware version 2, revision 9
  But found version 0, revision 0
  Follow the FW and FPGA upgrade instructions:
  http://wiki.myriadrf.org/Lime_Suite#Flashing_images
  Or run update on the command line: LimeUtil --update

[INFO] Device name: LimeSDR-USB
[INFO] Reference: 30.72 MHz
[INFO] Init LMS7002M(0)
[INFO] Ver=0, Rev=0, Mask=0

2017-10-01 19:56:15.988909 ERROR -    sdr: Following exception occurred during initialization of the SDR device: ResetChip() failed

Sometimes I also observe problems with setting sampling rate which I have requested - device is actually using much smaller values. Moreover TX/RX PLL can’t lock. After killing the app device goes into state 2.:

2017-10-01 19:58:27.436163 INFO -     sdr: Trying to set the following TX sample rate on channel 0: 16.666667 [MHz]
[ERROR] 
2017-10-01 19:58:27.747197 INFO -     sdr: Actual TX sample rate on channel 0: 7.680000 [MHz]

2017-10-01 19:59:24.975906 INFO -     sdr: Trying to set the following RX sample rate on channel 0: 16.666667 [MHz]
[ERROR]
2017-10-01 19:59:28.352797 INFO -     sdr: Actual RX sample rate on channel 0: 1.920000 [MHz]

Have u got some ideas what the heck is happening here or what may be causing that kind of problems?

Zack · 2 October 2017 05:41

This suggests that FPGA gateware is not programmed after power on.
Could you try another PC, please.

ccsh · 2 October 2017 06:28

Thank you for a quick answer, but like I said, another LimeSDR board works perfectly fine with the very same PC, so I really don’t think it is a matter of a host machine. I would rather suppose that some jumper on this particular board is damaged or something like that, just not sure where to look exactly.

But just to make sure I have tested this problematic board with another PC as you have proposed, and got the same behavior. It looks like FPGA gateware is not programmed as a result of previous problems (like these bandwidth- or sampling rate-related issues), rather than being their root cause.

Zack · 2 October 2017 06:43

Just to be sure.

FPGA being not programmed is the route of all the issues.

Contact Crowd supply for replacement, please. Add please all the information provided by you in this thread to the box too.

ccsh · 2 October 2017 10:54

I see. To be honest I hoped that it wouldn’t come to this, especially because I hate connecting all 12x SMA->U.FL pigtails inside Luftek’s enclosure, this is really challenging for me because of the size But I guess you are right and replacement is the only reasonable way to go.

One more question though - both of my boards were HF modified by Lime, and I know that it was done only for some boards and now it is not possible to order new board with such modification. So may I hope for it to be done also in this special case of board replacement due some malfunction?