Official bladeRF forum

I was trying to get bladeRF to work with the osmocom source block in gnuradio-companion, however something seems to have gone wrong and now whenever I attempt to flash the FX3 image i get a very generic error:
bladeRF> load fx3 bladeRF.img
Flashing firmware...

Error: An unexpected error occurred

Preceding this, I had put the following into the osmocom source block under the "device arguments" section:
bladerf=2,fpga='/apps/bladeRF/hdl/quartus/hostedx40.rbf',fw='/apps/bladeRF/fx3_firmware/bladeRF.img'

Then I executed the flow graph and it started loading the FPGA and FX3 images, then failed on the FX3 image with error -1 (I believe), and then my inability to load the firmware via any method appeared.

I can still load the FPGA image, and the bladerf-cli program still sees the device and returns:
bladeRF> probe

Path: /dev/bladerf2
Serial: 0x0000000000000000
Firmware: v0.3
FPGA: v0.0

Any help to fix this would be much appreciated. Thanks.

EDIT:
So, this is the error it currently gives when I run in gnuradio companion, although I can't guarantee this is the error I saw when it failed the first time and it started erroring on the firmware load:

gr-osmosdr v0.1.0-6-g93ad959d (0.1.1git) gnuradio v3.7.0-76-g752fe88b
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
Loading FPGA bitstream /apps/bladeRF/hdl/quartus/hostedx40.rbf...
The FPGA bitstream has been successfully loaded.
Flashing firmware image /apps/bladeRF/fx3_firmware/bladeRF.img..., DO NOT INTERRUPT!
bladerf_flash_firmware has failed with -1
Using nuand LLC bladeRF #2 SN 0000000000000000 FW v0.3 FPGA v0.0
Failed to read samples: File or device I/O failure

Are you connected via HS or SS on the USB side of things?

dmesg should tell you. Also it's interesting you have /dev/bladerf2 instead of /dev/bladerf0. If you don't mind me asking, what kernel are you running?

I've plugged into a USB3.0 port on my computer, but according to dmesg and lsusb the bladeRF is not running at SS and is connected to a USB2 bus...which seems odd.

Kernel: Linux grubuntu 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Also, having left it overnight, and then moved around the USB cable to various ports to figure out which one is actually a 3.0 port, I can suddenly flash the FX3 firmware again. So, I guess that problem is sort of solved, although it would be nice to know why it happened in the first place.

There was an issue where HS was setup in the FX3 to handle transfers of 512 bytes whereas SS was 1024 bytes. When programming the FX3, this wouldn't be taken into account and some of the data was lost due to the transfer size being bad.

I thought it was all fixed up in the repository, but I'll keep my eye on it and do some HS testing.

Ah, I have discovered my problem with getting it to connect at SS. I rebooted and didn't reload the bladerf.ko module.

Ah, yes - that will do it.

We're actively working on libusb support. Hopefully by mid-week we'll be able to do everything you can do with the kernel, but with libusb instead.