Hi Michael, I thought about your issue when you posted it originally and again when you reposted, but I don't really have a good feel for what's going on. From your last email, you mentioned the "D" message which means that UHD detected that consecutive receive packets do not have consecutive sequence numbers. And, the timeout, of course, means that no packets are arriving.
For the "D" message, this can sometimes occur for very fast data rates where the host PC gets overwhelmed such that packets get dropped. In this case, nothing is wrong on the FPGA, but the PC might be able to be optimized to avoid this. Otherwise, perhaps it is happening on the FPGA. Are you able to test your block in isolation with a graph such as tx_streamer => custom_block => rx_streamer? I don't use gnuradio so when I test this way it is with a c++ custom application. And, I seem to recall that in gnuradio for UHD 3.15, there is some restriction that you have to have at least 2 rfnoc blocks (such as a FIFO). I don't think this restriction applies for UHD 4.0. Rob On Thu, Apr 15, 2021 at 2:00 PM Rich, Michael via USRP-users < usrp-users@lists.ettus.com> wrote: > Has anyone had any ideas on how to address this issue? > > > > I’m not sure if my issue is the same as Paolo is seeing or not, but after > debugging some more, I did have an additional question I was hoping someone > could help me with. As I mentioned, the data stream I’m sending to the > AXI_Wrapper seems to work for a while, but at some point I start getting > the following error in GNU Radio: > > > > overrun on chan 0 > > D > > > > That persists for a while, then I get the error: > > > > timeout on chan 0 > > > > Once I get that timeout, data_tready from AXI_Wrapper is stuck low, and I > have to power-cycle or reprogram the FGPA to recover. > > > > Does anyone know what exactly would cause these error messages, and what > that means within the context of the FGPA datapath? > > > > Any assistance or insights would be greatly appreciated. > > > > Thank you, > > > > *Michael H. Rich* > > *Electronic Systems Laboratory* > > *Georgia Tech Research Institute®* > > Phone: (404) 407-8358 > > E-mail: michael.r...@gtri.gatech.edu > > > > *From:* Paolo Palana <p.pal...@itsystems.it> > *Sent:* Tuesday, April 13, 2021 3:06 AM > *To:* usrp-users@lists.ettus.com > *Subject:* [USRP-users] Re: AXI Stream Issue > > > > Cheers to all the mailing list. > > I have similar problem too (the device is an X310 with TwinRx, UHD-3.15 on > ubuntu 20.04). My NoC Block too has 2 input and 2 output at a different > data rate. The start streaming goes smootly and it seems to work for a > while, but when I stop the streaming (during my tests I streamed for a very > short time, say 10 secs) I had the following error from UHD. > > [ERROR] [UHD] Exception caught in safe-call. in > ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t > _endianness = uhd::ENDIANNESS_BIG] at ~/host/lib/rfnoc/ctrl_iface.cpp:50 > this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl > (CE_03_Port_61) no response packet - AssertionError: bool(buff) in uint64_t > ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with > uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long > unsigned int] at ~/host/lib/rfnoc/ctrl_iface.cpp:151 > > It seems too me that the internal FPGA bus for some reason is stuck. In > fact when I see the signals with ILA after the stop streaming I can see > that the i_tready signal for the second input in my Noc Block is low, while > the the i_tvalid is high. > > In my implementation I'm not using the axi_wrapper, but directly the > chdr_deframer_2clk and chdr_framer_2clk. > > I'm pretty shure that the logic of my NoC Block is (almost) correct > because I have the same one running with UHD-3.10.3 without any problem. > > Up to now I'm unable to pinpoint the problem, What can be the problem? Any > suggestion > > Thank you for your attention > > Paolo > > > > *From:* Rich, Michael via USRP-users <usrp-users@lists.ettus.com> > *Sent:* Monday, April 12, 2021 2:54 PM > *To:* usrp-users@lists.ettus.com > *Subject:* [USRP-users] AXI Stream Issue > > > > I am having issues getting data out of a custom block NoC Block (on an > X310 using UHD3.15) and I’m not quite sure what would be causing what I’m > seeing. When everything starts up, it seems to work just fine for a bit, > but then output stops. Checking the data bus using an ILA, it appears as > though data_tready from the AXI_Wrapper goes low at some point and just > stays there. > > > > My output is at a different rate than the input, so I’ve set SIMPLE_MODE=0 > for AXI_WRAPPER. I’m fairly sure I’m driving the AMBA bus properly. I’m > setting s_axis_data_tuser as follows: > > Bit 127-126 = 00 (data) > > Bit 125 = 0 (timestamp not used) > > Bit 124 = 0 or 1 (depending upon if end-of-burst or not) > > Bit 123-112 = sequence number (monotonically increasing for each packet > starting at 0) > > Bit 111-96 = packet length (total number of data bytes + 8 header bytes) > > Bit 95-80 = src_sid (from noc_shell) > > Bit 79-64 = next_dst_sid (from noc_shell) > > Bit 63-0 = 0 > > > > What might cause data_tready to remain low? Is there anything else I > should be looking at that might explain this behavior? > > > Thank you, > > > > *Michael H. Rich* > > *Electronic Systems Laboratory* > > *Georgia Tech Research Institute®* > > Phone: (404) 407-8358 > > E-mail: michael.r...@gtri.gatech.edu > > > > > > > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
