[USRP-users] timout issue on RFNoC output

Jason Matusiak jason at gardettoengineering.com
Mon Jul 24 13:29:23 EDT 2017


One last piece of oddball info I've discovered.

RFNoC:dataGenerator -> RFNoC:FIFO -> throttle -> QT GUI Time Sink

1 - If I program the X310 and run it, I get timeouts streaming 
immediately and nothing shows up on the timesink.  If I then stop it and 
run it again, I get some data through, and then the timeout stream.  If 
I run it a third time, I get:
RuntimeError: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no 
response packet - AssertionError: bool(buff)
   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
   at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:197

2 - If I remove the throttle (leave everything else the same), I get 
different results.  The first time through is the same, immediate stream 
of timeouts.  The second time I run it I get one "overrun on chan 0 D", 
but then the data streams through successfully.  If I run it a third 
time, I get the Block ctrl errors again.

3 - a fresh download of the image and then a uhd_usrp_probe returns a:
[ERROR] [UHD] Exception caught in safe-call.
   in virtual ctrl_iface_impl::~ctrl_iface_impl()
   at /home/jmat/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl 
(CE_00_Port_30) packet parse error - EnvironmentError: IOError: Expected 
SID: 02:30>00:00  Received SID: 02:60>00:00

And then running my flowgraph after getting that error only give me the 
error.

I cannot for the life of me figure out why removing the throttle helps, 
and what is special about running it the second time.  Also, why will it 
"run" on a fresh boot, but when I probe it first it gets into a weird state?


On 07/24/2017 12:32 PM, Jason Matusiak wrote:
> OK, in my original email I said that nothing was coming out of o_tdata 
> at the top level, but for some reason I see it working now.  That 
> said, I am still not seeing anything come out of the block even though 
> the o_tdata seems to be working.
>
> I attached a screenshot of what the data looks like in the middle of 
> running.  I see the data go valid, then it waits on o_tready to go 
> high, then data streams out until o_tlast goes high.  That all seems 
> legitimate to me, but when I put that output of the block through a 
> throttle and then a file sink, there is no data (which is probably why 
> I see the timeouts streaming across the debug screen).
>
> Any thoughts?
>
>
> On 07/24/2017 08:08 AM, Jason Matusiak wrote:
>> OK, attached is a screenshot of what you wanted.  i triggered on when 
>> o_tvalid when high and monitored o_tdata, o_tlast, o_tready, and 
>> o_tvalid.  I need to look at a working block, but I am surprised to 
>> see o_tlast go high so quickly..
>>
>> I would love to hear what you think is going on because I am stuck on 
>> this and have been for a few days.
>>
>> On 07/21/2017 04:00 PM, Jonathon Pendlum wrote:
>>> Yep
>>>
>>> On Fri, Jul 21, 2017 at 11:54 AM, Jason Matusiak 
>>> <jason at gardettoengineering.com 
>>> <mailto:jason at gardettoengineering.com>> wrote:
>>>
>>>     I need to re-setup my debug messages to check.  To be clear, you
>>>     are talking about the o_tdata (etc) up in my upper level
>>>     noc_block_dataGenerator, right?
>>>
>>>
>>>
>>>     On 07/21/2017 02:52 PM, Jonathon Pendlum wrote:
>>>
>>>         Here is what should happen on the axi stream bus to the
>>>         crossbar. You should first see the header on o_tdata with
>>>         o_tvalid asserted. After a few clock cycles, depending on
>>>         how long arbitration takes, you should see o_tready assert.
>>>         Are you seeing that sequence?
>>>
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170724/d4c51ce2/attachment-0002.html>


More information about the USRP-users mailing list