AnsweredAssumed Answered

code locks on call to iio_buffer_destroy(txbuf)

Question asked by wilsond on Feb 5, 2016
Latest reply on Mar 11, 2016 by wilsond

We're working to make use of a ZC706 board.

 

I'm working with the example code provided here:

libiio/ad9361-iiostream.c at master · analogdevicesinc/libiio · GitHub

 

The code compiles, and runs, It seems to be transmitting and receiving.

But when I do ctrl-c (like it says to do)

The code hangs on a call to iio_buffer_destroy(txbuf) during the cleanup function. (always the transmit buffer)

 

If I kill the process through the command line, and run the code again, receive buffers cannot be allocated (until I reset the board)

 

If I disable the SIGINT handling, and kill the process with ctrl-c, I can rerun just fine.  But I presume this doesn't clean up resources.

 

I tried adding a mutex thinking that perhaps the process needed to finish receiving, or transmitting before trying to clean up buffers.

This just resulted in a deadlock situation.

 

If instead of running an infinite loop, I just run a specified number of times, then call the cleanup function, the code exist without problem.

 

I feel like this may have something to do with the added network layer, but I don't have a good feel for what's going on in terms of how the buffer reading and writing works over the network.

 

-------

Some extra notes:

 

I made some modifications to the code:

 

first one being, I'm running the code over the network on the board which is at a different location.

Using a call to iio_create_network_context(ip-address) instead of the iio_create_default_context()

 

The Second modification

I changed the get device call from:

case RX: *dev = iio_context_find_device(ctx, "cf-ad9361-lpc");  return *dev != NULL;

to

case RX: *dev = iio_context_find_device(ctx, "cf-ad9361-A");  return *dev != NULL;

Because cf-ad9361-lpc doesn't appear to exist on the board.

Outcomes