[USRP-users] timout issue on RFNoC output
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)
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()
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
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:
>>> 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...
More information about the USRP-users