-
Notifications
You must be signed in to change notification settings - Fork 460
Troubleshooting
This page provides some quick tips on troubleshooting problems.
If you run across an issue not listed here and find a solution, please feel free to post it here!
|
By default, builds use -Werror or /WX to treat warnings as errors, with the intent of forcing developers to address any warnings.
Occasionally, we've seen different compiler versions throw errors that were not seen on developers' machines, breaking master for users.
Master is intended to always build. If you suspect a build is broken due to a warning being treated as an error, please report it via IRC or the issue tracker, and run the following from your build directory as a temporary workaround:
cmake -DTREAT_WARNINGS_AS_ERRORS=No ../If the libusb is reported to not be found, it may be the case that pkgconfig was not able to locate libusb. (This will certainly be the case for Windows.) Check your PKG_CONFIG_PATH variable, and ensure that libusb is installed to a location in your system's library search path.
Users that are in a *nix environment and have installed libusb via a package manager, should double check that both the library and development packages for libusb-1.0 (sometimes packaged as libusbx-1.0) are installed.
Windows users should use the LIBUSB_PATH CMake variable to specify the location of a the libusb(x) binary distribution.
If you receive a message similar to the following when running CMake, you'll need to obtain a more recent version of libusb:
A newer libusb version is needed by libbladeRF. libusb >= v1.0.10 is required to build. libusb >= v1.0.16 is recommended.
For some distributions, it may be possible to simply pull in a package from an upstream source for a later distro version. However, this is not always possible, as more recent versions of libusb packages may require a newer libc or libudev.
For example, Ubuntu 12.04 users will find that libusb-1.0.9 is provided in the repositories. In this case, it is recommended to upgrade to a more recent distribution (a 3.8+ kernel is also highly desirable). If this is not possible, these users may want to try obtaining a libusb package from the 12.10 repositories (this has not been tested), or attempt to build a slightly newer version from source.
Note: This build issue has been resolved as of commit 95a6c1d0e098. If you see this issue, ensure that you've checkout out the lastest codebase, remove and recreate your build directory, and re-run CMake.
If you see an error about being unable to find the libusb_get_version function, the version of libusb installed on your machine needs to be updated. Updating to >= 1.0.10 for Linux is required, but >= 1.0.16 is highly suggested.
There is an open action item to change the CMake configuration to detect and complain about this, prior to compilation.
If you obtain a warning about the installed libusb version not containing hotplug support, you'll need a newer libusb version to build bladeRF-flash. See Outdated libusb
Please take a look at Building libtecla and note the sed script required to remove the link to libgcc.a in the Makefile. This is due to the fact that the configure script for libtecla uses gcc -print-libgcc-file-name, which does not provide a full-path.
Removing all notion of libgcc.a from the Makefile appears to alleviate the problem. Alternatively, one may be able to replace this item with the full path the the clang-provided libgcc.a.
Currently, only one program may have a device open at a time. Any additional calls to bladerf_open() or bladerf_open_with_devinfo() will fail with BLADERF_ERR_NODEV.
Under the hood, this is due to the first caller opening a device claiming the device's interfaces via libusb_claim_interface(). Further attempts to claim an interface will fail with LIBUSB_ERROR_BUSY.
Setting the libbladeRF log level to DEBUG or VERBOSE will generally make this issue apparent. See the bladeRF-cli -v option, or libbladeRF's bladerf_log_set_verbosity() function for information on setting the log level.
For example, if a first instance of the bladeRF-cli is started:
$ bladeRF-cli -i -v verbose bladeRF> info Serial #: 00000000000000000000000000000000 VCTCXO DAC calibration: 0x8100 FPGA size: 40 KLE FPGA loaded: yes USB bus: 2 USB address: 6 USB speed: Hi-Speed Backend: libusb Instance: 0
If another instance of the CLI is run simultaneously, we'll see the aforementioned libusb error about a device being busy (as its interfaces are already claimed by a different device handle.):
$ bladeRF-cli -i -v verbose ~ [VERBOSE] Found a bladeRF [DEBUG] FPGA currently does not have a version number. [DEBUG] Could not claim interface 0 - LIBUSB_ERROR_BUSY No device(s) attached. bladeRF>
If you're encountering the following error message with GNU Radio programs, but have verified that the device operates in the CLI, double check that no other programs have the device open:
FATAL: bladerf_source_c failed to open bladeRF device libusb:instance=0
Under normal operation, the bladeRF should appear with VID=1d50 and PID=6066.
If you see a Cypress device with VID=04b4 and PID=00f3, your bladeRF's FX3 may be in its bootloader mode. In this case, you may see a message in the bladeRF-cli program that notes a potential bladeRF running in bootloader mode. See the firmware upgrade wiki page for information on flashing the device.
If you are using a Virtual Machine, there have been issues reported when changing the interfaces or claiming different interfaces. The level of success has been varied depending on the type of port (XHCI or EHCI) and the VM software used.
It has been reported that some VM software does not fully support USB 3.0. Verify the speed that the VM detects the device at, and try falling back to 2.0 if 3.0 does not work.
To see the device in Windows, ensure you have the appropriate inf installed so that Windows associated the bladeRF with a libusbK driver. Verify that you've followed these steps in the Getting Started guide for Windows.
Windows driver signing enforcement may cause driver installation problems. Try using the latest Zadig on the computer you want to install the driver on. Zadig will self-sign the driver package and install the corresponding certificate.
In Windows 8, Libusbx may incorrectly report USB 3.0 SuperSpeed connection as Hi-Speed.
If you have performed an operating system update, and a previously working bladeRF stops working, you might have a mismatch between the OS and libusb. (For example moving from OSX 10.9.0 to 10.9.1). A sign of this will be that you can see the device via bladeRF-cli -p, but you cannot send or receive any data and instead you will see error messages like [ERROR] Failed to access peripheral. In this case, reinstall libusb:
$ sudo port -f uninstall libusb $ sudo port install libusb
As USB 3.0 is still relatively new, we've heard reports of some controller working great, and others not working at all. Ensure you have the latest drivers (and firmware, if needed) for your USB controller.
If possible, try testing the device on both USB 2.0 and USB 3.0 ports, as well as other host machines.
There is currently a known problem with Intel XHCI controllers in Linux, where killing an application using libbladeRF (which uses libusb) in a manner that doesn't allow libusb_close() to be called. The symptoms will include kernel crashes with NULL pointer dereferences in xhci_free_dev(), and "not enough bandwidth for altsetting...) messages in dmesg (requiring a Power-on Reset).
To avoid this issue, ensure that programs using the device are closed cleanly: - Add SIGTERM/SIGINT handlers to your custom applications to ensure the bladeRF device handle is closed. See the bladeRF-cli source for a reference. - When using GNU Radio Companion, **do not** click the "Kill flowgraph" (a red X) button. Instead, close the GUI window associated with the flow graph. If your flow graph doesn't contain any GUI widgets, you'll have to add a dummy one just to achieve this.
As always, any help into investigating this issue is appreciated!
Below is a list of configurations that people have reported success on. Feel free to add to this list. (Please try to keep it reasonably organized.)
| Configuration Name | Device/Motherboard/CPU | Controller or Chipset | Operating System(s) |
| jynik's Desktop | EVGA x58 FTW3, Intel i7 | Onboard NEC/Renesas controller and 2-Port PCIe card NEC/Renesas | Windows 7, XUbuntu 12.10, 13.04, 13.10 (All 64-bit) |
| jynik's Laptop | Thinkpad W530, Intel i7-3630QM | Intel 7 Series/C210 Series xHCI (VID=8086, PID=1e31) | Windows 7, XUbuntu 13.04 (All 64-bit). Note: The XHCI issues mentioned above applies to the Linux configuration here. Able to process 40 Msps in osmocom_fft without overruns. |
| drmpeg's Desktop | Dell T3600, Intel E5-1607 | Onboard NEC uPD720200 xHCI | Ubuntu 13.04 (32-bit just to run old XView stuff). Able to process 36 Msps in osmocom_fft without overruns. |
| tnt's laptop | Apple Mac Book Pro Late 2008 (MacBookPro5,1) | ExpressCard ASM1042 (VID=1b21, PID=1042) | Gentoo (3.8.10-gentoo x86_64) |
| piranha32's desktop | Asus P6T / i7 920@2.67GHz | VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 02) | Fedora 19 x86_64. osmocom_fft works without overruns @42Msps. |
| Anker PCI-E card | Uspeed USB 3.0 PCI-E Express Card with 4 USB 3.0 Ports | VL805 Chipset (VIA Technologies, Inc. Device 3483 (rev 01)) | Ubuntu 13.04 x86_64. osmocom_fft runs without issue at 40Msps |
| scancapecod's at work desktop | Dell Optiplex 9020 / i5-4570 @ 3.20GHz | Intel 8 Series/C220 Series USB Enhanced Host Controller, Intel USB 3.0 eXtensible Host Controller | Windows 7 Pro 64 bit Service Pack 1. SDR-Radio 30 MHz display |
Issues have been reported on the following configurations:
| Configuration Name | Device/Motherboard/CPU | Controller or Chipset | Operating System(s) | Issues and symptoms |
| steve-m's desktop (with onboard xHCI controller) | ASRock Z68 Pro3 Gen3, Z68, Intel i5-2500K | Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) | Xubuntu 13.10 x86_64, Linux 3.11 | "Failed to access peripheral", libusb timeouts, kernel reports "Not enough bandwidth for altsetting 0" and other xHCI related errors |
| Orico PCI-E card | PVU3-4P USB 3.0 PCI-Express Host Controller Card | VIA Technologies, Inc. VL80x xHCI USB 3.0 Controller (rev 03) | Ubuntu 13.04 X86_64 | Hard lock while loading firmware |
One possible reason for this error is a mismatch between the FPGA bistream and the firmware being used. As of firmware v1.6.0 and FPGA v0.0.1, the UART bridge baudrate has been increased. Therefore, a mismatch would result in peripheral communication failures, as the FX3 and the FPGA are unable to communicate.
If you're seeing this issue, ensure that you've updated both your firmware (cycle power after flashing), and FPGA. Ensure you've disabled FPGA autoloading before flashing the new firmware, otherwise the (old) autoloaded FPGA will be attempting to use the lower bridge baudrate.
To disable FPGA autoloading: bladeRF-cli -L X
In many cases, load failures have been the result of trying to load the wrong size FPGA image for the board in question. Check to make sure you are using the 40kLE FPGA for x40 and the 115kLE FPGA for x115.
If you're unsure which FPGA size is on your board, identify the the Altera Cyclone IV package on the top of the bladeRF. You should see text on the package that reads EP4CExxxF23C8N, where xxx is the size -- either 40 or 115.
If you're unable to load the FPGA using a USB 3.0 port while successfully doing so via USB 2.0, edit /linux/drivers/usb/host/xhci.h by changing TRBS_PER_SEGMENT from 64 to 256, and recompiling the kernel.
$ dmesg | grep xhci xhci_hcd 0000:03:00.0: Too many fragments 73, max 63
Affected Linux kernel versions: 3.12.6 to 3.12.9.
This has been patched in 3.12.10.
If you've used ports to get libusb installed, there is a high likelihood that it is version 1.0.9. Unfortunately, libusb didn't add superspeed support until version 1.0.15 for OSX. We've had reports that the absolute latest version of libusb, 1.0.17, works on OSX. Please update accordingly.
This warning comes up if you have a that is considered out-of-date and requires flashing.
Please update to the latest firmware, per the instructions in this wiki page.
If you're really stuck, join the #bladeRF channel on Freenode or post to the Nuand Troubleshooting forum.
Folks in the community are generally very happy to help. However, to make the most of everyone's time, please try to have as much of following information available as you can. Providing this information up front can help you get to the bottom of things much quicker.
- Information about the target host machine
- Are you in a VM? See the Virtual Machines section for some known problems.
- Are you running on a 32-bit or 64-bit processor?
- What is your USB controller? Given that USB3 is still moderately new, some controllers have found to perform significantly better (or worse) than others.
- Are you connecting your device to a 2.0 or 3.0 port? If a 3.0 port, is it connecting
- Is this a tablet or smartphone?
- The OS you're using
- For Linux, please note your distribution (and that distribution's version), as well as kernel version
- Version information for the items you're having issues with
- When running the bladeRF-cli in interactive mode (
bladeRF-cli -i), theversioncommand may be used to display information for both host items and the attached device. This is generally helpful in identifying if a problem you're seeing has been fixed in more recent versions.
- When running the bladeRF-cli in interactive mode (
- Any relevant error messages or warnings.
- Run the bladeRF-cli with
-v verboseto enable all output - (Linux users) Check the output of dmesg and lsusb
- For GNU Radio and gr-osmosdr issues, note the versions of these you're running.
- Run the bladeRF-cli with
- Have you followed the steps in the Getting Started guides?
- If you're currently in the process of following these guides, which steps have you already performed, and at which step are you encountering problems with?