Just trying to get started, having no luck

gump · 17 April 2017 18:41

I have 2 of the Lime SDRs, and cannot get them working with anything, So I am down to just verifying that i have a usable software install.

I thought I had a firmware mismatch, and ran “LimeUtil --update” and I think I bricked one of my Lime SDRs. (Green FPGA LEDs, no power LED and FX3 LED blinks RED) But more on that after I actually get something working on the remaining one, obviously don’t want to try the update again just yet.

Hardware is an Intel NUC i5:

user@nuc-lab:~/Downloads$ sudo lshw -short
[sudo] password for user:
H/W path Device Class Description

                      system         Desktop Computer

/0 bus D54250WYK
/0/0 memory 64KiB BIOS
/0/3a processor Intel® Core™ i5-4250U CPU @ 1.30GHz
/0/3a/3b memory 512KiB L2 cache
/0/3a/3c memory 128KiB L1 cache
/0/3a/3d memory 3MiB L3 cache
/0/3e memory 16GiB System Memory
/0/3e/0 memory 8GiB SODIMM DDR3 Synchronous 1600 MHz (0.6 ns)
/0/3e/1 memory 8GiB SODIMM DDR3 Synchronous 1600 MHz (0.6 ns)
/0/100 bridge Haswell-ULT DRAM Controller
/0/100/2 display Haswell-ULT Integrated Graphics Controller
/0/100/3 multimedia Haswell-ULT HD Audio Controller
/0/100/14 bus 8 Series USB xHCI HC
/0/100/14/0 usb2 bus xHCI Host Controller
/0/100/14/0/2 generic WestBridge
/0/100/14/0/4 input USB Receiver
/0/100/14/1 usb3 bus xHCI Host Controller
/0/100/16 communication 8 Series HECI #0
/0/100/19 eno1 network Ethernet Connection I218-V
/0/100/1b multimedia 8 Series HD Audio Controller
/0/100/1d bus 8 Series USB EHCI #1
/0/100/1d/1 usb1 bus EHCI Host Controller
/0/100/1d/1/1 bus USB hub
/0/100/1f bridge 8 Series LPC Controller
/0/100/1f.2 storage 8 Series SATA Controller 1 [AHCI mode]
/0/100/1f.3 bus 8 Series SMBus Controller
/0/1 scsi0 storage
/0/1/0.0.0 /dev/sda disk 500GB Samsung SSD 850
/0/1/0.0.0/1 volume 511MiB Windows FAT volume
/0/1/0.0.0/2 /dev/sda2 volume 449GiB EXT4 volume
/0/1/0.0.0/3 /dev/sda3 volume 15GiB Linux swap volume
/1 power To Be Filled By O.E.M.

And I’m running Ubuntu 16.04, fully up to date:

user@nuc-lab:~/Downloads$ uname -a
Linux nuc-lab 4.8.0-46-generic #49~16.04.1-Ubuntu SMP Fri Mar 31 14:51:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I installed the following from the repositories (Seemed like the easiest way to get started)

sudo add-apt-repository -y ppa:ettusresearch/uhd
sudo add-apt-repository -y ppa:myriadrf/drivers
sudo add-apt-repository -y ppa:myriadrf/gnuradio
sudo add-apt-repository -y ppa:gqrx/gqrx-sdr
sudo apt-get update

sudo apt-get install osmo-sdr libosmocore libosmocore-dev gnuradio
sudo apt-get install limesuite limesuite-udev limesuite-images
sudo apt-get install soapysdr soapysdr-module-lms7
sudo apt-get update

When i plug in the Lime SDR:

relevant dmesg output when I plug in the Lime

[ 1892.407782] usb 2-1: new high-speed USB device number 3 using xhci_hcd
[ 1892.548392] usb 2-1: New USB device found, idVendor=04b4, idProduct=00f3
[ 1892.548396] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1892.548399] usb 2-1: Product: WestBridge
[ 1892.548401] usb 2-1: Manufacturer: Cypress
[ 1892.548403] usb 2-1: SerialNumber: 0000000004BE

