NULL pointer passed to sync_rx issue

[AurelienS]

Hello everyone,

I am using the great BladeRF x115 with OpenAirInterface (https://gitlab.eurecom.fr/oai/openairin ... wikis/home), a software to implement LTE networks in SDR.

Before I post this topic, I already have overrun issues with it, but resolved them by decreasing the bandwith (5 MHz to 1.4 MHz).

But now, when I am running the software part responsible of the radio frontend, I get these errors :

Code: Select all

[DEBUG @ sync.c:292] NULL pointer passed to sync_rx
RX failed: Invalid operation or parameter

Can someone explain me what can be the cause ? And, if possible, can someone help me to resolve this issue ?

Here is some informations about my setup, hope it will be sufficient :

- The host : a old (~4 years old) computer (Lenovo X230 tablet) with 4 (real) cores Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, running Ubuntu 14.04.4 LTS with a low-latency 3.19 (x86_64) kernel. The USB contoller is an Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]), and according to my researches is not blacklisted.

- The BladeRF hardware version and configuration :

Code: Select all

bladeRF> info

  Serial #:                 4f4e1acb5e1e45ab348665752172cc1f
  VCTCXO DAC calibration:   0x9261
  FPGA size:                115 KLE
  FPGA loaded:              yes
  USB bus:                  2
  USB address:              2
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0

bladeRF> version

  bladeRF-cli version:        1.4.0-git-d7b7eb3
  libbladeRF version:         1.7.1-git-d7b7eb3

  Firmware version:           1.9.0
  FPGA version:               0.5.0

The firmware and FPGA are updated by OAI build script using the bladerf ppa.

I use the following configuration for LTE :

Code: Select all

                 downlink_frequency      			      = 2680000000L; // L is ok but I don't know why
                           uplink_frequency_offset 			      = -120000000;
                           N_RB_DL                 			      = 6; // bandwith : 1.4 MHz
                           nb_antennas_tx          			      = 1;
                           nb_antennas_rx          			      = 1; 
			   tx_gain                                                = 60;
			   rx_gain                                                = 120;

- Complete setup : two antennas (they look like a fir or a pine, sorry I don't know a lot about antennas) with a range from 900 MHz to 2600 MHz we can find here (https://www.ettus.com/product/details/LP0965) plugged in the RX and TX port, the bladeRF is connected to the host by a USB 3 cable in a SuperSpeed port (verified using lsusb and the bladerf-cli). Note : the bladeRF is not powered by external power supply (does it need that ?)


I remain at your disposal for other informations,
Thank you a lot,

Aurélien Surier <[email protected]>

[jynik]

The code that prints that NULL pointer message may be found here.

This implies to me that the code calling bladerf_sync_rx is passing a NULL buffer or has called bladerf_sync_config before attempting to start calling the RX function.

Try setting a break point in the line of code I linked, and getting a backtrace of the calling code. Which item in that check is NULL, and why is this the case. This smells like it might be a bug in the code you're using...

Also, I"m pretty surprised that an XHCI wasn't keeping up with 5 MSPS... that's pretty bad, considering your specs. I wonder if the buffer configuration (size and count) and number of USB transfers being used are inadequate...

[AurelienS]

Hello jinyk,

Thank you for your fast reply.

I think it's more the code callling bladerf_sync_rx passing NULL buffer as you said (I take a look at the code, and found that bladerf_sync_config is called earlier).

I'm about to do a backtrace (but I think It will take some time). Moreover, I will talk about that to OAI developers.

Also, thank you to have confirmed that the USB configuration seems inadequate.

Have a nice day,
Best Regards

[jynik]

Also, thank you to have confirmed that the USB configuration seems inadequate.

Please bear in mind that I'm not saying it definitely is, but rather that's just my guess given the symptoms you've described, and my experience with too few/shallow buffers.

In terms of samplerate, # buffers, # samples per buffer, and # transfers to use -- I would need to see a some sorts of timing diagrams and requirements to get a sense of what is desired and compare that with how the device is configured.