iio_device_create_buffer in adrv9002

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?

Cheers,

-Paul

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

Darroz

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 (github.com)

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.

-Paul

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 (github.com)

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.

-Paul

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: https://wiki.analog.com/resources/fpga/docs/axi_tdd

-Travis

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.