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 < ja...@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 < > 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
