usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Possible Bug in E310 usrp_sink

PW
Peter Witkowski
Tue, Mar 8, 2016 11:45 PM

Hello,

I have an E310 that is running a simple GNU Radio Companion flow graph.
The flow graph just connects a file_source to a usrp_sink and configures
the USRP with various parameters such as sample rate, center frequency, etc.

Everything works, unless I try to stop the flow graph and then restart.
That is, I call start() on my generated top block, then stop()/wait() and
then start() again.  Specifically, the following error gets printed:

thread[thread-per-block[1]: <block gr uhd usrp sink (1)>]: AssertionError: _
send_entries_in_use.at(which_stream) <= H2S_NUM_CMDS
in uhd::transport::zero_copy_if::sptr
e300_fifo_interface_impl::_make_xport(size_t, const
uhd::transport::zero_copy_xport_params&, bool)
at
/home/balister/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.8.4.1-r0/uhd-3.8.4/lib/usrp/e300/e300_fifo_config.cpp:395

Note that I am running the factory microSD card that came with the SDR.
The UHD version is 3.8.4.  I haven't yet tried upgrading to a newer
version, but that's my next step.

Any help would be great.  Note that my current workaround is to call "del"
on the top block after I'm done with it.  If I then make a new top block,
the problem goes away (I can call start() on the new object).  This leads
me to believe that some clean-up routine is not being called when stop() is
being called.

Thanks in advance for the help.

--
Peter Witkowski
pwitkowski@gmail.com

Hello, I have an E310 that is running a simple GNU Radio Companion flow graph. The flow graph just connects a file_source to a usrp_sink and configures the USRP with various parameters such as sample rate, center frequency, etc. Everything works, unless I try to stop the flow graph and then restart. That is, I call start() on my generated top block, then stop()/wait() and then start() again. Specifically, the following error gets printed: thread[thread-per-block[1]: <block gr uhd usrp sink (1)>]: AssertionError: _ send_entries_in_use.at(which_stream) <= H2S_NUM_CMDS in uhd::transport::zero_copy_if::sptr e300_fifo_interface_impl::_make_xport(size_t, const uhd::transport::zero_copy_xport_params&, bool) at /home/balister/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.8.4.1-r0/uhd-3.8.4/lib/usrp/e300/e300_fifo_config.cpp:395 Note that I am running the factory microSD card that came with the SDR. The UHD version is 3.8.4. I haven't yet tried upgrading to a newer version, but that's my next step. Any help would be great. Note that my current workaround is to call "del" on the top block after I'm done with it. If I then make a new top block, the problem goes away (I can call start() on the new object). This leads me to believe that some clean-up routine is not being called when stop() is being called. Thanks in advance for the help. -- Peter Witkowski pwitkowski@gmail.com
MD
Marcus D. Leech
Tue, Mar 8, 2016 11:54 PM

On 03/08/2016 06:45 PM, Peter Witkowski via USRP-users wrote:

Hello,

I have an E310 that is running a simple GNU Radio Companion flow
graph.  The flow graph just connects a file_source to a usrp_sink and
configures the USRP with various parameters such as sample rate,
center frequency, etc.

Everything works, unless I try to stop the flow graph and then
restart.  That is, I call start() on my generated top block, then
stop()/wait() and then start() again. Specifically, the following
error gets printed:

thread[thread-per-block[1]: <block gr uhd usrp sink (1)>]:
AssertionError: _send_entries_in_use.at
http://send_entries_in_use.at(which_stream) <= H2S_NUM_CMDS
in uhd::transport::zero_copy_if::sptr
e300_fifo_interface_impl::_make_xport(size_t, const
uhd::transport::zero_copy_xport_params&, bool)
at
/home/balister/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.8.4.1-r0/uhd-3.8.4/lib/usrp/e300/e300_fifo_config.cpp:395

Note that I am running the factory microSD card that came with the
SDR.  The UHD version is 3.8.4.  I haven't yet tried upgrading to a
newer version, but that's my next step.

Any help would be great.  Note that my current workaround is to call
"del" on the top block after I'm done with it.  If I then make a new
top block, the problem goes away (I can call start() on the new
object).  This leads me to believe that some clean-up routine is not
being called when stop() is being called.

Thanks in advance for the help.

I'd strongly recommend upgrading to the latest image:

http://files.ettus.com/e3xx_images/e3xx-release-4/

On 03/08/2016 06:45 PM, Peter Witkowski via USRP-users wrote: > Hello, > > I have an E310 that is running a simple GNU Radio Companion flow > graph. The flow graph just connects a file_source to a usrp_sink and > configures the USRP with various parameters such as sample rate, > center frequency, etc. > > Everything works, unless I try to stop the flow graph and then > restart. That is, I call start() on my generated top block, then > stop()/wait() and then start() again. Specifically, the following > error gets printed: > > thread[thread-per-block[1]: <block gr uhd usrp sink (1)>]: > AssertionError: _send_entries_in_use.at > <http://send_entries_in_use.at>(which_stream) <= H2S_NUM_CMDS > in uhd::transport::zero_copy_if::sptr > e300_fifo_interface_impl::_make_xport(size_t, const > uhd::transport::zero_copy_xport_params&, bool) > at > /home/balister/e300-oe-build/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.8.4.1-r0/uhd-3.8.4/lib/usrp/e300/e300_fifo_config.cpp:395 > > Note that I am running the factory microSD card that came with the > SDR. The UHD version is 3.8.4. I haven't yet tried upgrading to a > newer version, but that's my next step. > > Any help would be great. Note that my current workaround is to call > "del" on the top block after I'm done with it. If I then make a new > top block, the problem goes away (I can call start() on the new > object). This leads me to believe that some clean-up routine is not > being called when stop() is being called. > > Thanks in advance for the help. > I'd strongly recommend upgrading to the latest image: http://files.ettus.com/e3xx_images/e3xx-release-4/