Post Go back to editing

iio_device_create_buffer in adrv9002


We have a problem in our system where we run an elf file that reads a file with samples and transmits it (through an ip core).

We checked in spectrum analyzer for the rf output and we see it as expected, although the system is not stabilized:

In some elfs the transmittion is as expected and in some we strange results in the spectrum. However per elf run, the transmittion remains the same (a good one will stay good and a bad one will stay bad), but it seems there is no logic to guess which run it will be.

After a lot of work we have managed to find that the problem occures when we use the function iio_device_create_buffer. The test was as followed: we run the elf (started transmitting) and every few seconds we just destroy the buffer (using iio_buffer_destroy) and recreate it. In this scenario we see that it splits between good and bad outputs.

We have continued by trying to read the location in memory where the buffer is allocated (iio_buffer_first) and it stays constant at 0xb62ac000, (however if I kill the process and wait a few minutes, it will change).

Any idea how we can continue finding the root of the problem?

Thanks a lot.


We should also mention that we have an ad9361 board where the transmittion is always successful for the same (besides using other devices) elf, and this problem occues only in the adrv9002 board.

  • Hi,

    Make sure you are not using invalid (outdated) pointers after the call to iio_buffer_destroy().

    Does that happen when running on the target board? Or remotely on a PC?



  • Hey Paul,

    This happens when we run the code on the target board.

    In addition, I have checked and the pointers should be valid since we only release pointers before the process dies, so all of them are "usable" at the lines where we release them. Also we tried to follow that from the example from the git repository.

    How does the iio_device_create_buffer function work behind the scenes? 

    Thanks a lot


  • Hi Darroz,

    You should release all pointers obtained from the iio_buffer (e.g. obtained with iio_buffer_first) before calling iio_buffer_destroy(), that's what I meant.

    The iio_device_create_buffer function is here:

    libiio/buffer.c at master · analogdevicesinc/libiio (

    If you can, try to make a tiny example program that shows the problem, then we can run it on our side to see if we can reproduce your issue.


  • Hey Paul,

    Thanks a lot. It is problematic for us to send a reference design of what we do, so I will try to explain what we do in a nutshell:

    In the ps, we split the channels in tdma, so each sample belongs to a different channel. Maybe tdma it is more sensible and it can cause problems if the data that the fpga recieved is delayed or something similiar.

    Is there a default reference design that expects tdma input that you can send us and we will make an example from it / check if the problem exists in it.

  • The default reference designs in master have a specialized TDD core already:


  • Hello Travis, I think that I might need to emphasize some points:

    1.the same logic on the PL was made on a ad9361 custom board and we didn't encountered such a problem in this custom board (we used the ADI RF SOM evaluation board)   

    2.between the adrv9001 and the ad9361 in terms of PL and IPCORE the following is happening:

         2.1. the user IP we created via mathworks HDL WORK FLOW ADVISOR that we used on the ADI RF SOM is the same user IP used in our custom board of the adrv9001 (point to mention that the tdma logic which works perfectly on the ad9361 is in the mentioned user IP CORE)

        2.2. the only difference between the two reference designs for each board is only the axi_ad**** IP CORES of each board (axi_ad9361 in compare to the axi_adrv9001) and the fact that we have 2 paths for rx and tx (meaning we have double upack and cpack cores for each channel)

    with the mentioned above we don't believe that is required to add  ADI AXI TDD CONTROLLER IP core . after all the IP user logic that we create with matlab doesn't have differences in terms of performance and logic if we move it to different kind of boards.

    Therefore we would like to have a different path to the solution because it don't seems that the problem is there 

    NOTE- please note that we checked several times with the ILA the flow of data in the PL and the data flow as we planned so it can't be a problem in terms of IP CORES but something else entirely.

    with best regards.