user@nuc-lab:~$ lsusb
Bus 001 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 002 Device 003: ID 04b4:00f3 Cypress Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

user@nuc-lab:~$ LimeUtil --info
######################################################

LimeSuite information summary

######################################################

Version information:
Library version: v17.02.1-myriadrf1~xenial
Build timestamp: 2017-03-12
Interface version: v2017.2.0
Binary interface: 17.02-1

System resources:
Installation root: /usr
User home directory: /home/user
App data directory: /home/user/.local/share/LimeSuite
Config directory: /home/user/.limesuite
Image search paths:
- /home/user/.local/share/LimeSuite/images
- /usr/share/LimeSuite/images

Supported connections:

NovenaRF7
PCIEXillybus
STREAM
uLimeSDR

user@nuc-lab:~$ LimeUtil --find

[WestBridge , media=USB 2.0, module=STREAM, addr=04b4:00f3, serial=0000000004BE]

user@nuc-lab:~$ SoapySDRUtil --info
######################################################

Soapy SDR – the SDR abstraction library

######################################################

Lib Version: v0.5.4-0.5.4-myriadrf1~xenial
API Version: v0.5.2
ABI Version: v0.5-2
Install root: /usr
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so
Loading modules… done
Available factories…lime, null,

user@nuc-lab:~$ SoapySDRUtil --find
######################################################

Soapy SDR – the SDR abstraction library

######################################################

Found device 0
addr = 04b4:00f3
driver = lime
label = WestBridge [USB 2.0] 4BE
media = USB 2.0
module = STREAM
name = WestBridge
serial = 0000000004BE

So it looks like everything is good, but no osmosdr blocks in GRC and when I connect to the Lime with the LimeUtilGui It shows all the version information as 0 and cannot / will not pull the device info. See attached screen shots.

Maybe I’m just missing something obvious, or have done something out of order or wrong. (Hard to tell, as I cannot find even a simple quick start tutorial that is complete / up to date)

I have been through the forum, that’s what led me to try the firmware update (didn’t go well, red blinky) And I have a couple years experience with other SDR platforms, GNURadio, GQRX etc…

No idea where to go from here. Any ideas / suggestions / experiences / comments or information would be greatly appreciated.

BT/AR
Chris “Gump” Graves

hTo137 · 17 April 2017 18:50

Don’t see a LimeSDR in that output.

Try a USB3 port.
You have udev rules configured?
lsusb -t

gump · 17 April 2017 19:09

This hardware shouldn’t have any USB 2 exposed only on the internal header. All external ports are labeled blue and labeled as SS, but you are correct, my B200 mini also shows as a USB 2 device not USB 3. I’lll look into that.

According to other forum posts, folks are having USB problems, but are operating at reduced throughput on USB 2. So my question is does it have to be USB 3 for the Lime?

Will be back tomorrow, with better understanding of what is going on with my USB ports.

Thank you for the first hit here.

andrewback · 17 April 2017 20:00

This is the default USB VID/PID of the Cypress FX3 microcontroller and so it looks like either quite an old firmware is loaded (from before we had a PID allocated by Openmoko) or it’s dropping back to not booting. Is jumper J3 fitted? This enables the FX3 booting from flash.

You shouldn’t be able to permanently brick the board and worst case would need to install the Cypress FX3 SDK for a utility that you can use to program the flash. See:

https://wiki.myriadrf.org/LimeSDR-USB_User_Guide#Flashing_the_USB_3.0_microcontroller

Note that the above guide needs updating, but the section on removing the jumper and flashing using CyControl.exe is still valid.

zener · 18 April 2017 05:12

On Linux I would assume that it should be possible to upload to the FX3 RAM using “fxload -t fx3 -i /path/to/firmware.img” rather than CyControl.exe.

gump · 18 April 2017 16:23

