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.

Parents Reply Children
  • 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.