Replaced HF-modified LimeSDR board is also damaged

Hi @ccsh,

Perform automatic board update, please. Then post the result.

Hi @Zack. As you wish, I have repeated update test on a different host machine. Here are the results:

As you can see, it does not work neither on “master” nor “RetructureLimeSuite” branch :confused:

You are right and it should not have an impact if everything has been done properly. But every modification may be risky in case of such complex and packed board. It was just few weeks ago when experienced company has fried our USRP B200 mini during replacing of literally several capacitors :wink: That is why I have asked whether any tests were performed after doing HF mod.

I have thought so too, but ruled it out, since it happens even when I connect that particular replaced board as a first one on a fresh linux installation.

Also I should note that when repeating update procedure many times in a row, sometimes (very rarely) it actually works fine, and I am able to probe the board sucessfully as long as I don’t pull out the USB plug. Now, this is just a blind guess, but it sound a little bit similar to the problem of too short pause after FPGA reset, fixed for LimeSDR mini recently by @IgnasJ in this commit. I am not sure if this fix has been applied only for LimeSDR mini or “big” LimeSDR as well. If the latter is not the case, is there a chance to create a test branch with such fix? I could check whether it helps or not.

That fix is only for LimeSDR-Mini

Okay, but I guess there are also similar pauses during “big” LimeSDR programming procedure, right? I would really use a test branch with them being increased, because this whole problem feels like unrealiable programming (as I wrote, sometimes programming can be completed successfully and then these boards work correctly as long as I don’t pull out USB plug). This is the only idea I’m having before asking for another replacement…

Is there a chance to provide such test branch? (I would do it myself, just don’t know where to look, as these source files named “ConnectionFT601” don’t tell me much :confused: )

I did some further testing today and found very interesting relationship. At first, let’s define “stable” and “unstable” state of the device:

def. “stable state” = state at which device may be probed (with “SoapySDRUtil --probe” command) two times in a row without throwing a single error (make sure that USB plug is not plugged out between these calls).

def. “unstable state” = state at which device is not in a stable state (i.e. it thowed at least one error during procedure mentioned above).

As I wrote before, it looks like if the device is in stable state, it stays here as long as I don’t pull out the USB plug. But if I will pull it out, it may recover and go into stable state again, or may fall into unstable state. I wanted to check if there is some relationship between the time of keeping the device unpowered and chances that it will fall into unstable state. So I did some testing according to following algorithm:

  1. Determine maximum number of runs Nruns_max and time Toff of powering off the device.
  2. Initialize Nunstable and Nruns counters with zeros.
  3. Put the device into “stable state” by updating it with “LimeUtil --update” command in a loop (usually 1-3 iterations are enough).
  4. Unplug the USB plug.
  5. Wait Toff seconds.
  6. Plug in the USB plug.
  7. Increase Nruns.
  8. Run “SoapySDRUtil --probe” command twice and look for errors (i.e. check if device is in a stable or unstable state). If at least one error was found, increase the value of Nunstable counter.
  9. If Nruns==Nruns_max, go to step 10. Otherwise, if errors were found in step 8, go to step 3. If no errors were found in step 8, go to step 4.
  10. Estimate the probability Punstable that the device will fall into unstable state as (Nunstable/Nruns)*100% and end the test.

Here are some results:
Toff=5 seconds: Punstable=(4/20)*100%=20%
Toff=10 seconds: Punstable=(12/20)*100%=60%
Toff=20 seconds: Punstable=(19/20)*100%=95%
Toff=60 seconds: Punstable=(10/10)*100%=100%

So I have found obvious relationship between time of keeping the device unpowered and probability that it will fall into unstable state. @Zack, @IgnasJ, does it ring a bell to you? If not, could you tell me where are initialization-related time constraints (such as length of a pause after FPGA reset) kept in a source code for “big” LimeSDR board? I would be happy to recompile LimeSuite with their different values, so I could check whether it helps at all or not.

P.S. I have tested it with the most recent “RestructureLimeSuite” branch, as it shows more errors than the “master” branch.

Hi @ccsh,

When device is in “unstable state”, do you see LimeSDR-USB board when lsusb?

Yeah, and I have compared the verbose output of lsusb in both stable and unstable state. There is no difference at all, in both cases it is as following:

Bus 004 Device 010: ID 1d50:6108 OpenMoko, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x1d50 OpenMoko, Inc.
  idProduct          0x6108 
  bcdDevice            0.00
  iManufacturer           1 Myriad-RF
  iProduct                2 LimeSDR-USB
  iSerial                 3 0009061C02CA2B20
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           70
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0f  EP 15 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x8f  EP 15 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapaCouldn't open device, some information will be missing
bilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat           0 micro seconds
    bU2DevExitLat           0 micro seconds