All, thanks for your help so far. BIOS update did wonders for the Intel NUC USB problems. I have 2 lime SDR boards working now, at least acting like they are working. I still have 1 board that is not working, looks like I need to flash it. I attempted the fxload recommended by Zener, but apparently the stock fxload does not support the fx3, so I’ll work that out.

I’ll be back, probably in another post if I can’t get the other board re-flashed in a couple of days.

thanks again to everyone for getting me up and running.

BT/AR
Gump

andrewback · 18 April 2017 16:42

Glad to hear you’re making progress and had previously missed you were using a NUC. I’ve previously got on OK with Core i5 and i7 NUCs without having to update BIOS, but I guess there could easily be a release or two out there with USB port issues. Always (mostly!) a good idea to load the latest and greatest, in any case.

zener · 18 April 2017 19:20

You need a fairly recent version of libusb/fxload to support the FX3:

$ fxload -h

Usage: fxload [-v] [-V] [-t type] [-d vid:pid] [-p bus,addr] [-s loader] -i firmware
  -i <path>       -- Firmware to upload
  -s <path>       -- Second stage loader
  -t <type>       -- Target type: an21, fx, fx2, fx2lp, fx3
  -d <vid:pid>    -- Target device, as an USB VID:PID
  -p <bus,addr>   -- Target device, as a libusb bus number and device address path
  -v              -- Increase verbosity
  -q              -- Decrease verbosity (silent mode)
  -V              -- Print program version

$ fxload  -V
Jan 15 2017 (libusb)

hTo137 · 18 April 2017 20:30

Not sure what stock is but fx3 support has been there for several years.

github.com

libusb/libusb/blob/master/examples/fxload.c#L71


      
          #endif
          		vfprintf(stderr, format, ap);
          	va_end(ap);
          }
          
          static int print_usage(int error_code) {
          	fprintf(stderr, "\nUsage: fxload [-v] [-V] [-t type] [-d vid:pid] [-p bus,addr] [-s loader] -i firmware\n");
          	fprintf(stderr, "  -i <path>       -- Firmware to upload\n");
          	fprintf(stderr, "  -s <path>       -- Second stage loader\n");
          	fprintf(stderr, "  -t <type>       -- Target type: an21, fx, fx2, fx2lp, fx3\n");
          	fprintf(stderr, "  -d <vid:pid>    -- Target device, as an USB VID:PID\n");
          	fprintf(stderr, "  -p <bus,addr>   -- Target device, as a libusb bus number and device address path\n");
          	fprintf(stderr, "  -v              -- Increase verbosity\n");
          	fprintf(stderr, "  -q              -- Decrease verbosity (silent mode)\n");
          	fprintf(stderr, "  -V              -- Print program version\n");
          	return error_code;
          }
          
          #define FIRMWARE 0
          #define LOADER 1
          int main(int argc, char*argv[])

gump · 19 April 2017 12:21

So this is what I mean by stock:

gump@gump-G750JX:~$ sudo apt-get install fxload
[sudo] password for gump:
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
linux-headers-4.4.0-70 linux-headers-4.4.0-70-generic linux-image-4.4.0-70-generic
linux-image-extra-4.4.0-70-generic
Use ‘sudo apt autoremove’ to remove them.
The following NEW packages will be installed:
fxload
0 upgraded, 1 newly installed, 0 to remove and 13 not upgraded.
Need to get 16.8 kB of archives.
After this operation, 81.9 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 fxload amd64 0.0.20081013-1ubuntu1 [16.8 kB]
Fetched 16.8 kB in 0s (308 kB/s)
Selecting previously unselected package fxload.
(Reading database … 359295 files and directories currently installed.)
Preparing to unpack …/fxload_0.0.20081013-1ubuntu1_amd64.deb …
Unpacking fxload (0.0.20081013-1ubuntu1) …
Processing triggers for man-db (2.7.5-1) …
Setting up fxload (0.0.20081013-1ubuntu1) …
gump@gump-G750JX:~$ fxload -h
fxload: invalid option – ‘h’
usage: fxload [-vV] [-l] [-t type] [-D devpath]
[-I firmware_hexfile] [-s loader] [-c config_byte]
[-L link] [-m mode]
… [-D devpath] overrides DEVNAME= and DEVICE= in env
… device types: one of an21, fx, fx2, fx2lp
… at least one of -I, -L, -m is required
gump@gump-G750JX:~$ fxload -t fx3 -I LimeSDR-USB_fx3_fw.img
illegal microcontroller type: fx3
usage: fxload [-vV] [-l] [-t type] [-D devpath]
[-I firmware_hexfile] [-s loader] [-c config_byte]
[-L link] [-m mode]
… [-D devpath] overrides DEVNAME= and DEVICE= in env
… device types: one of an21, fx, fx2, fx2lp
… at least one of -I, -L, -m is required
gump@gump-G750JX:~$

