When I Start LimeSuiteGUI (on linux) and connect to my board, a message appears on log area suggesting a firmware update:
16:04:37] WARNING: Gateware version mismatch!
Expected gateware version 2, revision 8
But found version 2, revision 6
Follow the FW and FPGA upgrade instructions:
http://wiki.myriadrf.org/Lime_Suite#Flashing_images
Or run update on the command line: LimeUtil --update
So, I go to a terminal to run «LimeUtil --update», but apparently it searches for a file that does not exist on the web:
Oh, sorry, I put the space by accident when cut&pasted the code here. The original line doesn’t have the space, obviously.
Seriously, I think the problem is that the git version of LimeUtil (I just compiled it) tries to look for an image from the 17.07 folder and this folder isn’t on the web yet:
The images don’t change with every Lime Suite release, but something obviously isn’t right, whether it’s the process of copying files on the downloads server or — as I’d have thought — the logic used when a non-tagged build checks to see if the board as the appropriate images loaded.
I have looked at the code and found out that the version number is taken from the latest entry in the changelog.txt. Which currently on master branch is “Release 17.07.0 (pending)”. So that is the problem.
Actually I am not sure why we need to include version number in file path as image names already contain their version (e.g. ‘LimeSDR-USB_HW_1.4_r2.8.rbf’ is exactly the same in 17.06 and 17.03 folders).
The fpga/fw images are versioned with the release major/minor. The tools look here for images: http://downloads.myriadrf.org/project/limesuite/ So, I made a copy of the last release to 16.07, but be careful to do that when making a new major.minor version. Should be ok now
But what is the reason for including software version number in path at all? FW/FPGA images already contain their version in filename so we could just link to something like .’…/fpga_images/LimeSDR-USB_HW_1.4_r2.8.rbf’. This way it would only be necessary to upload new image files to server when FPGA/FW actually changes.
The firmware/fpga images changed with features in the host driver. Rather than have a single directory with all versions of images ever made, the LimeSuite and various packaging platforms only have to download/store just the images needed for that release. Now it hasn’t changed very much recently, but that wasn’t always the case. Technically for the previous release some images should have been removed with the prototype models being deprecated. Anyway, that was the tradeoff – a little more effort on the web hosting end, but less files to download for the user.
Probe device driver=lime
[INFO] Make connection: ‘LimeSDR-USB [USB 3.0] 9070602527936’
[WARNING] Gateware version mismatch!
Expected gateware version 2, revision 11
But found version 2, revision 8
Follow the FW and FPGA upgrade instructions: http://wiki.myriadrf.org/Lime_Suite#Flashing_images
Or run update on the command line: LimeUtil --update
Yes, in the days of bear skins and flint knives of the LimeSDR development the beta testers, like me, had to remember ALL that stuff and remind ourselves not to brick our Limes…These kids today have it MUCH easier… !!
It is. The problem is when trying to write a bad value to the Lime, the ram becomes corrupted, at least that’s my interpretation. Let me describe the problem. When setting the bandwidth to the Lime, many times the operation isn’t successful, giving the error setBandwidth(Rx, 0, 30 MHz) Failed -. If we try to run the program again, we get the version mismatch error. After getting this error, if we unplug and plug again the Lime, the error goes away. If we don’t unplug the Lime, the error persists. Other note is that if we unplug and plug again the Lime after getting the setBandwidth(Rx, 0, 30 MHz) Failed - error, we get the same error. We only get the version mismatch error if we try to run the program yet again. To sum up, we get the setBandwidth(Rx, 0, 30 MHz) Failed - error many times, in order to resolve it we need to run the program again, to get the version mismatch error, and the unplug and plug the device. I hope this helps debugging the problem and helps to trace the source of the problem.
I am tagging @Zack because it seems that he’s somehow responsible for the actual hardware design of the board, so this should be important for him to have access to this information.