AnsweredAssumed Answered

AD9361 / MCS : random timeout when refilling buffer

Question asked by jmk on May 18, 2018
Latest reply on May 23, 2018 by jmk



I'm using a custom Z7000 based platform with two AD9361, using a multichip synchronisation setup to acquire samples synchronously over 4 RX channels. Using Linux drivers.


I'm encountering an application bug, appearing randomly after a few acquisitions, but definitely each time.

My code :

- initialize the iio context

- configures ad9361, including the MCS sequence

- enables 4 channels

- creates the buffer

- refill the iio buffer a number of times

- disables all channels

- destroy the buffer

- destroy the context



This code "usually" (see below) works fine, and samples are acquired correctly (and synchronously as I expect).


But, after running the program a few times, the first refill call done after channel enabling returns with an error, that I tracked down in libiio code to : libiio/local.c at master · analogdevicesinc/libiio · GitHub 

After this has happened, there is nothing more I can do except rebooting. Calling the program again and again always gives the exact same error. Rebooting fixes the issue temporarily, but things go wrong the same way after a few acquisitions.


The number of acquisitions after a reboot before the error reappears is random, but low. This can be 1 or 2, sometimes I can do up to 10 runs, but not more.


When the program runs ok, I can refill indefinitely. It is when stopping the program and launching it again that the bug appears. When it appears it is always at the very first iio_refill call following the buffer creation.


As to my user code:

- I am quite sure I de-initialize things correctly in the right order (always properly destroying the iio buffers & iio context) when exiting the acquisition program.

- I can reproduce this issue with very different source code : my C/C++ code, but also using the iio python bindings


I've only seen this issue with a MCS-enabled bitstream. Previously I was using a non-MCS bitstream and did not encounter such issue.


Does this ring any bell ?

I'd be happy to try to track down the bug deeper in the driver code, but I would need a little help as to where to look.

Any idea that could help track down this nasty bug would be very welcome !


Thanks in advance