Booting issue

[Abhilash B]

We have an issue with BladeRF x115

After powering ON, except the power LED, none of the other LEDs on the board glow. After repeated boot attempts, we see the LEDs turned on and able to use it.
Because of this behavior, we are not able to use the board and lot of time is being spent on rebooting.

Any help will be highly appreciated. Happy to provide further information that can help in resolving the issue.


-regards
Abhilash

[rtucker]

Greetings!

Those LEDs are controlled from the FPGA, so if they aren't illuminated, this suggests that the FPGA is not being loaded.

If you could, try the following command and let us know what it says:

Code: Select all

bladeRF-cli -v debug -e 'version'

Also, if you can describe a bit more about your application, that may help figure out why the FPGA is not being loaded.

Thanks! -rt

[Abhilash B]

Hello rtucker,

As per your suggestion, below is the terminal output I got by using the command "bladeRF-cli -v debug -e 'version' "

$ bladeRF-cli -v debug -e 'version'

bladeRF-cli version: 1.5.0-git-2ce14de
libbladeRF version: 1.8.0-git-2ce14de

Firmware version: 2.0.0
FPGA version: Unknown (FPGA not loaded)

[DEBUG @ trigger.c:62] FPGA v does not support synchronization triggers.
[DEBUG @ trigger.c:62] FPGA v does not support synchronization triggers.


I am using the bladeRF to transmit/receive a single tone/sinusoid with proper modulation/demodulation using GNU radio companion. I have tried earlier and it worked fine. But suddenly those LEDs stopped glowing and I am not able to use it since GNU radio is throwing an error.

[rtucker]

Okay, it looks like it's not finding an FPGA bitstream to load. If you do "bladeRF-cli -l /path/to/hostedx115.rbf" it should start working until the next time it loses power. (You can download one from https://nuand.com/fpga.php)

To make this automatic, there's three approaches:

- Put the hostedx115.rbf in one of the places libbladeRF looks (see https://github.com/Nuand/bladeRF/wiki/F ... nux_or_OSX for the list)
- Add "fpga=/path/to/hostedx115.rbf" to the Device Arguments of the osmocom sink/source in gnuradio
- Flash the FPGA bitstream onto the bladeRF itself (see https://github.com/Nuand/bladeRF/wiki/F ... mwarebased for details and caveats)

I recommend the first approach; I keep my FPGA bitstreams in ~/.config/Nuand/bladeRF and it works out okay.

[Abhilash B]

Hello Rey Tucker,

Below is the output dump after invoking the following command.
bladeRF-cli -l ./hostedx40-latest.rbf

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

[VERBOSE @ "...//bladeRF-master/host/libraries/libbladeRF/src/backend/usb/libusb.c":593] Using libusb version: 1.0.17.10830
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/libusb.c":470] Found a bladeRF (idx=8)
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/libusb.c":532] USB port reset succeeded for bladeRF 29f11395e1259dd4e5d35cd60752a1d9
[VERBOSE @ "...//bladeRF-master/host/libraries/libbladeRF/src/capabilities.c":45] Capability mask before FPGA load: 0x0000000700000000
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 0
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 2
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 3
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 2
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 3
Loading fpga...
[VERBOSE @ "...//bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 3
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 1
[DEBUG @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/nios_legacy_access.c":123] Failed to receive NIOS II response: Operation timed out
[DEBUG @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/nios_legacy_access.c":213] Failed to read FPGA version[0]: Operation timed out
Error: failed to load FPGA: Operation timed out
[DEBUG @ ".../bladeRF-master/host/libraries/libbladeRF/src/trigger.c":62] FPGA v(null) does not support synchronization triggers.
[DEBUG @ ".../bladeRF-master/host/libraries/libbladeRF/src/trigger.c":62] FPGA v(null) does not support synchronization triggers.

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

Does the above information useful in debugging the problem ?

[rtucker]

That's very interesting... if you're indeed using an x115, trying to load the hostedx40 image should throw errors like this:

Code: Select all

$ bladeRF-cli -v verbose -l hostedx115.rbf  # note: I'm testing with an x40
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/backend/usb/libusb.c":593] Using libusb version: 1.0.22.11312
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/backend/usb/libusb.c":470] Found a bladeRF (idx=1)
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/capabilities.c":45] Capability mask before FPGA load: 0x0000000700000000
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 0
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 2
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 3
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 2
[VERBOSE @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 3
Loading fpga...
[WARNING @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/fpga.c":116] Detected potentially incorrect FPGA file.
[DEBUG @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/fpga.c":119] If you are certain this file is valid, you may define
BLADERF_SKIP_FPGA_SIZE_CHECK in your environment to skip this check.

Error: failed to load FPGA: Invalid operation or parameter
[DEBUG @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/trigger.c":62] FPGA v does not support synchronization triggers.
[DEBUG @ "/Users/rtucker/dev/Nuand/bladeRF/host/libraries/libbladeRF/src/trigger.c":62] FPGA v does not support synchronization triggers.

What does "bladeRF-cli -e info" report?

[Abhilash B]

Hi,
The output of the terminal for bladeRF info command is below.

$ bladeRF-cli -e info


Serial #: 29f11395e1259dd4e5d35cd60752a1d9
VCTCXO DAC calibration: 0x8e80
FPGA size: 40 KLE
FPGA loaded: no
USB bus: 2
USB address: 8
USB speed: Hi-Speed
Backend: libusb
Instance: 0

****************************************************************************************
We are loading x40 image on to x40 FPGA board.
I noticed following statements different in comparison to your output. Please note that "USB alt setting" changing back to "1" in my case.
Does that suggest anything?



Loading fpga...
[VERBOSE @ "...//bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 3
[VERBOSE @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/usb.c":112] Changing to USB alt setting 1
[DEBUG @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/nios_legacy_access.c":123] Failed to receive NIOS II response: Operation timed out
[DEBUG @ ".../bladeRF-master/host/libraries/libbladeRF/src/backend/usb/nios_legacy_access.c":213] Failed to read FPGA version[0]: Operation timed out


-regards

[bglod]

Earlier you mentioned this board was an x115, was that in error? If you look at the FPGA itself, there is a product code that begins with EP4CE followed by 2 or 3 digits. If it says "EP4CE40" then it's an x40; if it says "EP4CE115" it is an x115. What do they read?

[Abhilash B]

Hi,

We have both the boards.
And both are having the same issue.

-Regards

[rtucker]

Okay, that makes sense

What OS are you running? If Linux, what shows up in 'dmesg' or 'journalctl -f' when you attach the bladeRF and then start bladeRF-cli? Is it possible to try with a different USB controller (if your host PC has multiple ones available) or a different host PC?