I have to find a version of fxload that doesn’t do that. The one available in the repository, “stock”, doesn’t support fx3 as demonstrated above.

BT/AR
Gump

andrewback · 19 April 2017 12:40

It looks like the official project is no longer maintained and the version that is shipped with Ubuntu dates back to 2008.

There appears to be a fork with FX3 support, which is also quite old:

Found a slightly newer one here:

https://bitbucket.org/DJOConnor/fxload

Not tested any of these as yet.

gump · 19 April 2017 12:46

Thanks Andrew, I’m loading it up today, and will let you know how it goes.

BT/AR
Gump

IgnasJ · 19 April 2017 19:10

Hello,

If your board is displayed as “WestBridge” it means that FX3 was not able to boot from flash and FX3 bootloader is running.

You can try programming FX3 manually from LimeSuiteGUI:

“Options->connection settings” connect to device displayed as “WestBridge”
Go to “Modules->programming”
2.1. select device: ‘FX3’, programming mode: “Firmware to RAM”
2.2. Click ‘Open’ button and select firmware file
2.3. Click ‘Program’ button
2.4. Re-connect to the board via “Options->Connection settings”. If programming went OK, the device should be displayed as “LimeSDR-USB” now.

If programming to RAM succeeds, try programming FW to flash by repeating the previous steps (from 2.) and selecting programming mode: “Firmware to Flash” in 2.1. Firmware loaded to RAM will be lost if you power cycle the board. Programming to flash from LimeSuiteGUI only works when LimeSDR FW is loaded.

There is also Cypress GUI tool (cyusb_linux) for programming FX3. It comes with “FX3 SDK for Linux” (needs registration for download): http://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit

zener · 19 April 2017 19:33

It seems like many distros have quite old versions of usblib/fxload. Like hTo137 said, it’s been there for quite a while:

$ git blame fxload.c |grep -i fx3
8aa50632 (Pete Batard       2013-03-16 23:36:47 +0000  71)      fprintf(stderr, "  -t <type>       -- Target type: an21, fx, fx2, fx2lp, fx3\n");
$ git tag --contains 8aa50632
v1.0.15
v1.0.15-rc1
v1.0.15-rc2
v1.0.15-rc3
v1.0.16
v1.0.16-rc1
v1.0.16-rc2
v1.0.16-rc3
v1.0.17
v1.0.17-rc1
v1.0.18
v1.0.18-rc1
v1.0.19
v1.0.19-rc1
v1.0.19-rc2
v1.0.20
v1.0.20-rc1
v1.0.20-rc2
v1.0.20-rc3
v1.0.21
v1.0.21-rc1
v1.0.21-rc2
v1.0.21-rc3
v1.0.21-rc4
v1.0.21-rc5
v1.0.21-rc6

It might have been there even longer, but the fx3 line in the help was updated in 2013.

Maybe it’s easier to go with the LimeSuite if you can’t find a more recent libusb.

BTW, the git blame above is from https://github.com/libusb/libusb.git

