Repeating Gateware version mismatch problem

This happens more now.

  • Is this due to some change in the MCU code?
  • What’s the correct API call for apps to "reset’ the chip? (Maybe the apps are doing the wrong kind of reset.)
  • An issue with newer code in LimeSuite?

Paging @zack.

I am experiencing the same issue - repeated gateware mismatch despite re-flashing firmware. Not doing anything intensive with the board either, just playing around with gnuradio using gr-osmosdr. Has there been any progress on this?

Hi, i am also having some trouble with the gateware version mismatch. Actually it happens every second time i try to connect to the LimeSDR. This happens using the SoapySDR python bindings, LimeSuiteGUI and GRC. So after getting that failure i simply reconnect to the Lime and everything works fine but still this is kind of annoying to prototype that way :frowning:.

Im using Arch Linux and limesuite-git + soapysdr-git from AUR, so everything should be up to date. Here is an example output:

py sdr_test.py
{addr=1d50:6108, driver=lime, label=LimeSDR-USB [USB 3.0] 9060B00471221, media=USB 3.0, module=STREAM, name=LimeSDR-USB, serial=0009060B00471221}
[INFO] Make connection: ‘LimeSDR-USB [USB 3.0] 9060B00471221’
[WARNING] Gateware version mismatch!
Expected gateware version 2, revision 8
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] Estimated reference clock 0.0000 MHz
[INFO] Selected reference clock 30.720 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 30.72 MHz
[INFO] Init LMS7002M(0)
[INFO] LMS7002M cache /home/jannik/.limesuite/LMS7002M_cache_values.db
[INFO] Ver=7, Rev=1, Mask=1
[INFO] LMS7002M calibration values caching Enable
Traceback (most recent call last):
File “sdr_test.py”, line 15, in
sdr = SoapySDR.Device(args)
File “/usr/lib/python3.6/site-packages/SoapySDR.py”, line 1712, in new
return cls.make(*args, **kwargs)
RuntimeError: SoapyLMS7::setSampleRate() – rate too high
libusb: warning [libusb_exit] application left some devices open

Thank you!

The issue is that we can not re-create this behavior.

Message “But found version 0, revision 0” says that there is no FPGA gateware uploaded or FPGA doesn’t boot properly at the power on.

As I can see from the message log provided by JTAG, the board is connected to the USB3 port, which should be fine. But is it connected directly to the PC? What about other experiencing this issue? It may happen if there is not enough of the power which may be the case if boar is connected to USB2 or via USB hub.

Give as much information as possible, please. Not only message logs, but information about your setup too - OS, how the board is connected etc.

Hey @Zack, isn’t the inability to reproduce almost expected nowadays? You didn’t really think this was foolproof, right? :grinning: I am a human fuzzer (or fool). :wink:

Some specifics:

  • USB3 (which I don’t have problems with using USB-powered HDD)
  • Linux 4.11.3
  • LimeSuite from github (as recommended by you (and thanks))
  • libusb 1.0.21

The application software doesn’t seem to be an issue (I consider LimeSuite as a config tool and not an app)
I have used Gqrx, gnuradio, URH, SDRAngel, CubicSDR and others.

I have not used my LimeSDR in some time now but will be happy to try things out if you have any ideas. But since you tried to repro I am not sure what could be tried.

In the other post * there is mention of missing firm/gate/ware in ~/.local/share/LimeSuite/images

Could that be a source of problems here?

@JTAG mentions that it happens every 2nd time. I can’t recall if that’s true for me but it might be. Could that provide a clue? Perhaps some arbitration issue?
i.e. an app shuts down but doesn’t release the device properly, the next app comes along and wants device control but can’t get it, so it does some kind of reset and that reset does the wrong thing or the board does the wrong thing because of unclean device release?

Maybe this is a libusb problem and not a USB hardware problem?

*

Nonexistent firmware

Hi

I’m facing the exact same behaviour. @JTAG were you able to resolve the problem in the mean time?

My Setup is the following:
Linux 4.10.0-37 (Linux Mint 18.2)
USB3 (Connected directly to the motherboard trough one cable or trough the included split-cable)
Libusb 1.0-0
Limesuite built from source over pybombs
Gateware V2 Rev11

I would like to work on this issue, but I need a starting point.
What Information could help?
How may I trace the problem? (Test scripts etc.)

Thanks!

Hi,

@dme unfortunatly i were not able to resolve this problem so far. Since everything is working fine on my windows machine, it is probably somthing linux related.

Hi,

I’m currently using my LimeSDR-USB on a Raspberry Pi 3, using an external power supply (9V, and current is around 500mA when doing nothing), and I’m having this kind of problem quite often.
It is most of the time solved by LimeUtil --update, but it takes several minutes and I’m concerned it is hiding a more severe issue (hopefully not a power-related one !). At least once, I had to unplug and power-cycle the device for it to fully recover (not clear how it went stuck that time).

I remember the device was completely unusable when running off only one USB2 port, and exhibiting the *ware loss much more often. Anyway the Raspberry Pi is only powered through a 1A, so supplying power through USB was hopeless from the very beginning. This is the reason I soldered wire to the Vcc Ext and Gnd pads next to the supply jack (when plugged directly to the Raspberry Pi 3 the jack isn’t accessible any more).

libusb found on the host is:

lrwxrwxrwx 1 root root 19 Oct 26 2016 libusb-1.0.so.0 -> libusb-1.0.so.0.1.0
-rw-r–r-- 1 root root 83888 Oct 26 2016 libusb-1.0.so.0.1.0

LimeSuite --info provides the following answer:
Version information:
Library version: v17.10.0-g5326611d
Build timestamp: 2017-10-20
Interface version: v2017.10.0
Binary interface: 17.10-1

