[USRP-users] timout issue on RFNoC output

Jonathon Pendlum jonathon.pendlum at ettus.com
Mon Jul 24 13:57:41 EDT 2017

In the first screenshot you captured your block sending out a command
response packet. That is normal.

In the second screenshot, I couldn't see the full value of the header /
first word, so I cannot say if it had any issues.

Did you add an explicit enable for your block that turns it on after
initialization? It would also be a good idea to add a sr_write to turn off
the enable in your block's destructor code too.

On Mon, Jul 24, 2017 at 10:29 AM, Jason Matusiak <
jason at gardettoengineering.com> wrote:

> 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> 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/d7519b57/attachment-0002.html>

More information about the USRP-users mailing list