gump · 20 April 2017 15:29

I J,

I tried both of your suggestions here and also got the right version of fxload running. Still can’t solve the problem but here is where I’m at for now.

On using the LimeSuiteGUI, I cam able to load the img file to ram and get the SDR recognized as LimeSDR.

user@nuc-lab:~$ LimeUtil --find

[LimeSDR-USB, media=USB 3.0, module=STREAM, addr=1d50:6108, serial=0009060B00463218]

user@nuc-lab:~$ SoapySDRUtil --find
######################################################

Soapy SDR – the SDR abstraction library

######################################################

Found device 0
addr = 1d50:6108
driver = lime
label = LimeSDR-USB [USB 3.0] 9060B00463218
media = USB 3.0
module = STREAM
name = LimeSDR-USB
serial = 0009060B00463218

But it fails when I reconnect and try to upload to FW to Flash.

So I went the second route with cyusb_linux.

I tried to write to SPI flash and I2C EEprom. It looks like the correct one is I2C EEPROM, but it still failed. I ran it as the user and with sudo, the terminal out put is here:

user@nuc-lab:~/fx3utils/cyusb_linux_1.0.4$ cyusb_linux
No device found
Signal 10 (=SIGUSR1) received !
No of devices of interest found = 1
Current device is not the FX3 flash programmer
Failed to find FX3 flash programmer
Trying to download flash programmer to RAM
Signal 10 (=SIGUSR1) received !
No device of interest found
Signal 10 (=SIGUSR1) received !
No of devices of interest found = 1
Found FX3 flash programmer
Timed out on SPI status read
Failed to erase SPI flash
Found FX3 flash programmer
Writing firmware image to I2C EEPROM
Failed to read expected data from I2C EEPROM
Read-verify from I2C EEPROM failed
Vendor write to FX3 RAM failed
Failed to download data to FX3 RAM
user@nuc-lab:~/fx3utils/cyusb_linux_1.0.4$ sudo cyusb_linux
Signal 10 (=SIGUSR1) received !
No device of interest found
Signal 10 (=SIGUSR1) received !
No of devices of interest found = 1
Current device is not the FX3 flash programmer
Failed to find FX3 flash programmer
Trying to download flash programmer to RAM
Signal 10 (=SIGUSR1) received !
No device of interest found
Signal 10 (=SIGUSR1) received !
No of devices of interest found = 1
Found FX3 flash programmer
Timed out on SPI status read
Failed to erase SPI flash
Found FX3 flash programmer
Writing firmware image to I2C EEPROM
Failed to read expected data from I2C EEPROM
Read-verify from I2C EEPROM failed
user@nuc-lab:~/fx3utils/cyusb_linux_1.0.4$

Then I went with the fxload option here, this is the second attempt after I used the nuclear permissions option on the img file:

user@nuc-lab:~$ fxload -t fx3 -I LimeSDR-USB_fx3_fw.img -D /dev/bus/usb/003/001
Permission denied : /dev/bus/usb/003/001
user@nuc-lab:~$ sudo fxload -t fx3 -I LimeSDR-USB_fx3_fw.img -D /dev/bus/usb/003/001
[sudo] password for user:
LimeSDR-USB_fx3_fw.img: unable to open for input.
user@nuc-lab:~$ cd Downloads/
user@nuc-lab:~/Downloads$ ls -la
total 748
drwxr-xr-x 2 user user 4096 Apr 20 09:26 .
drwxr-xr-x 25 user user 4096 Apr 20 11:00 …
-rwxrwxrwx 1 user user 186040 Apr 14 09:53 LimeSDR-USB_fx3_fw.img

So in all honesty, this is progress. Next step I will re-download and checksum the img file and try all of this again. Now that all the utilities appear to be running correctly.

BT/AR
Gump

zener · 20 April 2017 19:18

The option to upload in fxload is “-i” (this is the fxload which is included in libusb, it might be that there are other versions of fxload out there). Here’s an example on how to upload a LimeSDR image from the git repository to a FX3 RAM:

