This happens but I have not been able to determine why or how.
Not sure how that would be implemented but really only LimeSuiteGui should be able to alter the firmwares. I don’t do that much with my board. Very generic stuff, gnuradio, pothos, gqrx, etc. Just apps. Sure it’s easy enough to re-flash but that shouldn’t need to be done except on intentional upgrades. But maybe that’s inherent with how this device works. i.e. altering the firmware is how this board is controlled/calibrated, etc.
[WARNING] Gateware version mismatch!
Expected gateware version 2, revision 8
But found version 0, revision 0
There’s another topic on this and it seems to point to USB3 controllers but I’m not convinced of that. I run USB HDDs on this port for backups and don’t see problems at high data rates.
It could be a problem with the kernel usb stack or libusb. But no other devices have shown any similar symptoms.
Yes it’s resolved by re-flashing. I am concerned that it’s happening at all. Resolving it’s easy enough. That’s good but better to avoid the problem and understanding how it happens would be good. Some kind of guard might be needed to prevent spurious, unwanted erasures/corruption?
Inadequate power supply could cause flash corruption, but would have expected this only to happen during writes to it and not sure whether this happens outside of updating the firmware.
I had my Lime lock up while I was testing transmit. It just stopped responding. I closed the app and opened up LimeSuiteGui and saw the above message. I then unplugged the Lime and tried again and this time there was no error.
Extra info… I am using the LimeSuite git master. But the real discussion should probably be around whether or not we want applications to have access to the fpga flash. Is that a reasonable question to even ask? Is there anyway to protect the flash?
May be that I have some gaps (huge?) in my understanding of the way this all works.
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 .
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: Lime Suite - Myriad-RF Wiki
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
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? I am a human fuzzer (or fool).
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?
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.)
@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.
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):
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.
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.
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 --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
.
I am a human fuzzer (or fool). 
