Intel Edison and BladeRF

Having issues with the site, hardware, source code, or any other issues?
Post Reply
fumiko
Posts: 6
Joined: Sun Mar 22, 2015 11:15 pm

Intel Edison and BladeRF

Post by fumiko »

Hi,
I tried to work Intel Edison with BladeRF, but had some bladeRF-cli trouble.
Does anyone succeed to work them? Please tell me anything.

I tried the following.
edison > uname -a
Linux ubilinux 3.10.17-yocto-standard-r2 #7 SMP PREEMPT Thu Feb 26 09:57:06 UTC 2015 i686 GNU/Linux

edison > dpkg -l |grep libusb
ii libusb-0.1-4:i386 2:0.1.12-20+nmu1 i386 userspace USB programming library
ii libusb-1.0-0:i386 2:1.0.19-1~bpo70+1 i386 userspace USB programming library
ii libusb-1.0-0-dbg:i386 2:1.0.19-1~bpo70+1 i386 userspace USB programming library development files
ii libusb-1.0-0-dev:i386 2:1.0.19-1~bpo70+1 i386 userspace USB programming library development files
ii libusb-dev 2:0.1.12-20+nmu1 i386 userspace USB programming library development files


After plugging bladeRF,
edison > dmesg
[ 3758.274941] usb 1-1: new high-speed USB device number 2 using dwc3-host
[ 3758.298433] usb 1-1: New USB device found, idVendor=1d50, idProduct=6066
[ 3758.298464] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3758.298486] usb 1-1: Product: bladeRF
[ 3758.298504] usb 1-1: Manufacturer: Nuand
[ 3758.298522] usb 1-1: SerialNumber: xxxxxxxxxxxx
[ 3758.485094] usb 1-1: reset high-speed USB device number 2 using dwc3-host


edison > lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1d50:6066 OpenMoko, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

edison > bladeRF-cli -i -v verbose
[VERBOSE @ libusb.c:515] Using libusb version: 1.0.19.10903
[VERBOSE @ libusb.c:406] Found a bladeRF (idx=1)
[VERBOSE @ libusb.c:458] USB port reset succeeded for bladeRF xxxxxxxxxxxx
[INFO @ usb.c:459] Waiting for device to become ready...
[DEBUG @ usb.c:461] Retry 02/30.
[DEBUG @ usb.c:461] Retry 03/30.
[DEBUG @ usb.c:461] Retry 04/30.
[DEBUG @ usb.c:461] Retry 05/30.
[DEBUG @ usb.c:461] Retry 06/30.
[DEBUG @ usb.c:461] Retry 07/30.
:
[DEBUG @ usb.c:461] Retry 29/30.
[DEBUG @ usb.c:461] Retry 30/30.
[DEBUG @ usb.c:469] Timed out while waiting for device.
Failed to open device (first available): Operation timed out

Distribusion is ubilinux.
I built bladeRF-cli from github's source code and libusb's version is 1.0.19.


Thanks,
jynik
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: Intel Edison and BladeRF

Post by jynik »

Hi there,

I haven't had the pleasure of working with one of those Edisons, but I think we see a few things here to look into. (However, I would totally take an Edison would take one if someone wants to provide me one for debug assistance... ;) ).

Since we don't have an Edison here, I think we'll need the following answered to get a sense of the situation:

(1) I see it looks like there's both USB 2.0 and 3.0 interfaces. However, dmesg shows the device is on a high-speed port. Is it actually on a 2.0 port? If not, that's one red flag.

(2) What is the state of the various LEDs after this timeout?

(3) Have you tried supplying external power via the DC barrel jack? (5V, I recommend a 1.5 - 2 A power supply just to be cautious). We have seen strange behavior on embedded systems using USB 2.0 (e.g., the Raspberry Pi) since they can't supply enough current to the device. Typically, the strange behavior resulting from insufficient power will begin once the FPGA has loaded or is attempting to load.

(4) Have you already confirmed that the bladeRF is working on a host machine? This will help us rule out some version mismatch issues:
(a) What FX3 firmware version are you using?
(b) What FPGA version are you using?
(c) Do you have an FPGA image stored in SPI flash? Is this what you intend to be doing, or will the Edison be loading the FPGA?

In that "Retry" loop, libbladeRF seems to think that the device is of a new enough of a firmware version such that it can poll the "loaded/unloaded" state of the FPGA. This is done so that the library can wait until the FPGA is loaded, if one is being loaded from SPI flash, rather than from the host. The big question here is, "why are we timing out?"
fumiko
Posts: 6
Joined: Sun Mar 22, 2015 11:15 pm

Re: Intel Edison and BladeRF

Post by fumiko »

Thank you for your reply. It works. (Several problems remains.)
bladerf_edison.jpg
(4) Your check list is very helpful.
It is because of no firmware loaded with DC supply and an USB3.0 cable.
I tried the follow methodology, and it works.

1. I tried to check firmware with bladeRF and universal PC, but bladeRF-cli on universal PC timed out.
2. I connected an USB3.0 cable from universal PC to bladeRF without an DC cable. (J70 pin = USB supply type)
3. After that, firmwares are loaded from universal PC.
4. I changed J70 to DC supply type.
5. Loading firmware once, Edison, bladeRF, USB3.0, and DC cable's connection works well.

------------
Other details for Edison and bladeRF are as follows.

- Edison does not have USB3.0 port physically. And an OTG cable is needed for connecting with bladeRF.
- Edison may not be able to supply power for bladeRF.
- A DC cable needed for bladeRF and voltage is 5V. RAPC712X is 2.5mm inner diameter and 5V.
- External power is needed for Edison and voltage is 7 - 15V. I use 9V for Edison.




But I have related problems yet. If you have more concern, I will try check and debugs.

1. No firmware is loaded with DC suppply.
2. "Rx overrun" occured with verbose mode and 1M samplerate
There is no Rx overrun message with universal PC. It may be Edison's performance limit..


Thanks,
Post Reply