$ git rev-parse HEAD
07d6eb95f98f18d5eb5db2ffa0359362a8e543a5
$ lsusb |egrep -i cypress\|openmoko
Bus 008 Device 007: ID 04b4:00f3 Cypress Semiconductor Corp. 
$ fxload  -t fx3 -i Debug/LimeSDR-USB_fx3_fw.img 
found device 'Cypress FX3' [04b4:00f3] (8,7)
microcontroller type: fx3
Debug/LimeSDR-USB_fx3_fw.img: type Cypress IMG format
open firmware image Debug/LimeSDR-USB_fx3_fw.img for RAM upload
normal FW binary executable image with checksum
FX3 bootloader version: 0x000000A9
writing image...
transfer execution to Program Entry at 0x400105f0
$ lsusb |egrep -i cypress\|openmoko
Bus 009 Device 005: ID 1d50:6108 OpenMoko, Inc.

If you don’t have the permissions set up to write to the usb device you’ll have to use sudo to run fxload as you did previously.

IgnasJ · 20 April 2017 19:22

There seems to be a problem accessing FX3 flash as you are able to load firmware into RAM but cannot load it to flash or boot from flash. Normally, this happens when FX3 BOOT jumper is removed, so make sure that it is placed.

As I understand, when you tried programming to flash from LimeSuiteGUI, you 1) programmed to RAM, 2) connected to LimeSDR-USB, and then 3) tried programming to flash. Is that right? (It is the correct sequence).

The correct option in cyusb_linux should be ‘SPI Flash’.

Not sure if this could help, but you can try programming the most recent FPGA GW first (your board reports v2.5, and the most recent on GitHub is v2.9):

Load FX3 firmware to RAM,
connect to “LimeSDR-USB”,
“Modules->programming”, device “Altera FPGA”, mode “Bitstream to flash”, select ‘.rbf’ file, and click “Program”
Re-connect to “LimeSDR-USB” (if it shows up as “WestBridge”, program FX3 to RAM again).
Check “GW_rev” that is reported after connecting (if FPGA programming succeeded, should be 8 or 9 instead of 5)
Try programming FX3 to flash.

gump · 25 April 2017 15:31

I tried following your instructions here, both with the Lime in it’s initial state and with the FW flashed to RAM through the LimeUtilGUI. I’m still open to suggestions, you will see that i tried the “i” as you suggest, but it was an invalid option. the help shows that “I” is the switch to ID the firmware image, for this version of fxload. It looks like we have the same version of the repository, so…

user@nuc-lab:~/LimeSDR-USB_FX3$ git rev-parse HEAD
07d6eb95f98f18d5eb5db2ffa0359362a8e543a5
user@nuc-lab:~/LimeSDR-USB_FX3$ lsusb |egrep -i cypress\|openmoko
Bus 002 Device 007: ID 04b4:00f3 Cypress Semiconductor Corp. 
user@nuc-lab:~/LimeSDR-USB_FX3$ fxload  -t fx3 -i Debug/LimeSDR-USB_fx3_fw.img
fxload: invalid option -- 'i'
usage: fxload [-vV] [-B backend] [-l] [-t type] [-D devpath]
		[-I firmware_hexfile] [-s loader] [-c config_byte]
		[-L link] [-m mode]
... [-D devpath] overrides DEVICE= in env
... device types:  one of an21, fx, fx2, fx2lp, fx3
... at least one of -I, -L, -m is required
user@nuc-lab:~/LimeSDR-USB_FX3$ fxload  -t fx3 -I Debug/LimeSDR-USB_fx3_fw.img
no device specified!
usage: fxload [-vV] [-B backend] [-l] [-t type] [-D devpath]
		[-I firmware_hexfile] [-s loader] [-c config_byte]
		[-L link] [-m mode]