LimeSuite --find also find the device, not matter what *ware is in there (of course, else --update wouldn’t solve anything):

  • [LimeSDR-USB, media=USB 2.0, module=STREAM, addr=1d50:6108, serial=0009060B00491F29]

After LimeUtil --update, here is the answer of LimeUtil --make:
Make device
Reference clock 30.720 MHz
Device name: LimeSDR-USB
Expansion name: UNSUPPORTED
Firmware version: 3
Hardware version: 4
Protocol version: 1
Gateware version: 2
Gateware revision: 11
Gateware target: LimeSDR-USB
Serial number: 0x9060b00491f29
Free connection… OK

Let me know if you need more info / testing, I have access to the device most of the time and can experiment a lot, except maybe power-cycle and unplug operation.

Thanks.

This happens to me very often. Only pressing hardware reset button helps.
This happens especially often when:

  1. hard-stopping running processes.
  2. multiple apps are accessing the registers, for example starting GNURadio graph while reading registers with LimeSuite.
1 Like

I am having similar problem as you. Sometimes the device shows gateware version mismatch. I am using LimeSDR together with jetson tx2 mostly, but when I plugged it on my desktop ubuntu PC, it is similar. So I doubt that it was just a power supply problem. Maybe the newer version of the driver has also caused problem?

Another problem is that sometimes the device shows setSampleRate() not a power of two factor, but I am using a samp rate of 10MHz which should be quite common.

Hi,

I’m noticed something lately: since I plugged the LimeSDR-USB through the provided cable (the Y cable), while still powering through the same external power supply (9V), I didn’t get the error. This might still just be a fluke (it’s only be a week since I started using the provided cable). Before that, the LimeSDR-USB (mine is equipped with the USB Type-A connector) was plugged directly in one of the 4 USB port of the Raspberry Pi 3 (the one farthest from the Ethernet port, else it doesn’t fit). This sounds to me like an impedance-matching / noise issue, when not using the provided Y cable, preventing the USB from working properly and triggering strange behavior.
Don’t take it for granted, but using the Y cable seems to have improved the behavior for me when running with the Raspberry Pi 3 ; I have plugged the 2 ports in the Raspberry Pi, even if only the connector with D+/D- is useful, just to be on par with the way it would be used without external power supply.

This is good to know. Cables, like the humble power supply, can be extremely variable in terms of quality and performance. I’ve seen poor quality cables and PSUs cause problems with many different platforms and this is not something specific to the LimeSDR.

Well, well, well … Turns out it what a fluke … I just got the issue again … The device had been streaming data for several days when I realized it wasn’t seeing anything any more. I tried to restart the RX and got the well-known error.

pi@raspberrypi3:~ $ LimeUtil --find

  • [LimeSDR-USB, media=USB 2.0, module=STREAM, addr=1d50:6108, serial=0009060B00491F29]

pi@raspberrypi3:~ $ LimeUtil --make
Make device
Gateware version mismatch!
Expected gateware version 2, revision 11
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

Device name: LimeSDR-USB
Expansion name: UNSUPPORTED
Firmware version: 3
Hardware version: 4
Protocol version: 1
Gateware version: 0
Gateware revision: 0
Gateware target: UNKNOWN
Serial number: 0x9060b00491f29
Free connection… OK

Interesting thing though, it recovered by simpling pressing the reset button:

pi@raspberrypi3:~ $ LimeUtil --make
Make device
Reference clock 30.720 MHz
Device name: LimeSDR-USB
Expansion name: UNSUPPORTED
Firmware version: 3
Hardware version: 4
Protocol version: 1
Gateware version: 2
Gateware revision: 11
Gateware target: LimeSDR-USB
Serial number: 0x9060b00491f29
Free connection… OK

Hi there,

I was able to narrow the gateware-problem which in my case gives me a gateware mismatch every 2nd initialisation of libLimesuite. For example if I want to run the Limesuite example-program “singleRX”

I extracted the core USB-calls out of Limesuite which are called to get the gateware-version.
The following two LMS-Commands are sent to the USB-Driver (of course with the corresponding read-backs):
CMD_USB_FIFO_RST (libusb_control_transfer)
CMD_BRDSPI_RD (libusb_bulk_transfer)

I wrote a simple C++ program which calls those commands, surrounded with a proper initialisation and closing of the USB-port.

With the CMD_USB_FIFO_RST-Command, every 2nd run of the program, the call to CMD_BDRSPI_RD ends in a timeout (independent of the timeout value)

NOW, if I omit the CMD_USB_FIFO_RST-Command, everything works as expected and the gateware can be read on every program run.

BTW: All the Python examples from pyLMS7002M are working fine and they do no include a CMD_USB_FIFO_RST-Command

Any ideas what the CMD_USB_FIFO_RST-command does exactly and why it is called in Limesuite, but not in pyLMS7002M?

CMD_USB_FIFO_RST suppose to clear any residual samples data in USB microcontroller’s FIFOs before starting to stream new samples.

Checking further I noticed some strange behavior (current from the power supply, status leds, this didn’t make sense depending on what was actually plugged) and found out that I had some faulty cabling along the way … So I rebuild a proper jack power cable (now that I have space to actually plug the power jack), and it’s been a week without any error. So a proper power supply might, indeed, make everything perfectly stable as far as gateware is concerned. Lets not draw any conclusion yet, and wait for a few more weeks before stating the issue is solved on my side.

Just to make sure - do you have a possibility to check if the problem persists when using “Y” split cable plugged into USB 3.0 port (main plug) and USB 2.0/3.0 port (additional power plug)?

Yeah, this still happens to me. It’s really annoying and it’s something that is not supposed to happen. So far I’ve not seen anyone from the team trying to fix the issue.

As far as we can tell when this happens the issue is power supply related.