Hi Jim, I have also been playing around with UHD-4.0, but mostly in testbenches. I've only built one image (for the N310) with one of my custom blocks. The errors you mentioned seem very strange. A few questions/comments: - can you send your "XXX_x310_rfnoc_image_core.yml" contents? - would it be helpful to run directly with UHD examples (removing gnuradio and gr-ettus from the equation)? You could try "rfnoc_rx_to_file" as-is where you specify on the command line the desired "block-id" to insert between the Radio and the rx_streamer. With the X310, the Radio rate might be too high with your custom "thru" block so perhaps you could modify the example (in-tree would be easiest) to automatically include the DDC and then insert the command line "block-id" optionally after the DDC. - In my testbenches, I have occasionally seend CHDR error messages like you mentioned and it seemed to solve them if I set "s_out_payload_tkeep=1". I didn't think this was needed if there was only 1 output port, but I seem to recall that this fixed my CHDR error issue for my 1 port block. Rob
On Wed, Sep 30, 2020 at 10:39 AM Jim Palladino via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > Several weeks ago I went through the tutorial for producing the example > "gain" block using rfnoc 3.8 and uhd 3.15. There were some bumps, but I did > get that working fine. For the past couple weeks, I've been working with > UHD 4.0 and the latest gr-ettus repo. > > I posted a question a week or two ago since I couldn't get UHD to > recognize my custom block, as UHD doesn't look for the block yml file in > the latest uhd 4.0 build. It just shows up as "0/Block#0" when probing. > Thanks to Wade F. for the quick response to that question and for > suggesting I either just continue OOT and use the "Block" name to interface > with it or build in-tree for now. I chose to stick with OOT and just use > the "Block" naming. > > I started with the gain example, but ended up simplifying it to literally > just using what was generated by rfnocmodtool (just a pass through block in > the FPGA) with no modifications. I made an rfnoc block, called "Block". I > built this for an E320, so I did have to modify the > "XXX_x310_rfnoc_image_core.yml" file accordingly. > > I built/installed everything, but this is what is happening. When I create > a gnuradio-companion "waveform", it does run, but I get the following > behavior: > > 1) If my setup is RFNoC_RX_Radio -> RFNoC_DDC_Block -> RFNoC_Block -> > RFNoC_RX_Streamer -> QT_GUI_Freq_Sink: > > Everything runs, but the following repeats over and over and the output > plot doesn't change: > ---- > gr::log :WARN: rfnoc_rx_streamer0 - RFNoC Streamer block received error > ERROR_CODE_BAD_PACKET (Code: 0xf) > [ERROR] [STREAMER] The receive transport caught a value exception. > ValueError: Bad CHDR header or invalid packet length. > gr::log :WARN: rfnoc_rx_streamer0 - RFNoC Streamer block received error > ERROR_CODE_BAD_PACKET (Code: 0xf) > [ERROR] [STREAMER] The receive transport caught a value exception. > ValueError: Bad CHDR header or invalid packet length. > ---- > > I put in some ILA probes and it seems that "ep4_to_xb_tready" is stuck > low. ep4 is the endpoint tied to the in and out of my custom "Block." I'm > guessing it didn't start low but a FIFO or something filled up somewhere. > > I should mention that if I use this same setup, but remove my custom > RFNoC_Block and directly connect the DDC to the RX_Streamer, everything > works fine. No errors, the spectrum looks fine, etc. > > > 2) If my setup is Constant_Source(set to 4+9j) -> RFNoC_TX_Streamer -> > RFNoC_Block -> RFNoC_RX_Streamer -> QT_GUI_Time_Sink: > > Everything runs and I do not have a problem with any gnuradio warnings. > Also, TReady is high the entire time. But, the output plot for I and Q sit > mostly constant stuck at "1", with non-periodic blips down to "0". I'm not > seeing the complex constant I set in gnuradio. If I look at the > payload_tdata in an ILA for my "Block" when tvalid is high and tready is > high, I see that the data is sitting at 0x7fff7fff except when TLAST is > high, tdata switches to 0xfffc7ff7. > > I'm at a bit of a loss trying to figure out what is happening. Could it be > that UHD is not interfacing properly to my block (given that UHD doesn't > look for my OOT yml file)? I did not change any block controller code or > anything else. Oh, and the user_register that is included as part of the > default design designated by rfnocmodtool seems to work fine. I can change > the register value in gnuradio and I can see it change appropriately via > and ILA. > > For reference, this is what I've been working with: > 1) UHD (v4.0.0.0 tag) > 2) gnuradio (3.8.2.0 tag) > 3) gr-ettus (maint-3.8-uhd4.0 branch) > > RFNoC is new to me, so any thoughts on what could be wrong or how I could > go about debugging this would be greatly appreciated. Hopefully, I'm just > missing something simple. > > Thanks, > Jim > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