... [-D devpath] overrides DEVICE= in env
... device types:  one of an21, fx, fx2, fx2lp, fx3
... at least one of -I, -L, -m is required
user@nuc-lab:~/LimeSDR-USB_FX3$ git rev-parse HEAD
07d6eb95f98f18d5eb5db2ffa0359362a8e543a5
user@nuc-lab:~/LimeSDR-USB_FX3$ lsusb |egrep -i cypress\|openmoko
Bus 003 Device 003: ID 1d50:6108 OpenMoko, Inc. 
user@nuc-lab:~/LimeSDR-USB_FX3$ fxload  -t fx3 -i Debug/LimeSDR-USB_fx3_fw.img
fxload: invalid option -- 'i'
usage: fxload [-vV] [-B backend] [-l] [-t type] [-D devpath]
		[-I firmware_hexfile] [-s loader] [-c config_byte]
		[-L link] [-m mode]
... [-D devpath] overrides DEVICE= in env
... device types:  one of an21, fx, fx2, fx2lp, fx3
... at least one of -I, -L, -m is required
user@nuc-lab:~/LimeSDR-USB_FX3$ fxload  -t fx3 -I Debug/LimeSDR-USB_fx3_fw.img
no device specified!
usage: fxload [-vV] [-B backend] [-l] [-t type] [-D devpath]
		[-I firmware_hexfile] [-s loader] [-c config_byte]
		[-L link] [-m mode]
... [-D devpath] overrides DEVICE= in env
... device types:  one of an21, fx, fx2, fx2lp, fx3
... at least one of -I, -L, -m is required
user@nuc-lab:~/LimeSDR-USB_FX3$ fxload  -t fx3 -I Debug/LimeSDR-USB_fx3_fw.img -D /dev/bus/usb/003/003
ctrl_msg returned an error=-1, errno=32
write on-chip: Broken pipe
unable to download Debug/LimeSDR-USB_fx3_fw.img
user@nuc-lab:~/LimeSDR-USB_FX3$

I’m up for the next suggestion, or if anyone can tell me what I’m doing wrong.

gump · 25 April 2017 15:33

I J,

I followed your instructions here and it looked good until this…

I chose “stop” at this point. If i should have continued I can run it again, but i didn’t want to potentially make things worse.

Thanks for your help and any additional suggestions.

gump · 25 April 2017 15:36

Forgot to upload the backtrace file from that attempt, here it is.

ASSERT INFO:
../src/gtk/gauge.cpp(67): assert "0 <= m_gaugePos && m_gaugePos <= m_rangeMax" failed in DoSetGauge(): invalid gauge position in DoSetGauge()

BACKTRACE:
[1] wxGauge::DoSetGauge()
[2] void std::vector<unsigned char, std::allocator<unsigned char> >::emplace_back<unsigned char>(unsigned char&&)
[3] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[5] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[6] wxEvtHandler::TryHereOnly(wxEvent&)
[7] wxEvtHandler::ProcessEventLocally(wxEvent&)
[8] wxEvtHandler::ProcessEvent(wxEvent&)
[9] wxEvtHandler::ProcessPendingEvents()
[10] wxAppConsoleBase::ProcessPendingEvents()
[11] wxApp::DoIdle()
[12] g_main_context_dispatch
[13] g_main_loop_run
[14] gtk_main
[15] wxGUIEventLoop::DoRun()
[16] wxEventLoopBase::Run()
[17] wxAppConsoleBase::MainLoop()
[18] wxEntry(int&, wchar_t**)
[19] __libc_start_main
[20] _start

Just trying to get started, having no luck

user@nuc-lab:~/Downloads$ sudo lshw -short [sudo] password for user: H/W path Device Class Description

LimeSuite information summary

Soapy SDR – the SDR abstraction library

Soapy SDR – the SDR abstraction library

Soapy SDR – the SDR abstraction library

user@nuc-lab:~/Downloads$ sudo lshw -short
[sudo] password for user:
H/W path Device Class Description