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
<ja...@gardettoengineering.com
<mailto:ja...@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?
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