Device Status:     0x0000
  (Bus Powered)

Hi @ccsh,

Why you getting this strange string in the middle of verbose output of lsusb?

I just forgot to run lsusb with super user privileges.

I have check it again and confirmed that there are no differences between lsusb output in stable and unstable state:

Bus 004 Device 019: ID 1d50:6108 OpenMoko, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x1d50 OpenMoko, Inc.
  idProduct          0x6108 
  bcdDevice            0.00
  iManufacturer           1 Myriad-RF
  iProduct                2 LimeSDR-USB
  iSerial                 3 0009061C02CA2B20
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           70
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0f  EP 15 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x8f  EP 15 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength           22
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat           0 micro seconds
    bU2DevExitLat           0 micro seconds
Device Status:     0x0000
  (Bus Powered)

I had a break for a while. Today I recompiled everything (fresh linux) and encountered similar behaviour to what you encountered. So I reverted to old sources(from last time I did something) and everything works as it used to! Try this commit:
git checkout 9c365b144dc8fcc277a77843adf7dd4d55ba6406
Maybe there is something in the code.
With now sources I managed to run my application but changing frequency caused crash. Also PAD amplifier is not responding.
@zack were there some major API changes?

Will try that on Tuesday, but as I am struggling with that issue over past few months and other board works perfectly fine both on old and current drivers, I don’t think that’s it. I will report results though.

Okay, so I have tested this commit, which is the closest commit to the one proposed by @modimo, for which I am able to download source files. Surprisingly, the issue with device probing was gone indeed for this version of LimeSuite. However, it doesn’t mean that it worked successfully, since I was unable to transmit or receive anything, and got following warnings when trying to set RF frequency of 1455 MHz:

The same was happening for any other frequency in TX or RX, both in GNURadio UHD-based application and custom SoapySDR-based application.

So, right now I got two “options”: recent LimeSuite version which is unreliable in terms of board programming and throws error even when simply probing the device, or some ancient version which doesn’t throw such errors but also doesn’t allow me to transmit or receive anything. @Zack, do you have any other ideas?

This warning is due to calibration cache. Try removing it and/or disabling.

Actually I have passed “cacheCalibrations=0” in device arguments, but it didn’t help.

So when using old version of LimeSuite to program your board no longer gets into “unstable state”. Is that correct? Programming is done the same way on both versions of LimeSuite only FW/GW version flashed by auto-update are different. Update should install FW and GW that were tested to work with that LimeSuite version, so not being able to receive anything suggest that there may actually be something wrong with the board.

Yes, I no longer got errors during probing the device with that old version of LimeSuite. But maybe it is because these error messages simply weren’t displayed on stderr/stdout in this old version and the actual issue is still there? Hard to say from my point of view.

And it looks like it indeed works like that, I can see different FW and GW numbers being installed for these two versions of LimeSuite.

I believe so. But I probably should be more precise about “not being able to receive/transmit anything”: in GNURadio Companion I am able to run simple graph with UHD Source and FFT/Scope Sink, it’s just that the received spectrum or time course doesn’t show the signals which I know are there (e.g. I am transmitting them via other device such as USRP). So I am actually getting some samples, it’s more like setting the RX/TX frequency doesn’t work like it should in this old LimeSuite version. The same applies for custom SoapySDR-based application, which in normal conditions should transmit and receive some bursts via LimeSDR itself.

Anyway, @andrewback has contacted me in order to send back the faulty board, so I hope things will become clearer when you guys will have the possibility to actually see the problem ;). But for now, thank to all of you for your help!

Since i have similar problem I will post here.
I found something interesting.
https://community.cypress.com/thread/27549?start=30&tstart=0
There is FX3 loopback test attached:
https://community.cypress.com/servlet/JiveServlet/download/122338-26247/FX3USBnoise3.zip
I used this to upload the image to ram. Remove FX3 jumpre reset chip an load image with cyfwprog available here:
http://www.cypress.com/file/138806/download
Run test FX3USBTest.
It seems like communication problem between PC and cypress.
@IgnasJ can you comment on that? Is that the root of all problems?

Hi,
sorry, but I did not understand your problem. Could you explain it in more detail.

If you are speaking about problem experienced by ccsh, then that problem does not look like it is in communication between PC and FX3.

I did run test from cypress forum as transfer errors do occur. In my board i have [ERROR] Read(64 bytes) failed and [ERROR] Write(64 bytes) failed errors when I do LimeUtil --timing. LimeUtil --update however works fine.

EDIT:
also problems are more severe when device is cold. If it is powered for few minutes and gets warm it sometimes works.