Official bladeRF forum

jynik wrote: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.

[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

jynik wrote: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.

jynik wrote: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?

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

[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

jynik wrote: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.

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

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

jynik wrote:

j0henz wrote: 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?