bladeRF-cli: Failed to open device Operation timed out [SOLV

[j0henz]

I recently (4 hours ago) updated bladeRF-cli and bladeRF-flash to the latest version (0.11.0-git-40399b0 and 0.4.2-git-40399b0) and then bladeRF-cli said that I had to update the firmware.

I tried doing this under OS X using the bootloader approach, and when I ran open after running recover it said "operation timed out".

I the tried updating the firmware using the Cypress Control Center in Windows, which eventually worked.

Now when I plug it into my Macbook Air (USB 2.0) running OS X 10.9, the following happens:

If I check "USB" under "System report" it show:

Code: Select all

bladeRF:

  Product ID:	0x6066
  Vendor ID:	0x1d50
  Version:	 0.00
  Serial Number:	1b4e3b68de6d86d4016ff99df40aac53
  Speed:	Up to 480 Mb/sec
  Manufacturer:	Nuand
  Location ID:	0xfd110000 / 3
  Current Available (mA):	500
  Current Required (mA):	200

bladeRF-cli --probe gives:

Code: Select all

Backend:        libusb
Serial:         1b4e3b68de6d86d4016ff99df40aac53
USB Bus:        253
USB Address:    3

Running bladeRF-cli -i results in

Code: Select all

Failed to open device (first available): Operation timed out

and dmesg gives

Code: Select all

AppleUSBEHCI::Found a transaction past the completion deadline on bus 0xfd, timing out! (Addr: 3, EP: 2)

I'm using libusb-10.0.18 installed via macports.

Does anyone have any idea how to fix it?

I'm kind of certain it's not OS X, since I could talk to it using bladeRF-cli version 0.10.8, before updating to 0.11.

[jynik]

Could you post the results of:

Code: Select all

bladeRF-cli -i -v verbose

Hopefully that should help us see where in the process this timeout is occurring.

[j0henz]

Could you post the results of:

Code: Select all

bladeRF-cli -i -v verbose

Hopefully that should help us see where in the process this timeout is occurring.

Sure!
bladeRF-cli -v verbose -i:

Code: Select all

[VERBOSE] Using libusb version: 1.0.18.10866
[VERBOSE] Found a bladeRF (based upon VID/PID)
[VERBOSE] Changing to USB alt setting 0
[VERBOSE] Changing to USB alt setting 1
[DEBUG] Failed to read FPGA version[0]: Operation timed out
Failed to open device (first available): Operation timed out

Trying to load an FPGA results in the same thing.

[jynik]

Hmm...I'm not having an immediate "ah ha!" moment here, so I may have to mull this over and get back to you when I get home later tonight with any new ideas.

For the time being, here's just a grab bag of thoughts; maybe one of them will lead you somewhere useful...

• Just as a sanity check, are you running the latest and greatest FPGA image? There are dependencies between libbladeRF, the FPGA, and the FX3 firmware. libbladeRF is supposed to detect and complain about mismatches; perhaps one was missed..
• Do you have an FPGA being autoloaded from SPI flash? Be aware that the device currently enumerates before the FPGA autoload is finished (this will be changed soon), so you have to wait for the FPGA autoload to complete (LEDs will turn on) before attempting to run the CLI or "recover". If an incompatible FPGA is being auto-loaded, you'll have to back up to the old firmware, and do the 'bladeRF-cli -L X' from there. (For what it's worth, I prefer the newer software-autoload, which just requires that you place the FPGA in ~/.config/Nuand/bladeRF/hostedx[40|115].rbf.
• You mentioned using Windows -- do the same symptoms occur if you run the latest and greatest there?

[jynik]

Also, could you just list out the FX3 firmware and FPGA versions that you started with, and those you're now using and running into trouble with?

If you don't come to a quick solution, perhaps I could try to replicate the situation on an OSX box within the next couple days.

[j0henz]

Also, could you just list out the FX3 firmware and FPGA versions that you started with, and those you're now using and running into trouble with?

If you don't come to a quick solution, perhaps I could try to replicate the situation on an OSX box within the next couple days.

To my best recollection, these are the versions (for x40):
FPGA
Before: v0.0.3
After: v0.0.5

Firmware
Before: v1.6.1
After: v1.7.0

[j0henz]

Hmm...I'm not having an immediate "ah ha!" moment here, so I may have to mull this over and get back to you when I get home later tonight with any new ideas.

For the time being, here's just a grab bag of thoughts; maybe one of them will lead you somewhere useful...

• Just as a sanity check, are you running the latest and greatest FPGA image? There are dependencies between libbladeRF, the FPGA, and the FX3 firmware. libbladeRF is supposed to detect and complain about mismatches; perhaps one was missed..
• Do you have an FPGA being autoloaded from SPI flash? Be aware that the device currently enumerates before the FPGA autoload is finished (this will be changed soon), so you have to wait for the FPGA autoload to complete (LEDs will turn on) before attempting to run the CLI or "recover". If an incompatible FPGA is being auto-loaded, you'll have to back up to the old firmware, and do the 'bladeRF-cli -L X' from there. (For what it's worth, I prefer the newer software-autoload, which just requires that you place the FPGA in ~/.config/Nuand/bladeRF/hostedx[40|115].rbf.
• You mentioned using Windows -- do the same symptoms occur if you run the latest and greatest there?

When this problem began, I was using version 0.0.3 (the february version) of the FPGA and version 1.6.1 of the firmware (the reason I tried to update it was because the newest version of bladeRF-cli required it). After I ran recover XX YY /path/to/firmwarev1.7.0.img (on OSX, which completed successfully) I ran open and got this (tested now):

Code: Select all

bladerf-cli> open
[VERBOSE] Using libusb version: 1.0.18.10866
[VERBOSE] Found a bladeRF (based upon VID/PID)
[VERBOSE] Changing to USB alt setting 0
[VERBOSE] Changing to USB alt setting 2
[VERBOSE] Changing to USB alt setting 3
[DEBUG] Failed to change setting: An unexpected error occurred
[DEBUG] Failed to restore alt setting: An unexpected error occurred
[DEBUG] Unable to fetch DAC trim. Defaulting to 0x8000
[WARNING] Failed to get VCTCXO trim value: An unexpected error occurred
[VERBOSE] Changing to USB alt setting 2
[DEBUG] Failed to change setting: No devices available
[WARNING] Failed to get FPGA size No devices available
[DEBUG] lusb_control_transfer failed: status = -4
[DEBUG] lusb_control_transfer failed: status = -4
[ERROR] Failed to switch to NULL interface: No devices available
Error: No devices available

OS X also hanged while doing this, which may be a clue to something.

On Windows I can flash the firmware successfully by following this. Although, when I start bladeRF-cli (v 0.10.3, libbladerf version is 0.12.1) and run open, I get:

Code: Select all

[VERBOSE] Using libusb version: 1.0.16.10774
[VERBOSE] Non-bladeRF device found: VID 8086, PID 3b3c
[VERBOSE] Non-bladeRF device found: VID 8086, PID 3b34
[VERBOSE] Non-bladeRF device found: VID 0425, PID 0101
[VERBOSE] Non-bladeRF device found: VID 04b4, PID 4720
[VERBOSE] Non-bladeRF device found: VID 04f9, PID 0041
[VERBOSE] Non-bladeRF device found: VID 0518, PID 0001
[VERBOSE] Non-bladeRF device found: VID 093a, PID 2521
[VERBOSE] Non-bladeRF device found: VID 8087, PID 0020
[VERBOSE] Non-bladeRF device found: VID 8087, PID 0020
[DEBUG] No devices available on the libusb backend.
Error: No devices available

I installed everything on Windows using the Windows installer today, so that should be up to date. I use the latest firmware. I am not able to load the fpga, since I can't open the device.

I think I'll try to reinstall libusb on OS X and see if that makes a different.
I also realized that this post got longer than I first intended.

[jynik]

Update: Before going through the below...let me just rule out a very common mistake. After putting the device into bootloader mode, you are removing that jumper on J64 prior to attempting to run 'recover' and 'open', right?

Hmm...this feels like some sort of version mismatch situation, but the FPGA v0.0.3-v0.0.5 should be compatible with firmware 1.6.1 & 1.7.0. I wouldn't have expected the CLI to request a FW uprgade, given the versions you reported. Additionally, you should have been able to upgrade via the CLI normally, without using the bootloader.

So let's start back at the beginning... you got message telling you to upgrade. Some version compatibility tables and associated checks were recently introduced to help alleviate the version incompatibility hell, which would be responsible for the message you saw. Do you recall the exact message? Here's a list of the various version-related warnings -- perhaps you'll recognize the one you saw?

1. The detected firmware version requiring a newer FPGA
2. The detected FPGA version requiring a newer firmware
3. libbladeRF detecting a firmware it no longer supports (i.e., FW v1.5.3 and earlier.)
4. FW v1.7.0 being required to enable firmware loopback
5. XB-200 support requiring FPGA v0.0.5 or later.
6. Potentially very old firmware that doesn't support the request to query its version.
7. Old firmware the doesn't present a single interface with 4 alt-settings

Knowing this will likely set us in the right direction here...

Just to reiterate an earlier question -- you do not have an FPGA being autoloaded from SPI flash, correct? If so, I generally recommend disabling that prior to doing upgrades...just so there's one less thing in the mix when the firmware starts running.

Regarding the Windows side of things...
Perhaps we'll stick to the above stuff for debugging now, just to stay focused on one thing...but I just wanted to mention the below items:

Note that libbladeRF & bladeRF-cli version included in the Windows installer are rather old; I do not believe they're compatible with the current FX3 firmware and FPGA image. I'll ask the guy that builds those to see if he can get a new one up. In the upcoming weeks, I'll be looking to start doing windows installer builds, which I'll plan to post at more frequent intervals.

In the meantime, if you're in Windows... it'd probably be best to build from source if you're looking to use the latest and greatest FW + FPGA.

[j0henz]

Update: Before going through the below...let me just rule out a very common mistake. After putting the device into bootloader mode, you are removing that jumper on J64 prior to attempting to run 'recover' and 'open', right?

Hmm...this feels like some sort of version mismatch situation, but the FPGA v0.0.3-v0.0.5 should be compatible with firmware 1.6.1 & 1.7.0. I wouldn't have expected the CLI to request a FW uprgade, given the versions you reported. Additionally, you should have been able to upgrade via the CLI normally, without using the bootloader.

So let's start back at the beginning... you got message telling you to upgrade. Some version compatibility tables and associated checks were recently introduced to help alleviate the version incompatibility hell, which would be responsible for the message you saw. Do you recall the exact message? Here's a list of the various version-related warnings -- perhaps you'll recognize the one you saw?

1. The detected firmware version requiring a newer FPGA
2. The detected FPGA version requiring a newer firmware
3. libbladeRF detecting a firmware it no longer supports (i.e., FW v1.5.3 and earlier.)
4. FW v1.7.0 being required to enable firmware loopback
5. XB-200 support requiring FPGA v0.0.5 or later.
6. Potentially very old firmware that doesn't support the request to query its version.
7. Old firmware the doesn't present a single interface with 4 alt-settings

Knowing this will likely set us in the right direction here...

Just to reiterate an earlier question -- you do not have an FPGA being autoloaded from SPI flash, correct? If so, I generally recommend disabling that prior to doing upgrades...just so there's one less thing in the mix when the firmware starts running.

Regarding the Windows side of things...
Perhaps we'll stick to the above stuff for debugging now, just to stay focused on one thing...but I just wanted to mention the below items:

Note that libbladeRF & bladeRF-cli version included in the Windows installer are rather old; I do not believe they're compatible with the current FX3 firmware and FPGA image. I'll ask the guy that builds those to see if he can get a new one up. In the upcoming weeks, I'll be looking to start doing windows installer builds, which I'll plan to post at more frequent intervals.

In the meantime, if you're in Windows... it'd probably be best to build from source if you're looking to use the latest and greatest FW + FPGA.

I can't remember exactly, either this or this. I remember it mentioning the bootloader (since that was the reason that I tried to upgrade using the bootloader).

Regarding the autoloading. The thing is that prior to all this, I noticed that when I tried to get the FPGA to autoload (bladeRF-cli -L /path/to/fpga) it didn't seem to take, as it complained that there were no FPGA present when I tried to do things like set the frequency, although I could still load the fpga after each power cycle. So I don't think that it's autoloading.

And if I try to disable autoloading with bladeRF-cli -L X, i get the response

Code: Select all

Failed to open device (first available): Operation timed out

, which OS X confirms with

Code: Select all

AppleUSBEHCI::Found a transaction past the completion deadline on bus 0xfd, timing out! (Addr: 3, EP: 2)

from dmesg.

[jynik]

Regarding the autoloading. The thing is that prior to all this, I noticed that when I tried to get the FPGA to autoload (bladeRF-cli -L /path/to/fpga) it didn't seem to take, as it complained that there were no FPGA present when I tried to do things like set the frequency, although I could still load the fpga after each power cycle. So I don't think that it's autoloading.

The autoloading from SPI flash is quite slow (7ish seconds for the x40, and over twice that for the x115), and I've seen bizare stuff happen if you try to open a device handle prior to the autoload finishing. There's opportunities to speed the autoload up, as well as have the device not enumerate on the bus until the autoload is complete -- those just require someone to find/spend some time making these changes in firmware.

Do you think there's any chance that the device was trying to autoload, but you were attempting to start using it before it completed? Perhaps plug the device in and leave it for 30 seconds -- if the two LEDs come on, you know it autoloaded on you.

Regarding the messages -- either your firmware was a lot older than you thought, or something is very awry on the USB side of things. Your dmesg output seems to support the latter.

Last night I tried using your "before" configuraiton and upgrading to the "after" configuration on OSX Mavericks, but didn't see any issues. Perhaps we'll have to think about whether something else on your setup changed?

[j0henz]

Regarding the autoloading. The thing is that prior to all this, I noticed that when I tried to get the FPGA to autoload (bladeRF-cli -L /path/to/fpga) it didn't seem to take, as it complained that there were no FPGA present when I tried to do things like set the frequency, although I could still load the fpga after each power cycle. So I don't think that it's autoloading.

The autoloading from SPI flash is quite slow (7ish seconds for the x40, and over twice that for the x115), and I've seen bizare stuff happen if you try to open a device handle prior to the autoload finishing. There's opportunities to speed the autoload up, as well as have the device not enumerate on the bus until the autoload is complete -- those just require someone to find/spend some time making these changes in firmware.

Do you think there's any chance that the device was trying to autoload, but you were attempting to start using it before it completed? Perhaps plug the device in and leave it for 30 seconds -- if the two LEDs come on, you know it autoloaded on you.

Regarding the messages -- either your firmware was a lot older than you thought, or something is very awry on the USB side of things. Your dmesg output seems to support the latter.

Last night I tried using your "before" configuraiton and upgrading to the "after" configuration on OSX Mavericks, but didn't see any issues. Perhaps we'll have to think about whether something else on your setup changed?

Nothing changed between me using the bladeRF (i.e. setting frequency etc.) and me trying to upgrade the firmware besides installing the newest version of bladeRF-[cli|flash]. I think I'll try it in Linux, on a different computer, with a different cable, and try to reinstall libusb and see if something works.

[j0henz]

Today I tried playing around with it some more, and I noticed something quite odd. If I ran bladeRF-cli -i almost immediately after I plugged in the bladeRF, I was sometimes able to connect to and without problems, load an FPGA and e.g. set the frequency. I then tried to disable the FPGA autloading (bladeRF-cli -L X), and then re-enabled it again. That seems to have solved the problem. Thank you to jynik for all the help.

Here is the versions of things:

Code: Select all

bladeRF> version

  bladeRF-cli version:        0.11.0-git-f607510
  libbladeRF version:         0.16.1-git-f607510

  Firmware version:           1.7.0-git-ee89b79
  FPGA version:               0.0.5

[[email protected]]

Hello,

I am having similar problems after successfully updating the FX-3 using Cypress's SDK. Haven't yet tried to run bladeRF-cli before the FPGA loads... Always have waited until all LEDs are lit... I'm using the latest pre-built .img and .rbf. Any other ideas?

[jynik]

Just to quickly summarize the issue j0henz and a number of other people seem to have been running into...

The recurring problem I've seen is that folks upgrade a very old FX3 firmware and libbladeRF to a very recent one, but forget to disable FPGA autoloading prior to this.

The problem that ends up occuring with some very old FPGA versions is that the old FPGA didn't provide functionality (e.g., presenting their version number) that the newer libbladeRF versions need to correctly identify the available FPGA functionality.

For this reason, I personally highly discourage the use of the SPI flash-based FPGA autoloading if people are always going to use the bladeRF with a host machine. Instead, I recommend allowing the host machine to automatically load the FPGA when a device handle is opened.

------------------------------------------------------------------------

surfer20, could you provide the following information?

• What versions did you start at? Which versions did you upgrade to?
• You said you upgraded the FPGA (the .rbf). You also notesd that the three LEDs are turning on. This indicates to me that you must have run a "<bladeRF-cli -L <new rbf>". Is that correct? Otherwise, is it possible that you may have an old FPGA stuck in SPI flash?
• The contents of a log from bladeRF-cli -i -v verbose, preferably pasted here within the phpBB "code" tags.

Thanks,
Jon

[[email protected]]

A mismatch between bladeRF-cli and the .img or .rbf makes sense... Seems like the autoloading old code into FPGA is the likely source of the problem. I was negligent in disabling that (-L X).
I am unable to recall the old versions, and the windows 8 machine they were on has been upgraded...
The latest installer was used for the updates, with an additional image (.img) at v1.7.1.
Here is my bladerf-cli -v -verbose output.

C:\Program Files\bladeRF\x64>bladerf-cli -v verbose
[VERBOSE] Using libusb version: 1.0.19.10905
[VERBOSE] Found a bladeRF (based upon VID/PID)
[VERBOSE] Changing to USB alt setting 0
[VERBOSE] Changing to USB alt setting 1
[DEBUG] Failed to read FPGA version[0]: Operation timed out
Failed to open device (first available): Operation timed out

What do I do now? reflash an older .img and use an older bladerf-cli to disable the autoload? UGH! What version?

Thanks.