[USRP-users] Receiving IO Block Error when Using RFNoC Split Stream
Greetings,
I was wondering if anyone had encountered the following error and had a way
to fix it?
[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
UHD_3.14.1.HEAD-0-g0347a6d8
[INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Detecting internal GPS
[INFO] [E300] GPSDO found
[INFO] [E300] Initializing core control (global registers)...
[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
[WARNING] [RFNOC] Can't find a block controller for key SplitStream, using
default block controller!
[INFO] [0/SplitStream_0] Initializing block control (NOC ID:
0x5757)
[ERROR] [UHD] Exception caught in safe-call.
in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
uhd::endianness_t _endianness = (uhd::endianness_t)1u]
at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
(CE_01_Port_21) 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_t)1u; uint64_t =
long long unsigned int]
at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
Traceback (most recent call last):
File "rfnoc_fosphor_network_usrp.py", line 283, in
main()
File "rfnoc_fosphor_network_usrp.py", line 272, in main
tb = top_block_cls(fft_size=options.fft_size,
fpga_path=options.fpga_path, freq=options.freq, gain=options.gain,
host_ip_addr=options.host_ip_addr, samp_rate=options.samp_rate,
tdecay=options.tdecay, trise=options.trise)
File "rfnoc_fosphor_network_usrp.py", line 43, in __init__
self.device3 = variable_uhd_device3_0 =
ettus.device3(uhd.device_addr_t( ",".join(('type=e3x0',
"master_clock_rate=%d,fpga=%s" % (samp_rate,fpga_path))) ))
File
"/home/root/localinstall/usr/lib/python2.7/site-packages/ettus/ettus_swig.py",
line 1307, in make
return _ettus_swig.device3_make(*args, **kwargs)
RuntimeError: EnvironmentError: IOError: [0/SplitStream_0] sr_read64()
failed: EnvironmentError: IOError: Block ctrl (CE_01_Port_21) 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_t)1u; uint64_t =
long long unsigned int]
at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
This is only occurring when I use the split stream block in RFNoC. I have
tried the fixes in [1] but unfortunately they have not helped. Also, fix 1,
I can't seem to before b/c I am missing the file
rfnoc_ce_auto_inst_.v as shown from the output when attempting a
"find" command in Ubuntu.
find: ‘rfnoc_ce_auto_inst_e310.v’: No such file or directory
I ran it on both ~/* and /* with no luck.
Regards,
Jon Lockhart
[1] https://kb.ettus.com/RFNoC#Why_do_I_have_a_command_timeout_error.3F
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] RFNoC Radio Issue
Apologies, the files are attached. On Thu, Oct 31, 2019 at 3:30 PM Jonathan Lockhart wrote: > Greetings, > > I was wondering if anyone else has had this issue with the RFNoC radio > block. > > So I was using the copy block with the rfnoc_fosphor_network_usrp.grc file > as I wanted to split off the signal before it went off to the RFNoC Window. > So I put in a copy block (since the RFNoC Split block appears to be broken) > and passed the data off to a ZMQ Push and back to the window to continue to > be processed by the FPGA. GNURadio says this is all well and good since all > vectors are 512 and builds the file. However, when I run the .py file on my > E312 it throws an error stating that the radio is providing data of size 8 > when the copy block expects to get data of size 512 (the vector size). > > [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; > UHD_3.14.1.HEAD-0-gbfb9c1c7 > [INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit... > [INFO] [E300] FPGA image loaded > [INFO] [E300] Detecting internal GPS > [INFO] [E300] GPSDO found > [INFO] [E300] Initializing core control (global registers)... > > [INFO] [E300] Performing register loopback test... > [INFO] [E300] Register loopback test passed > [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000) > [WARNING] [RFNOC] Can't find a block controller for key FFT, using default > block controller! > [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70) > [INFO] [0/Window_0] Initializing block control (NOC ID: 0xD053) > [WARNING] [RFNOC] Can't find a block controller for key fosphor, using > default block controller! > [INFO] [0/fosphor_0] Initializing block control (NOC ID: > 0x666F) > [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) > [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) > Traceback (most recent call last): > File "rfnoc_fosphor_network_usrp.py", line 282, in > main() > File "rfnoc_fosphor_network_usrp.py", line 271, in main > tb = top_block_cls(fft_size=options.fft_size, > fpga_path=options.fpga_path, freq=options.freq, gain=options.gain, > host_ip_addr=options.host_ip_addr, samp_rate=options.samp_rate, > tdecay=options.tdecay, trise=options.trise) > File "rfnoc_fosphor_network_usrp.py", line 166, in __init__ > self.connect((self.uhd_rfnoc_streamer_radio_0, 0), > (self.blocks_copy_0, 0)) > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", > line 47, in wrapped > func(self, src, src_port, dst, dst_port) > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", > line 110, in connect > self.primitive_connect(*args) > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", > line 3482, in primitive_connect > return _runtime_swig.top_block_sptr_primitive_connect(self, *args) > ValueError: itemsize mismatch: rfnoc_radio0:0 using 8, copy0:0 using 4096 > > I have attached my modified examples for anyone who is interested. I have > tried to modify the python and that just gets me into more trouble. > > Through my tracing of the files it appears that the RFNoC Radio block in > the .py file never actually uses the vector size, and that the force vector > length block is an additive to allow compliance when working in GNURadio, > as it will not generate python with mismatched types and sizes. Trying to > force the radio to take the 512 as an argument in the python throws a new > error that the Radio is only allowed to have 5 arguments and I have > supplied 6, and validated in the Ettus .py file that there is no arg for > vector size. > > I was wondering if anyone found away around this or got the RFNoC Split > block working? > > Regards, > Jon Lockhart > rfnoc_fosphor_radio_network_host.grc Description: Binary data rfnoc_fosphor_radio_network_usrp.grc Description: Binary data ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] RFNoC Radio Issue
Greetings, I was wondering if anyone else has had this issue with the RFNoC radio block. So I was using the copy block with the rfnoc_fosphor_network_usrp.grc file as I wanted to split off the signal before it went off to the RFNoC Window. So I put in a copy block (since the RFNoC Split block appears to be broken) and passed the data off to a ZMQ Push and back to the window to continue to be processed by the FPGA. GNURadio says this is all well and good since all vectors are 512 and builds the file. However, when I run the .py file on my E312 it throws an error stating that the radio is providing data of size 8 when the copy block expects to get data of size 512 (the vector size). [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; UHD_3.14.1.HEAD-0-gbfb9c1c7 [INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit... [INFO] [E300] FPGA image loaded [INFO] [E300] Detecting internal GPS [INFO] [E300] GPSDO found [INFO] [E300] Initializing core control (global registers)... [INFO] [E300] Performing register loopback test... [INFO] [E300] Register loopback test passed [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000) [WARNING] [RFNOC] Can't find a block controller for key FFT, using default block controller! [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70) [INFO] [0/Window_0] Initializing block control (NOC ID: 0xD053) [WARNING] [RFNOC] Can't find a block controller for key fosphor, using default block controller! [INFO] [0/fosphor_0] Initializing block control (NOC ID: 0x666F) [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) Traceback (most recent call last): File "rfnoc_fosphor_network_usrp.py", line 282, in main() File "rfnoc_fosphor_network_usrp.py", line 271, in main tb = top_block_cls(fft_size=options.fft_size, fpga_path=options.fpga_path, freq=options.freq, gain=options.gain, host_ip_addr=options.host_ip_addr, samp_rate=options.samp_rate, tdecay=options.tdecay, trise=options.trise) File "rfnoc_fosphor_network_usrp.py", line 166, in __init__ self.connect((self.uhd_rfnoc_streamer_radio_0, 0), (self.blocks_copy_0, 0)) File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 47, in wrapped func(self, src, src_port, dst, dst_port) File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", line 110, in connect self.primitive_connect(*args) File "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line 3482, in primitive_connect return _runtime_swig.top_block_sptr_primitive_connect(self, *args) ValueError: itemsize mismatch: rfnoc_radio0:0 using 8, copy0:0 using 4096 I have attached my modified examples for anyone who is interested. I have tried to modify the python and that just gets me into more trouble. Through my tracing of the files it appears that the RFNoC Radio block in the .py file never actually uses the vector size, and that the force vector length block is an additive to allow compliance when working in GNURadio, as it will not generate python with mismatched types and sizes. Trying to force the radio to take the 512 as an argument in the python throws a new error that the Radio is only allowed to have 5 arguments and I have supplied 6, and validated in the Ettus .py file that there is no arg for vector size. I was wondering if anyone found away around this or got the RFNoC Split block working? Regards, Jon Lockhart ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Issues Using FFT RFNoC Block for E312
Greetings, I was wondering if anyone is familiar with utilizing the FFT block from the Ettus code library. I am using the default binary that is complied following the instructions in [1]. I have a working environment and have successfully used the foshpor window in the end example of that install to look at the spectrum around my area, which was really cool. I had some old hackRF examples I had made when I went through that course and was trying to convert them over to run on the E312, which some changes. I started with building a radio using the UHD software components but found out real quick that A9 can not sample fast enough, so switch to slowly using the RFNoC blocks, like Radio, FIFO, FFT, to do the heavy lifting, with a ZMQ Push to my host where it does software processing on it. Right now its just meant to be an FM radio, like in your car, and I have copied many of the modules over from the fosphor example in the gr-ettus install examples folder. With that bg, I get an interesting result. With the components of Window and FFT disabled I get an audio output. When I don't the host shows on the QT GUI a sync at my centering frequency. I assumed it was b/c the RFNoC blocks were operating with a 512 vector size and GNU Radio software blocks prefer a vector size of 1 (for some of them like QT GUI). I also thought it was b/c the QT block also has an FFT, so I placed an inverse FFT inline, which had no effect. With all this said, I know there needs to be an FFT to process an analog signal, that is how a DFT is handled with logic or computers. I would like to do the heavy lifting on the FPGA with its FFT, rather than relying on the FFT in the gui, and also still get audio out. Does anyone have an suggestions, and are there any reference materials that could be recommended? I have mostly been using Google and examples I can find on the Ettus KB, plus the gr-ettus installed examples as references. I have attached my .grc files for reference. Regards, Jon Lockhart [1] https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source fm_example_host.grc Description: Binary data fm_example_usrp.grc Description: Binary data ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues with RFNoC Component Test Bench
Greetings Brian,
Thanks for the link. Yeah my Vivado always complains about the tcl cache
being unavailable unless I run as sudo. I think its b/c I installed it with
sudo, as otherwise it wouldn't make the /opt/Xilinx directory. It seems to
work either way regardless if it uses the official tcl cache or a local one.
Anyways, that example worked out great. Now the sim could find the FPGA
repo and it tested on the 7020. I making a note of that so I can be sure to
incorporate those changes in the future for other blocks will build.
Regards,
Jon
On Wed, Nov 13, 2019 at 11:21 AM Brian Padalino wrote:
> Hey Jon,
>
> On Wed, Nov 13, 2019 at 11:17 AM Jonathan Lockhart
> wrote:
>
>> Greetings Brian,
>>
>> I had noticed that the script was set to use the X300 after I sent the
>> email. I switched in the CMakeList.txt file to use the e300 repo, which is
>> using the Zynq-7020, which is included in the webpack version of Vivado. I
>> unfortunately got the same error prior to the change, included below.
>>
>> ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ make
>> noc_block_gain_tb
>> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
>> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>>
>> Environment successfully initialized.
>> BUILDER: Checking tools...
>> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
>> * Python 2.7.15+
>> * Vivado v2017.4.1 (64-bit)
>>
>> ** Vivado v2017.4.1 (64-bit)
>> SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
>> IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
>> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
>>
>> CRITICAL WARNING: [Common 17-741] No write access right to the local Tcl
>> store at '/home/ettus_sdr/.Xilinx/Vivado/2017.4/XilinxTclStore'.
>> XilinxTclStore is reverted to the installation area. If you want to use
>> local Tcl Store, please change the access right and relaunch Vivado.
>> source
>> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
>>
>
> This seems bad in general. Maybe because you ran it as sudo before and
> now non-sudo?
>
>
>> # set simulator $::env(VIV_SIMULATOR)
>> # set design_srcs $::env(VIV_DESIGN_SRCS)
>> # set sim_srcs$::env(VIV_SIM_SRCS)
>> # set inc_srcs$::env(VIV_INC_SRCS)
>> # set sim_top $::env(VIV_SIM_TOP)
>> # set part_name $::env(VIV_PART_NAME)
>> # set sim_runtime $::env(VIV_SIM_RUNTIME)
>> # set sim_fast$::env(VIV_SIM_FAST)
>> # set vivado_mode $::env(VIV_MODE)
>> # set working_dir [pwd]
>> # set sim_fileset "sim_1"
>> # set project_name "[string tolower $simulator]_proj"
>> # if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
>> # set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
>> # if [expr [file isdirectory $sim_complibdir] == 0] {
>> # set sim_complibdir ""
>> # }
>> # } else {
>> # set sim_complibdir ""
>> # }
>> # if [expr ([string equal $simulator "XSim"] == 0) && ([string length
>> $sim_complibdir] == 0)] {
>> # puts "BUILDER: \[ERROR\]: Could not resolve the location for the
>> compiled simulation libraries."
>> # puts " Please build libraries for chosen simulator
>> and set the env or"
>> # puts " makefile variable SIM_COMPLIBDIR to point
>> to the location."
>> # exit 1
>> # }
>> # puts "BUILDER: Creating Vivado simulation project part $part_name"
>> BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
>> # create_project -part $part_name -force $project_name/$project_name
>> WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
>> ERROR: [Coretcl 2-106] Specified part could not be found.
>> INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 11:07:09 2019...
>> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
>> recipe for target 'xsim' failed
>> make[4]: *** [xsim] Error 1
>> CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
>> 'CMakeFiles/noc_block_gain_tb' failed
>> make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 2
>> CMakeFiles/Makefile2:131: recipe for target
>> 'CMakeFiles/noc_block_gain_tb.dir/all' failed
>> make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
>> CMakeFiles/Makefile2:138: recipe for target
>> 'CMakeFiles/noc_block_gain_tb.dir/rule' failed
>> make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
>> Makefile:201: recipe for target 'noc_block_gain_tb' failed
>> make: *** [noc_block_gain_tb] Error 2
>>
>> I am assuming this is the part that needs to be changed:
>> xc7k410tffg900-2. I am not seeing where this is declared in the
>> CMakeList.txt file. Do you know where I would go about changing it in the
>> build scripts?
>>
>
> Yeah, change it over. I use EJ's repository as a good example for lots of
> stuff. Particularly this:
>
>
> https://github.com/ejk43/rfnoc-ootexample/blob/master/rfnoc/testbenches/noc_block_complextomagphase_tb/Makefile#L14
>
> Just override it in the Makefile
[USRP-users] Issues with RFNoC Component Test Bench
Greetings USRP Users,
I am having another issue with the UHD-3.14 build I can't seem to shake
down. I have been going through this guide on the KB to learn how to use
the rfnocmodtool to build new modules for my E312:
https://kb.ettus.com/Getting_Started_with_RFNoC_Development
Unfortunately, when I get to the point of using the test bench, I get the
following error.
ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ sudo make
noc_block_gain_tb
[sudo] password for ettus_sdr:
Setting up a 64-bit FPGA build environment for the USRP-X3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
Environment successfully initialized.
BUILDER: Checking tools...
* GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.15+
* Vivado v2017.4.1 (64-bit)
** Vivado v2017.4.1 (64-bit)
SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
source
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
# set simulator $::env(VIV_SIMULATOR)
# set design_srcs $::env(VIV_DESIGN_SRCS)
# set sim_srcs$::env(VIV_SIM_SRCS)
# set inc_srcs$::env(VIV_INC_SRCS)
# set sim_top $::env(VIV_SIM_TOP)
# set part_name $::env(VIV_PART_NAME)
# set sim_runtime $::env(VIV_SIM_RUNTIME)
# set sim_fast$::env(VIV_SIM_FAST)
# set vivado_mode $::env(VIV_MODE)
# set working_dir [pwd]
# set sim_fileset "sim_1"
# set project_name "[string tolower $simulator]_proj"
# if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
# set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
# if [expr [file isdirectory $sim_complibdir] == 0] {
# set sim_complibdir ""
# }
# } else {
# set sim_complibdir ""
# }
# if [expr ([string equal $simulator "XSim"] == 0) && ([string length
$sim_complibdir] == 0)] {
# puts "BUILDER: \[ERROR\]: Could not resolve the location for the
compiled simulation libraries."
# puts " Please build libraries for chosen simulator
and set the env or"
# puts " makefile variable SIM_COMPLIBDIR to point to
the location."
# exit 1
# }
# puts "BUILDER: Creating Vivado simulation project part $part_name"
BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
# create_project -part $part_name -force $project_name/$project_name
WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
ERROR: [Coretcl 2-106] Specified part could not be found.
INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 10:44:55 2019...
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
recipe for target 'xsim' failed
make[4]: *** [xsim] Error 1
CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
'CMakeFiles/noc_block_gain_tb' failed
make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 2
CMakeFiles/Makefile2:131: recipe for target
'CMakeFiles/noc_block_gain_tb.dir/all' failed
make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
CMakeFiles/Makefile2:138: recipe for target
'CMakeFiles/noc_block_gain_tb.dir/rule' failed
make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
Makefile:201: recipe for target 'noc_block_gain_tb' failed
make: *** [noc_block_gain_tb] Error 2
The tutorial has you build a gain module, and I have verified the code is
copied as they provide it in the guide, with no other extras provided by
the build script being modified.
I also verified that the cmake for the test bench was provided the correct
FPGA source repository and it picked it up in the build phase.
Regards,
Jon
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream
Greetings EJ, Thanks for the info. I haven't had time to grab the new block as my dev box is packed for moving this weekend. I will get it downloaded and try it as soon as I can. Regards, Jon On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar wrote: > Hi there, > > Just want to chime in since I recently went through the upgrade process to > UHD-3.14... > > Can you confirm you're using uhd-3.14? If so, this is actually a split > stream fpga bug caused by the commit Jon referred to, not the "not enough > bandwidth" problem. > > Fortunately, rather than referring the old commit, the bug seems to have > been fixed in October on the master branch: https:// > github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9 > (but not yet ported onto 3.14) > > I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up for me. > > I assume this will eventually make it to the UHD-3.14 branch? But if not > the cherry pick works fine > > EJ > > > On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Jonathon, >> >> I will give that a try and see if it works. >> >> >> Nick, >> >> If the revert on Split_Stream fails, I will try switching from ce_clk to >> bus_clk and give that a try. >> >> >> Regards, >> Jon >> >> On Fri, Nov 8, 2019 at 1:52 PM Nick Foster wrote: >> >>> Jonathon (Pendlum), correct me if I'm wrong, but I think this is the >>> usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem. >>> >>> Jonathan (Lockhart), if I'm right, then in your >>> rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the >>> noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix the >>> problem. >>> >>> Nick >>> >>> On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum < >>> jonathon.pend...@ettus.com> wrote: >>> >>>> Hi Jon, >>>> >>>> Can you try reverting commit e39334fe on the fpga repo and rebuilding >>>> your bitstream? Let me know if that makes a difference or not. >>>> >>>> Jonathon >>>> >>>> On Sat, Nov 9, 2019 at 12:13 AM Jonathan Lockhart via USRP-users < >>>> usrp-users@lists.ettus.com> wrote: >>>> >>>>> Greetings Nick, >>>>> >>>>> Here is the screenshot of my GR flow graph, though it shouldn't matter >>>>> as the Split_Stream RFNoC Block I believe is a failure of the python or >>>>> Verilog but the solutions in the link I sent in my previous email did not >>>>> resolve the issue. >>>>> >>>>> [image: Screenshot from 2019-11-08 10-06-50.png] >>>>> >>>>> Regards, >>>>> Jon >>>>> >>>>> On Thu, Nov 7, 2019 at 5:33 PM Nick Foster >>>>> wrote: >>>>> >>>>>> Can you be more specific about what your flowgraph looks like? >>>>>> >>>>>> On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>>> Greetings, >>>>>>> >>>>>>> I was wondering if anyone had encountered the following error and >>>>>>> had a way to fix it? >>>>>>> >>>>>>> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; >>>>>>> UHD_3.14.1.HEAD-0-g0347a6d8 >>>>>>> [INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit... >>>>>>> [INFO] [E300] FPGA image loaded >>>>>>> [INFO] [E300] Detecting internal GPS >>>>>>> [INFO] [E300] GPSDO found >>>>>>> [INFO] [E300] Initializing core control (global registers)... >>>>>>> >>>>>>> [INFO] [E300] Performing register loopback test... >>>>>>> [INFO] [E300] Register loopback test passed >>>>>>> [INFO] [0/Radio_0] Initializing block control (NOC ID: >>>>>>> 0x12AD1000) >>>>>>> [WARNING] [RFNOC] Can't find a block controller for key SplitStream, >>>>>>> using default block controller! >>>>>>> [INFO] [0/SplitStream_0] Initializing block control (NOC ID: >>>>>>> 0x5757) >>>>>>> [ERROR] [UHD] Exception caught in safe-call. >
Re: [USRP-users] Issues with RFNoC Component Test Bench
Greetings Brian,
I had noticed that the script was set to use the X300 after I sent the
email. I switched in the CMakeList.txt file to use the e300 repo, which is
using the Zynq-7020, which is included in the webpack version of Vivado. I
unfortunately got the same error prior to the change, included below.
ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ make
noc_block_gain_tb
Setting up a 64-bit FPGA build environment for the USRP-E3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
Environment successfully initialized.
BUILDER: Checking tools...
* GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.15+
* Vivado v2017.4.1 (64-bit)
** Vivado v2017.4.1 (64-bit)
SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
CRITICAL WARNING: [Common 17-741] No write access right to the local Tcl
store at '/home/ettus_sdr/.Xilinx/Vivado/2017.4/XilinxTclStore'.
XilinxTclStore is reverted to the installation area. If you want to use
local Tcl Store, please change the access right and relaunch Vivado.
source
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
# set simulator $::env(VIV_SIMULATOR)
# set design_srcs $::env(VIV_DESIGN_SRCS)
# set sim_srcs$::env(VIV_SIM_SRCS)
# set inc_srcs$::env(VIV_INC_SRCS)
# set sim_top $::env(VIV_SIM_TOP)
# set part_name $::env(VIV_PART_NAME)
# set sim_runtime $::env(VIV_SIM_RUNTIME)
# set sim_fast$::env(VIV_SIM_FAST)
# set vivado_mode $::env(VIV_MODE)
# set working_dir [pwd]
# set sim_fileset "sim_1"
# set project_name "[string tolower $simulator]_proj"
# if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
# set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
# if [expr [file isdirectory $sim_complibdir] == 0] {
# set sim_complibdir ""
# }
# } else {
# set sim_complibdir ""
# }
# if [expr ([string equal $simulator "XSim"] == 0) && ([string length
$sim_complibdir] == 0)] {
# puts "BUILDER: \[ERROR\]: Could not resolve the location for the
compiled simulation libraries."
# puts " Please build libraries for chosen simulator
and set the env or"
# puts " makefile variable SIM_COMPLIBDIR to point to
the location."
# exit 1
# }
# puts "BUILDER: Creating Vivado simulation project part $part_name"
BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
# create_project -part $part_name -force $project_name/$project_name
WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
ERROR: [Coretcl 2-106] Specified part could not be found.
INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 11:07:09 2019...
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
recipe for target 'xsim' failed
make[4]: *** [xsim] Error 1
CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
'CMakeFiles/noc_block_gain_tb' failed
make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 2
CMakeFiles/Makefile2:131: recipe for target
'CMakeFiles/noc_block_gain_tb.dir/all' failed
make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
CMakeFiles/Makefile2:138: recipe for target
'CMakeFiles/noc_block_gain_tb.dir/rule' failed
make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
Makefile:201: recipe for target 'noc_block_gain_tb' failed
make: *** [noc_block_gain_tb] Error 2
I am assuming this is the part that needs to be changed: xc7k410tffg900-2.
I am not seeing where this is declared in the CMakeList.txt file. Do you
know where I would go about changing it in the build scripts?
Regards,
Jon
On Wed, Nov 13, 2019 at 11:12 AM Brian Padalino wrote:
> On Wed, Nov 13, 2019 at 10:54 AM Jonathan Lockhart via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Greetings USRP Users,
>>
>> I am having another issue with the UHD-3.14 build I can't seem to shake
>> down. I have been going through this guide on the KB to learn how to use
>> the rfnocmodtool to build new modules for my E312:
>>
>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>>
>> Unfortunately, when I get to the point of using the test bench, I get the
>> following error.
>>
>> ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ sudo make
>> noc_block_gain_tb
>> [sudo] password for ettus_sdr:
>> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
>> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>>
>> Environment successfully initialized.
>> BUILDER: Checking tools...
>> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
>> * Python 2.7.15+
>> * Vivado v2017.4.1 (64-bit)
>>
>> ** Vivado v201
Re: [USRP-users] Issues with RFNoC Component Test Bench
Greetings Brian,
I was having some issues with the build process, as the build script
couldn't find the gain.v block file even though I was pointing the script
to it. I saw that ejk github has some .inc files, so I added those and it
seemed to clear up the issue. *crosses fingers* The bit file was building
when I left for word this morning.
Regards,
Jon
On Wed, Nov 13, 2019 at 12:32 PM Jonathan Lockhart
wrote:
> Greetings Brian,
>
> Thanks for the link. Yeah my Vivado always complains about the tcl cache
> being unavailable unless I run as sudo. I think its b/c I installed it with
> sudo, as otherwise it wouldn't make the /opt/Xilinx directory. It seems to
> work either way regardless if it uses the official tcl cache or a local one.
>
> Anyways, that example worked out great. Now the sim could find the FPGA
> repo and it tested on the 7020. I making a note of that so I can be sure to
> incorporate those changes in the future for other blocks will build.
>
> Regards,
> Jon
>
> On Wed, Nov 13, 2019 at 11:21 AM Brian Padalino
> wrote:
>
>> Hey Jon,
>>
>> On Wed, Nov 13, 2019 at 11:17 AM Jonathan Lockhart
>> wrote:
>>
>>> Greetings Brian,
>>>
>>> I had noticed that the script was set to use the X300 after I sent the
>>> email. I switched in the CMakeList.txt file to use the e300 repo, which is
>>> using the Zynq-7020, which is included in the webpack version of Vivado. I
>>> unfortunately got the same error prior to the change, included below.
>>>
>>> ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ make
>>> noc_block_gain_tb
>>> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
>>> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>>>
>>> Environment successfully initialized.
>>> BUILDER: Checking tools...
>>> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
>>> * Python 2.7.15+
>>> * Vivado v2017.4.1 (64-bit)
>>>
>>> ** Vivado v2017.4.1 (64-bit)
>>> SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
>>> IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
>>> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
>>>
>>> CRITICAL WARNING: [Common 17-741] No write access right to the local Tcl
>>> store at '/home/ettus_sdr/.Xilinx/Vivado/2017.4/XilinxTclStore'.
>>> XilinxTclStore is reverted to the installation area. If you want to use
>>> local Tcl Store, please change the access right and relaunch Vivado.
>>> source
>>> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
>>>
>>
>> This seems bad in general. Maybe because you ran it as sudo before and
>> now non-sudo?
>>
>>
>>> # set simulator $::env(VIV_SIMULATOR)
>>> # set design_srcs $::env(VIV_DESIGN_SRCS)
>>> # set sim_srcs$::env(VIV_SIM_SRCS)
>>> # set inc_srcs$::env(VIV_INC_SRCS)
>>> # set sim_top $::env(VIV_SIM_TOP)
>>> # set part_name $::env(VIV_PART_NAME)
>>> # set sim_runtime $::env(VIV_SIM_RUNTIME)
>>> # set sim_fast$::env(VIV_SIM_FAST)
>>> # set vivado_mode $::env(VIV_MODE)
>>> # set working_dir [pwd]
>>> # set sim_fileset "sim_1"
>>> # set project_name "[string tolower $simulator]_proj"
>>> # if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
>>> # set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
>>> # if [expr [file isdirectory $sim_complibdir] == 0] {
>>> # set sim_complibdir ""
>>> # }
>>> # } else {
>>> # set sim_complibdir ""
>>> # }
>>> # if [expr ([string equal $simulator "XSim"] == 0) && ([string length
>>> $sim_complibdir] == 0)] {
>>> # puts "BUILDER: \[ERROR\]: Could not resolve the location for the
>>> compiled simulation libraries."
>>> # puts " Please build libraries for chosen
>>> simulator and set the env or"
>>> # puts " makefile variable SIM_COMPLIBDIR to point
>>> to the location."
>>> # exit 1
>>> # }
>>> # puts "BUILDER: Creating Vivado simulation project part $part_name"
>>> BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
>>> # create_project -part $part_name -force $project_name/$project_name
>>> WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
>>> ERROR: [Coretcl 2-106] Specified part could not be found.
>>> INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 11:07:09 2019...
>>> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
>>> recipe for target 'xsim' failed
>>> make[4]: *** [xsim] Error 1
>>> CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
>>> 'CMakeFiles/noc_block_gain_tb' failed
>>> make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 2
>>> CMakeFiles/Makefile2:131: recipe for target
>>> 'CMakeFiles/noc_block_gain_tb.dir/all' failed
>>> make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
>>> CMakeFiles/Makefile2:138: recipe for target
>>> 'CMakeFiles/noc_block_gain_tb.dir/rule' failed
>>> make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
>>> Makefile:201: recipe for target 'noc_block_gain_tb' failed
Re: [USRP-users] Issues with RFNoC Component Test Bench
Greetings Brian,
Update: the noc_block_split_stream does work in the radio. However, it has
to be going to another hardware component first, like a FIFO, before it can
be passed to software blocks on the arm or the ZMQ to port to a host
machine. It was very interesting. I know in one of the troubleshooting
documents they recommended that, but it does appear to be necessary for
some blocks.
Regards,
Jon
On Thu, Nov 14, 2019 at 10:48 AM Jonathan Lockhart
wrote:
> Greetings Brian,
>
> I was having some issues with the build process, as the build script
> couldn't find the gain.v block file even though I was pointing the script
> to it. I saw that ejk github has some .inc files, so I added those and it
> seemed to clear up the issue. *crosses fingers* The bit file was building
> when I left for word this morning.
>
> Regards,
> Jon
>
> On Wed, Nov 13, 2019 at 12:32 PM Jonathan Lockhart
> wrote:
>
>> Greetings Brian,
>>
>> Thanks for the link. Yeah my Vivado always complains about the tcl cache
>> being unavailable unless I run as sudo. I think its b/c I installed it with
>> sudo, as otherwise it wouldn't make the /opt/Xilinx directory. It seems to
>> work either way regardless if it uses the official tcl cache or a local one.
>>
>> Anyways, that example worked out great. Now the sim could find the FPGA
>> repo and it tested on the 7020. I making a note of that so I can be sure to
>> incorporate those changes in the future for other blocks will build.
>>
>> Regards,
>> Jon
>>
>> On Wed, Nov 13, 2019 at 11:21 AM Brian Padalino
>> wrote:
>>
>>> Hey Jon,
>>>
>>> On Wed, Nov 13, 2019 at 11:17 AM Jonathan Lockhart <
>>> jlockhar...@gmail.com> wrote:
>>>
Greetings Brian,
I had noticed that the script was set to use the X300 after I sent the
email. I switched in the CMakeList.txt file to use the e300 repo, which is
using the Zynq-7020, which is included in the webpack version of Vivado. I
unfortunately got the same error prior to the change, included below.
ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ make
noc_block_gain_tb
Setting up a 64-bit FPGA build environment for the USRP-E3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
Environment successfully initialized.
BUILDER: Checking tools...
* GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.15+
* Vivado v2017.4.1 (64-bit)
** Vivado v2017.4.1 (64-bit)
SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
CRITICAL WARNING: [Common 17-741] No write access right to the local
Tcl store at '/home/ettus_sdr/.Xilinx/Vivado/2017.4/XilinxTclStore'.
XilinxTclStore is reverted to the installation area. If you want to use
local Tcl Store, please change the access right and relaunch Vivado.
source
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
>>>
>>> This seems bad in general. Maybe because you ran it as sudo before and
>>> now non-sudo?
>>>
>>>
# set simulator $::env(VIV_SIMULATOR)
# set design_srcs $::env(VIV_DESIGN_SRCS)
# set sim_srcs$::env(VIV_SIM_SRCS)
# set inc_srcs$::env(VIV_INC_SRCS)
# set sim_top $::env(VIV_SIM_TOP)
# set part_name $::env(VIV_PART_NAME)
# set sim_runtime $::env(VIV_SIM_RUNTIME)
# set sim_fast$::env(VIV_SIM_FAST)
# set vivado_mode $::env(VIV_MODE)
# set working_dir [pwd]
# set sim_fileset "sim_1"
# set project_name "[string tolower $simulator]_proj"
# if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
# set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
# if [expr [file isdirectory $sim_complibdir] == 0] {
# set sim_complibdir ""
# }
# } else {
# set sim_complibdir ""
# }
# if [expr ([string equal $simulator "XSim"] == 0) && ([string length
$sim_complibdir] == 0)] {
# puts "BUILDER: \[ERROR\]: Could not resolve the location for the
compiled simulation libraries."
# puts " Please build libraries for chosen
simulator and set the env or"
# puts " makefile variable SIM_COMPLIBDIR to point
to the location."
# exit 1
# }
# puts "BUILDER: Creating Vivado simulation project part $part_name"
BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
# create_project -part $part_name -force $project_name/$project_name
WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
ERROR: [Coretcl 2-106] Specified part could not be found.
INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 11:07:09 2019...
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
recipe for
Re: [USRP-users] E312 - Migrating OOT Modules to the USRP
/rx_dsps/0/freq
>>> /mboards/0/rx_dsps/0/freq/value
>>> /mboards/0/rx_dsps/0/freq/range
>>> /mboards/0/rx_dsps/0/rate
>>> /mboards/0/rx_dsps/0/rate/value
>>> /mboards/0/rx_dsps/1
>>> /mboards/0/rx_dsps/1/stream_cmd
>>> /mboards/0/rx_dsps/1/freq
>>> /mboards/0/rx_dsps/1/freq/value
>>> /mboards/0/rx_dsps/1/freq/range
>>> /mboards/0/rx_dsps/1/rate
>>> /mboards/0/rx_dsps/1/rate/value
>>> /mboards/0/tx_dsps
>>> /mboards/0/tx_dsps/0
>>> /mboards/0/tx_dsps/0/freq
>>> /mboards/0/tx_dsps/0/freq/value
>>> /mboards/0/tx_dsps/0/freq/range
>>> /mboards/0/tx_dsps/0/rate
>>> /mboards/0/tx_dsps/0/rate/value
>>> /mboards/0/tx_dsps/1
>>> /mboards/0/tx_dsps/1/freq
>>> /mboards/0/tx_dsps/1/freq/value
>>> /mboards/0/tx_dsps/1/freq/range
>>> /mboards/0/tx_dsps/1/rate
>>> /mboards/0/tx_dsps/1/rate/value
>>> /mboards/0/rx_subdev_spec
>>> /mboards/0/tx_subdev_spec
>>> [INFO] [E300] Loading FPGA image:
>>> /home/root/newinstall/usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit...
>>> [INFO] [E300] FPGA image loaded
>>>
>>> The failure output I got from running the python script shows that it
>>> can't find "/mboards/0/xbar/gain_0/args/0/gain/value" and when I look at
>>> the tree, there is no value instantiated by the probe. It only looks like
>>> the furthest that the probe goes down in the mboards is
>>> "/mboards/0/xbar/gain_0/args/0". I am assuming its something in the
>>> arguments file not getting loaded, but everything appears ok to me on
>>> glance in that XML file.
>>>
>>> Regards,
>>> Jon
>>>
>>> On Thu, Nov 21, 2019 at 4:49 PM EJ Kreinar wrote:
>>>
>>>> Okay, great...
>>>>
>>>> You might want to try increasing the log level. Export
>>>> UHD_LOG_CONSOLE_LEVEL=trace or debug and try to make sure the correct xml
>>>> file is getting applied to the block correctly.
>>>>
>>>> There's also something like a "--tree" parameter in the uhd_usrp_probe
>>>> so try running the probe with the tree option to print out the device tree
>>>> and look for the arguments assigned to your new block.
>>>>
>>>> Let's see if any of that helps figure out what's going on...
>>>> EJ
>>>>
>>>> On Thu, Nov 21, 2019, 4:01 PM Jonathan Lockhart
>>>> wrote:
>>>>
>>>>> Also, when I compiled from the OOT directory for ARM, I used this
>>>>> command, which I pieced together from the RFNoC build guide, and the
>>>>> release-4 guide for cross-compiling gr-ettus.
>>>>>
>>>>> cmake
>>>>> -DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>>>>> -DCMAKE_INSTALL_PREFIX=/usr
>>>>> -DUHD_FPGA_DIR="/home/jon/rfnoc/src/uhd/fpga-src/" ../
>>>>>
>>>>> Regards,
>>>>> Jon
>>>>>
>>>>> On Thu, Nov 21, 2019 at 3:48 PM Jonathan Lockhart <
>>>>> jlockhar...@gmail.com> wrote:
>>>>>
>>>>>> Greetings EJ,
>>>>>>
>>>>>> So, from the tutorial, they have you edit the gain.xml file, and this
>>>>>> is what I have for it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> gain
>>>>>> gain
>>>>>>
>>>>>> B7DD64941A952AAC
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gain
>>>>>> 128
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> gain
>>>>>> double
>>>>>> 1.0
>>>>>> GE($gain, 0.0) AND LE($gain, 32767.0)
>>>>>> Invalid Gain!
>>>>>>
>>>>>> SR_WRITE("GAIN", IROUND($gain))
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> in0
>>>>>> sc16
>>>>>>
>>>>>>
>>>>>> out0
>>>>>>
Re: [USRP-users] E312 - Migrating OOT Modules to the USRP
gt;>
>>> Gain
>>> 128
>>>
>>>
>>>
>>>
>>>
>>> gain
>>> double
>>> 1.0
>>> GE($gain, 0.0) AND LE($gain, 32767.0)
>>> Invalid Gain!
>>>
>>> SR_WRITE("GAIN", IROUND($gain))
>>>
>>>
>>>
>>>
>>>
>>>
>>> in0
>>> sc16
>>>
>>>
>>> out0
>>> sc16
>>>
>>>
>>>
>>>
>>> There is an args value and it is declared as gain.
>>>
>>> So from there, I followed your second suggestion and tried to find where
>>> it was installed when I did the cross compile. It was not placed in the
>>> "GRC_BLOCKS_PATH" of "/share/gnuradio/grc/blocks" like the default RFNoC
>>> blocks. It was instead placed in "/share/uhd/rfnoc/bocks" so I added that
>>> to the setup.env file, included below.
>>>
>>> LOCALPREFIX=~/newinstall/usr
>>> export PATH=$LOCALPREFIX/bin:$PATH
>>> export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
>>> export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
>>> export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
>>> export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
>>> export
>>> GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
>>> export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
>>> export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
>>> export
>>> GRC_BLOCKS_PATH=$LOCALPREFIX/share/uhd/rfnoc/blocks:$GRC_BLOCKS_PATH
>>>
>>> Unfortunately, after re-sourcing the setup.env, I still get the same
>>> message.
>>>
>>> File "rfnoc_myGain_usrp.py", line 223, in
>>> main()
>>> File "rfnoc_myGain_usrp.py", line 212, in main
>>> tb = top_block_cls(fpga_path=options.fpga_path,
>>> rx_gain=options.rx_gain, rx_digital_gain=options.rx_digital_gain,
>>> rx_freq=options.rx_freq, host_ip_addr=options.host_ip_addr)
>>> File "rfnoc_myGain_usrp.py", line 117, in __init__
>>> self.tutorial_gain_0.set_arg("gain", rx_digital_gain)
>>> File
>>> "/home/root/newinstall/usr/lib/python2.7/site-packages/tutorial/tutorial_swig.py",
>>> line 315, in set_arg
>>> return _tutorial_swig.gain_sptr_set_arg(self, *args)
>>> RuntimeError: LookupError: Path not found in tree:
>>> /mboards/0/xbar/gain_0/args/0/gain/value
>>>
>>> I looked at some of your examples (which have been very helpful to get
>>> me this far) from what I believe is your github someone linked me.
>>> Everything appears to match what it should, for what gain is trying to
>>> accomplish.
>>>
>>> Regards,
>>> Jon
>>>
>>> On Thu, Nov 21, 2019 at 3:27 PM EJ Kreinar wrote:
>>>
>>>> Hi Jon,
>>>>
>>>> The rfnoc "nocscript" xml definition can create arguments and attach to
>>>> the device tree like you are trying to set there (it's not compiled
>>>> directly, but rather created dynamically from the xml definition)
>>>>
>>>> Recommended debugging...
>>>> 1. Check your OOT gain block xml (in rfnoc/blocks) and make sure it has
>>>> a "gain" field in the "args" list. You'll also want to make sure it writes
>>>> your desired register, but I don't think you're even getting that far
>>>> 2. Make sure the block xml is installed on the e310 embedded prefix and
>>>> is found at run time during uhd_usrp_probe and when running your
>>>> application. If it's not in the right place or not attaching to your block
>>>> then it won't create the gain argument
>>>>
>>>> I'm guessing it's one of those two possibilities...
>>>> EJ
>>>>
>>>> On Thu, Nov 21, 2019, 3:19 PM Jonathan Lockhart via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> I was able to get the ARM cross compile working. I removed the build
>>>>> directory and re-sourced the dev environment and then the cross-compile
>>>>> used the -mfloar=hard flag. Not sure what caused the issue earlier and why
>>>>> it wasn't picking it up.
>>
Re: [USRP-users] E312 - Migrating OOT Modules to the USRP
and this
>>>>> is what I have for it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> gain
>>>>> gain
>>>>>
>>>>> B7DD64941A952AAC
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Gain
>>>>> 128
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> gain
>>>>> double
>>>>> 1.0
>>>>> GE($gain, 0.0) AND LE($gain, 32767.0)
>>>>> Invalid Gain!
>>>>>
>>>>> SR_WRITE("GAIN", IROUND($gain))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> in0
>>>>> sc16
>>>>>
>>>>>
>>>>> out0
>>>>> sc16
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> There is an args value and it is declared as gain.
>>>>>
>>>>> So from there, I followed your second suggestion and tried to find
>>>>> where it was installed when I did the cross compile. It was not placed in
>>>>> the "GRC_BLOCKS_PATH" of "/share/gnuradio/grc/blocks" like the default
>>>>> RFNoC blocks. It was instead placed in "/share/uhd/rfnoc/bocks" so I added
>>>>> that to the setup.env file, included below.
>>>>>
>>>>> LOCALPREFIX=~/newinstall/usr
>>>>> export PATH=$LOCALPREFIX/bin:$PATH
>>>>> export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
>>>>> export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
>>>>> export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
>>>>> export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
>>>>> export
>>>>> GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
>>>>> export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
>>>>> export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
>>>>> export
>>>>> GRC_BLOCKS_PATH=$LOCALPREFIX/share/uhd/rfnoc/blocks:$GRC_BLOCKS_PATH
>>>>>
>>>>> Unfortunately, after re-sourcing the setup.env, I still get the same
>>>>> message.
>>>>>
>>>>> File "rfnoc_myGain_usrp.py", line 223, in
>>>>> main()
>>>>> File "rfnoc_myGain_usrp.py", line 212, in main
>>>>> tb = top_block_cls(fpga_path=options.fpga_path,
>>>>> rx_gain=options.rx_gain, rx_digital_gain=options.rx_digital_gain,
>>>>> rx_freq=options.rx_freq, host_ip_addr=options.host_ip_addr)
>>>>> File "rfnoc_myGain_usrp.py", line 117, in __init__
>>>>> self.tutorial_gain_0.set_arg("gain", rx_digital_gain)
>>>>> File
>>>>> "/home/root/newinstall/usr/lib/python2.7/site-packages/tutorial/tutorial_swig.py",
>>>>> line 315, in set_arg
>>>>> return _tutorial_swig.gain_sptr_set_arg(self, *args)
>>>>> RuntimeError: LookupError: Path not found in tree:
>>>>> /mboards/0/xbar/gain_0/args/0/gain/value
>>>>>
>>>>> I looked at some of your examples (which have been very helpful to get
>>>>> me this far) from what I believe is your github someone linked me.
>>>>> Everything appears to match what it should, for what gain is trying to
>>>>> accomplish.
>>>>>
>>>>> Regards,
>>>>> Jon
>>>>>
>>>>> On Thu, Nov 21, 2019 at 3:27 PM EJ Kreinar
>>>>> wrote:
>>>>>
>>>>>> Hi Jon,
>>>>>>
>>>>>> The rfnoc "nocscript" xml definition can create arguments and attach
>>>>>> to the device tree like you are trying to set there (it's not compiled
>>>>>> directly, but rather created dynamically from the xml definition)
>>>>>>
>>>>>> Recommended debugging...
>>>>>> 1. Check your OOT gain block xml (in rfnoc/blocks) and make sure it
>>>>>> has a "gain" field in the "args" li
Re: [USRP-users] E312 - Migrating OOT Modules to the USRP
ers/rb/RB_FFT_DIRECTION >>>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_FFT_SCALING >>>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_FFT_SHIFT_CONFIG >>>>>> /mboards/0/xbar/FFT_0/ports >>>>>> /mboards/0/xbar/FFT_0/ports/in >>>>>> /mboards/0/xbar/FFT_0/ports/in/0 >>>>>> /mboards/0/xbar/FFT_0/ports/out >>>>>> /mboards/0/xbar/FFT_0/ports/out/0 >>>>>> /mboards/0/xbar/FFT_0/args >>>>>> /mboards/0/xbar/FFT_0/args/0 >>>>>> /mboards/0/xbar/FFT_0/args/0/spp >>>>>> /mboards/0/xbar/FFT_0/args/0/spp/type >>>>>> /mboards/0/xbar/FFT_0/args/0/spp/value >>>>>> /mboards/0/xbar/FFT_0/args/0/shift >>>>>> /mboards/0/xbar/FFT_0/args/0/shift/type >>>>>> /mboards/0/xbar/FFT_0/args/0/shift/value >>>>>> /mboards/0/xbar/FFT_0/args/0/direction >>>>>> /mboards/0/xbar/FFT_0/args/0/direction/type >>>>>> /mboards/0/xbar/FFT_0/args/0/direction/value >>>>>> /mboards/0/xbar/FFT_0/args/0/scaling >>>>>> /mboards/0/xbar/FFT_0/args/0/scaling/type >>>>>> /mboards/0/xbar/FFT_0/args/0/scaling/value >>>>>> /mboards/0/xbar/FFT_0/args/0/otype >>>>>> /mboards/0/xbar/FFT_0/args/0/otype/type >>>>>> /mboards/0/xbar/FFT_0/args/0/otype/value >>>>>> /mboards/0/xbar/FFT_0/args/0/reset >>>>>> /mboards/0/xbar/FFT_0/args/0/reset/type >>>>>> /mboards/0/xbar/FFT_0/args/0/reset/value >>>>>> /mboards/0/xbar/FFT_0/args/0/magnitude_out >>>>>> /mboards/0/xbar/FFT_0/args/0/magnitude_out/type >>>>>> /mboards/0/xbar/FFT_0/args/0/magnitude_out/value >>>>>> /mboards/0/time >>>>>> /mboards/0/time/now >>>>>> /mboards/0/time/pps >>>>>> /mboards/0/time/cmd >>>>>> /mboards/0/time_source >>>>>> /mboards/0/time_source/value >>>>>> /mboards/0/time_source/options >>>>>> /mboards/0/rx_codecs >>>>>> /mboards/0/rx_codecs/A >>>>>> /mboards/0/rx_codecs/A/name >>>>>> /mboards/0/rx_codecs/A/gains >>>>>> /mboards/0/tx_codecs >>>>>> /mboards/0/tx_codecs/A >>>>>> /mboards/0/tx_codecs/A/name >>>>>> /mboards/0/tx_codecs/A/gains >>>>>> /mboards/0/gpio >>>>>> /mboards/0/gpio/INT0 >>>>>> /mboards/0/gpio/INT0/SRC >>>>>> /mboards/0/gpio/INT0/CTRL >>>>>> /mboards/0/gpio/INT0/DDR >>>>>> /mboards/0/gpio/INT0/OUT >>>>>> /mboards/0/gpio/INT0/ATR_0X >>>>>> /mboards/0/gpio/INT0/ATR_RX >>>>>> /mboards/0/gpio/INT0/ATR_TX >>>>>> /mboards/0/gpio/INT0/ATR_XX >>>>>> /mboards/0/gpio/INT0/READBACK >>>>>> /mboards/0/rx_dsps >>>>>> /mboards/0/rx_dsps/0 >>>>>> /mboards/0/rx_dsps/0/stream_cmd >>>>>> /mboards/0/rx_dsps/0/freq >>>>>> /mboards/0/rx_dsps/0/freq/value >>>>>> /mboards/0/rx_dsps/0/freq/range >>>>>> /mboards/0/rx_dsps/0/rate >>>>>> /mboards/0/rx_dsps/0/rate/value >>>>>> /mboards/0/rx_dsps/1 >>>>>> /mboards/0/rx_dsps/1/stream_cmd >>>>>> /mboards/0/rx_dsps/1/freq >>>>>> /mboards/0/rx_dsps/1/freq/value >>>>>> /mboards/0/rx_dsps/1/freq/range >>>>>> /mboards/0/rx_dsps/1/rate >>>>>> /mboards/0/rx_dsps/1/rate/value >>>>>> /mboards/0/tx_dsps >>>>>> /mboards/0/tx_dsps/0 >>>>>> /mboards/0/tx_dsps/0/freq >>>>>> /mboards/0/tx_dsps/0/freq/value >>>>>> /mboards/0/tx_dsps/0/freq/range >>>>>> /mboards/0/tx_dsps/0/rate >>>>>> /mboards/0/tx_dsps/0/rate/value >>>>>> /mboards/0/tx_dsps/1 >>>>>> /mboards/0/tx_dsps/1/freq >>>>>> /mboards/0/tx_dsps/1/freq/value >>>>>> /mboards/0/tx_dsps/1/freq/range >>>>>> /mboards/0/tx_dsps/1/rate >>>>>> /mboards/0/tx_dsps/1/rate/value >>>>>> /mboards/0/rx_subdev_spec >>>>>> /mboards/0/tx_subdev_spec >>>>>> [INFO] [E300] Loading FPGA image: >>>>>> /home/root/newinstall/usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit... >>>>>> [INFO] [E3
Re: [USRP-users] E312 - Migrating OOT Modules to the USRP
cy_api/1 >>>>> /mboards/0/xbar/DDC_0/legacy_api/1/rate >>>>> /mboards/0/xbar/DDC_0/legacy_api/1/rate/value >>>>> /mboards/0/xbar/DDC_0/legacy_api/1/rate/range >>>>> /mboards/0/xbar/DDC_0/legacy_api/1/freq >>>>> /mboards/0/xbar/DDC_0/legacy_api/1/freq/value >>>>> /mboards/0/xbar/DDC_0/legacy_api/1/freq/range >>>>> /mboards/0/xbar/FFT_0 >>>>> /mboards/0/xbar/FFT_0/noc_id >>>>> /mboards/0/xbar/FFT_0/input_buffer_size >>>>> /mboards/0/xbar/FFT_0/input_buffer_size/0 >>>>> /mboards/0/xbar/FFT_0/mtu >>>>> /mboards/0/xbar/FFT_0/mtu/0 >>>>> /mboards/0/xbar/FFT_0/registers >>>>> /mboards/0/xbar/FFT_0/registers/sr >>>>> /mboards/0/xbar/FFT_0/registers/sr/FFT_RESET >>>>> /mboards/0/xbar/FFT_0/registers/sr/FFT_SIZE_LOG2 >>>>> /mboards/0/xbar/FFT_0/registers/sr/MAGNITUDE_OUT >>>>> /mboards/0/xbar/FFT_0/registers/sr/FFT_DIRECTION >>>>> /mboards/0/xbar/FFT_0/registers/sr/FFT_SCALING >>>>> /mboards/0/xbar/FFT_0/registers/sr/FFT_SHIFT_CONFIG >>>>> /mboards/0/xbar/FFT_0/registers/rb >>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_FFT_RESET >>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_MAGNITUDE_OUT >>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_FFT_SIZE_LOG2 >>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_FFT_DIRECTION >>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_FFT_SCALING >>>>> /mboards/0/xbar/FFT_0/registers/rb/RB_FFT_SHIFT_CONFIG >>>>> /mboards/0/xbar/FFT_0/ports >>>>> /mboards/0/xbar/FFT_0/ports/in >>>>> /mboards/0/xbar/FFT_0/ports/in/0 >>>>> /mboards/0/xbar/FFT_0/ports/out >>>>> /mboards/0/xbar/FFT_0/ports/out/0 >>>>> /mboards/0/xbar/FFT_0/args >>>>> /mboards/0/xbar/FFT_0/args/0 >>>>> /mboards/0/xbar/FFT_0/args/0/spp >>>>> /mboards/0/xbar/FFT_0/args/0/spp/type >>>>> /mboards/0/xbar/FFT_0/args/0/spp/value >>>>> /mboards/0/xbar/FFT_0/args/0/shift >>>>> /mboards/0/xbar/FFT_0/args/0/shift/type >>>>> /mboards/0/xbar/FFT_0/args/0/shift/value >>>>> /mboards/0/xbar/FFT_0/args/0/direction >>>>> /mboards/0/xbar/FFT_0/args/0/direction/type >>>>> /mboards/0/xbar/FFT_0/args/0/direction/value >>>>> /mboards/0/xbar/FFT_0/args/0/scaling >>>>> /mboards/0/xbar/FFT_0/args/0/scaling/type >>>>> /mboards/0/xbar/FFT_0/args/0/scaling/value >>>>> /mboards/0/xbar/FFT_0/args/0/otype >>>>> /mboards/0/xbar/FFT_0/args/0/otype/type >>>>> /mboards/0/xbar/FFT_0/args/0/otype/value >>>>> /mboards/0/xbar/FFT_0/args/0/reset >>>>> /mboards/0/xbar/FFT_0/args/0/reset/type >>>>> /mboards/0/xbar/FFT_0/args/0/reset/value >>>>> /mboards/0/xbar/FFT_0/args/0/magnitude_out >>>>> /mboards/0/xbar/FFT_0/args/0/magnitude_out/type >>>>> /mboards/0/xbar/FFT_0/args/0/magnitude_out/value >>>>> /mboards/0/time >>>>> /mboards/0/time/now >>>>> /mboards/0/time/pps >>>>> /mboards/0/time/cmd >>>>> /mboards/0/time_source >>>>> /mboards/0/time_source/value >>>>> /mboards/0/time_source/options >>>>> /mboards/0/rx_codecs >>>>> /mboards/0/rx_codecs/A >>>>> /mboards/0/rx_codecs/A/name >>>>> /mboards/0/rx_codecs/A/gains >>>>> /mboards/0/tx_codecs >>>>> /mboards/0/tx_codecs/A >>>>> /mboards/0/tx_codecs/A/name >>>>> /mboards/0/tx_codecs/A/gains >>>>> /mboards/0/gpio >>>>> /mboards/0/gpio/INT0 >>>>> /mboards/0/gpio/INT0/SRC >>>>> /mboards/0/gpio/INT0/CTRL >>>>> /mboards/0/gpio/INT0/DDR >>>>> /mboards/0/gpio/INT0/OUT >>>>> /mboards/0/gpio/INT0/ATR_0X >>>>> /mboards/0/gpio/INT0/ATR_RX >>>>> /mboards/0/gpio/INT0/ATR_TX >>>>> /mboards/0/gpio/INT0/ATR_XX >>>>> /mboards/0/gpio/INT0/READBACK >>>>> /mboards/0/rx_dsps >>>>> /mboards/0/rx_dsps/0 >>>>> /mboards/0/rx_dsps/0/stream_cmd >>>>> /mboards/0/rx_dsps/0/freq >>>>> /mboards/0/rx_dsps/0/freq/value >>>>> /mboards/0/rx_dsps/0/freq/range >>>>> /mboards/0/rx_dsps/0/rate >>>>> /mboards/0/rx_dsps/0/rate/value >>>>> /mboards/0/rx_dsps/1
Re: [USRP-users] E312 - Migrating OOT Modules to the USRP
Greetings EJ,
So, from the tutorial, they have you edit the gain.xml file, and this is
what I have for it.
gain
gain
B7DD64941A952AAC
Gain
128
gain
double
1.0
GE($gain, 0.0) AND LE($gain, 32767.0)
Invalid Gain!
SR_WRITE("GAIN", IROUND($gain))
in0
sc16
out0
sc16
There is an args value and it is declared as gain.
So from there, I followed your second suggestion and tried to find where it
was installed when I did the cross compile. It was not placed in the
"GRC_BLOCKS_PATH" of "/share/gnuradio/grc/blocks" like the default RFNoC
blocks. It was instead placed in "/share/uhd/rfnoc/bocks" so I added that
to the setup.env file, included below.
LOCALPREFIX=~/newinstall/usr
export PATH=$LOCALPREFIX/bin:$PATH
export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export
GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
export GRC_BLOCKS_PATH=$LOCALPREFIX/share/uhd/rfnoc/blocks:$GRC_BLOCKS_PATH
Unfortunately, after re-sourcing the setup.env, I still get the same
message.
File "rfnoc_myGain_usrp.py", line 223, in
main()
File "rfnoc_myGain_usrp.py", line 212, in main
tb = top_block_cls(fpga_path=options.fpga_path,
rx_gain=options.rx_gain, rx_digital_gain=options.rx_digital_gain,
rx_freq=options.rx_freq, host_ip_addr=options.host_ip_addr)
File "rfnoc_myGain_usrp.py", line 117, in __init__
self.tutorial_gain_0.set_arg("gain", rx_digital_gain)
File
"/home/root/newinstall/usr/lib/python2.7/site-packages/tutorial/tutorial_swig.py",
line 315, in set_arg
return _tutorial_swig.gain_sptr_set_arg(self, *args)
RuntimeError: LookupError: Path not found in tree:
/mboards/0/xbar/gain_0/args/0/gain/value
I looked at some of your examples (which have been very helpful to get me
this far) from what I believe is your github someone linked me. Everything
appears to match what it should, for what gain is trying to accomplish.
Regards,
Jon
On Thu, Nov 21, 2019 at 3:27 PM EJ Kreinar wrote:
> Hi Jon,
>
> The rfnoc "nocscript" xml definition can create arguments and attach to
> the device tree like you are trying to set there (it's not compiled
> directly, but rather created dynamically from the xml definition)
>
> Recommended debugging...
> 1. Check your OOT gain block xml (in rfnoc/blocks) and make sure it has a
> "gain" field in the "args" list. You'll also want to make sure it writes
> your desired register, but I don't think you're even getting that far
> 2. Make sure the block xml is installed on the e310 embedded prefix and is
> found at run time during uhd_usrp_probe and when running your application.
> If it's not in the right place or not attaching to your block then it won't
> create the gain argument
>
> I'm guessing it's one of those two possibilities...
> EJ
>
> On Thu, Nov 21, 2019, 3:19 PM Jonathan Lockhart via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Greetings,
>>
>> I was able to get the ARM cross compile working. I removed the build
>> directory and re-sourced the dev environment and then the cross-compile
>> used the -mfloar=hard flag. Not sure what caused the issue earlier and why
>> it wasn't picking it up.
>>
>> Now I have a different issue. So I have completed this guide:
>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>>
>> I modified the GNURadio just a bit so that the output from gain was
>> placed on a ZMQ push, and the graphics were on the host to graph the signal
>> (seen in the screenshots below).
>>
>> [image: Screenshot from 2019-11-21 15-06-33.jpg]
>>
>> [image: Screenshot from 2019-11-21 15-010-44.jpg]
>>
>> However, when I run the top file for the USRP, I am running into this
>> error.
>>
>> Traceback (most recent call last):
>> File "rfnoc_myGain_usrp.py", line 223, in
>> main()
>> File "rfnoc_myGain_usrp.py", line 212, in main
>> tb = top_block_cls(fpga_path=options.fpga_path,
>> rx_gain=options.rx_gain, rx_digital_gain=options.rx_digital_gain,
>> rx_freq=options.rx_freq, host_ip_addr=options.host_ip_addr)
>> File "rfnoc_myGain_usrp.py", line 117, in __init__
>> self.tutorial_gain_0.set_arg("gain", rx_digital_gain)
>> Fil
Re: [USRP-users] E312 - Migrating OOT Modules to the USRP
Also, when I compiled from the OOT directory for ARM, I used this command,
which I pieced together from the RFNoC build guide, and the release-4 guide
for cross-compiling gr-ettus.
cmake
-DCMAKE_TOOLCHAIN_FILE=~/rfnoc/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
-DCMAKE_INSTALL_PREFIX=/usr
-DUHD_FPGA_DIR="/home/jon/rfnoc/src/uhd/fpga-src/" ../
Regards,
Jon
On Thu, Nov 21, 2019 at 3:48 PM Jonathan Lockhart
wrote:
> Greetings EJ,
>
> So, from the tutorial, they have you edit the gain.xml file, and this is
> what I have for it.
>
>
>
>
> gain
> gain
>
> B7DD64941A952AAC
>
>
>
>
> Gain
> 128
>
>
>
>
>
> gain
> double
> 1.0
> GE($gain, 0.0) AND LE($gain, 32767.0)
> Invalid Gain!
>
> SR_WRITE("GAIN", IROUND($gain))
>
>
>
>
>
>
> in0
> sc16
>
>
> out0
> sc16
>
>
>
>
> There is an args value and it is declared as gain.
>
> So from there, I followed your second suggestion and tried to find where
> it was installed when I did the cross compile. It was not placed in the
> "GRC_BLOCKS_PATH" of "/share/gnuradio/grc/blocks" like the default RFNoC
> blocks. It was instead placed in "/share/uhd/rfnoc/bocks" so I added that
> to the setup.env file, included below.
>
> LOCALPREFIX=~/newinstall/usr
> export PATH=$LOCALPREFIX/bin:$PATH
> export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
> export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
> export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
> export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
> export
> GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
> export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
> export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
> export GRC_BLOCKS_PATH=$LOCALPREFIX/share/uhd/rfnoc/blocks:$GRC_BLOCKS_PATH
>
> Unfortunately, after re-sourcing the setup.env, I still get the same
> message.
>
> File "rfnoc_myGain_usrp.py", line 223, in
> main()
> File "rfnoc_myGain_usrp.py", line 212, in main
> tb = top_block_cls(fpga_path=options.fpga_path,
> rx_gain=options.rx_gain, rx_digital_gain=options.rx_digital_gain,
> rx_freq=options.rx_freq, host_ip_addr=options.host_ip_addr)
> File "rfnoc_myGain_usrp.py", line 117, in __init__
> self.tutorial_gain_0.set_arg("gain", rx_digital_gain)
> File
> "/home/root/newinstall/usr/lib/python2.7/site-packages/tutorial/tutorial_swig.py",
> line 315, in set_arg
> return _tutorial_swig.gain_sptr_set_arg(self, *args)
> RuntimeError: LookupError: Path not found in tree:
> /mboards/0/xbar/gain_0/args/0/gain/value
>
> I looked at some of your examples (which have been very helpful to get me
> this far) from what I believe is your github someone linked me. Everything
> appears to match what it should, for what gain is trying to accomplish.
>
> Regards,
> Jon
>
> On Thu, Nov 21, 2019 at 3:27 PM EJ Kreinar wrote:
>
>> Hi Jon,
>>
>> The rfnoc "nocscript" xml definition can create arguments and attach to
>> the device tree like you are trying to set there (it's not compiled
>> directly, but rather created dynamically from the xml definition)
>>
>> Recommended debugging...
>> 1. Check your OOT gain block xml (in rfnoc/blocks) and make sure it has a
>> "gain" field in the "args" list. You'll also want to make sure it writes
>> your desired register, but I don't think you're even getting that far
>> 2. Make sure the block xml is installed on the e310 embedded prefix and
>> is found at run time during uhd_usrp_probe and when running your
>> application. If it's not in the right place or not attaching to your block
>> then it won't create the gain argument
>>
>> I'm guessing it's one of those two possibilities...
>> EJ
>>
>> On Thu, Nov 21, 2019, 3:19 PM Jonathan Lockhart via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Greetings,
>>>
>>> I was able to get the ARM cross compile working. I removed the build
>>> directory and re-sourced the dev environment and then the cross-compile
>>> used the -mfloar=hard flag. Not sure what caused the issue earlier and why
>>> it wasn't picking it up.
>>>
>>> Now I have a different issue. So I have completed this guide:
>>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>>>
>&
Re: [USRP-users] Issues Completing Radio Build and Installation
Greetings Nate, So been working through your instructions you linked and everything appears to be good on the software end. It is all cross-compiling and running on the E312. Unfortunately there appears to be a new issue. So when running the GUI for building an FGPA bit file, per the instructions, I have included an FFT, Window, and Fosphor, and selected the option to "File with FIFOS," which causes the build to fail. The GUI reports for the E310_SG3 it can support 14 blocks. I tested this with the command line version and 14 also fails. The instructions show a command line option of 5 modules (blocks) which builds fine. If I up it to 6 it immediately fails. I have attached a copy of the failure output as a .txt file for 6 blocks. Regards, Jon On Fri, Oct 11, 2019 at 2:51 PM Jonathan Lockhart wrote: > Greetings Nate, > > Thanks for getting back to me so quickly. I will be sure to flash the OS > to release 4 and roll back my dev environment to match the instructions. > > Regards, > Jon Lockhart > > > On Fri, Oct 11, 2019, 1:20 PM Nate Temple wrote: > >> Hi Jon, >> >> If you are following this app note [0], I would recommend starting with >> the release-4 image. The pre-3.15 MPM based image that has been released is >> currently a "beta" release. It lacks several of the dependencies required >> to build out GNU Radio. We are working on a new release and hope to have it >> posted soon. >> >> [0] - >> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source >> >> >> Regards, >> Nate Temple >> >> On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart >> wrote: >> >>> Greetings Ettus Radio List, >>> >>> I have recently acquired and began using an Ettus E312 and have been >>> trying to configure the dev host and the cross compile environment. >>> Unfortunately I am having issues completing some of these tasks with the >>> pre-release version of 3.15 image that Ettus mentions you should use in the >>> manual for the E312. I forward those issues to support but have heard no >>> reply. Please refer below to the issues I am reporting. The GNURadio cross >>> compile issue with the SDK and environment is the more crucial one at the >>> moment. I was wondering if anyone else has been experiencing these issues >>> and if so how did you proceed to get it resolved. Is there an image, sdk, >>> GNURadio version that I should be using other than the 3.15 image and >>> instructions that Ettus currently recommends using until a stable RC is >>> provided? >>> >>> Thanks for your help and feedback. >>> >>> Regards, >>> Jon Lockhart >>> >>> >>> -- Forwarded message - >>> From: Jonathan Lockhart >>> Date: Mon, Oct 7, 2019 at 3:16 PM >>> Subject: Issues Completing Radio Build and Installation >>> To: >>> >>> >>> Greetings Ettus Support, >>> >>> I recently acquired an Ettus E312 and I was looking to do some >>> development on it. Unfortunately I am have been having some issues. The >>> manual via files.ettus.com and the "Getting Started" both failed to >>> provide a working environment. >>> >>> The farthest I got was downloading the meta section direction for the >>> E312 to get 3.15.0 image and sdk for the radio, and then following this >>> guide page for 3.14, correcting the UHD install accordingly to comply with >>> 3.15. (Guide >>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor >>> ) >>> >>> When mounting the cross compiled UHD folders via the instructions on the >>> radio, and using the uhd_usrp_probe command, there is an error checking for >>> the libusb_init information. >>> >>> root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe >>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; >>> UHD_3.15.0.HEAD-0-g6563c537 >>> [ERROR] [UHD] Device discovery error: AssertionError: >>> libusb_init(&_context) == 0 >>> in libusb_session_impl::libusb_session_impl() >>> at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36 >>> >>> [ERROR] [UHD] Device discovery error: AssertionError: >>> libusb_init(&_context) == 0 >>> in libusb_session_impl::libusb_session_impl() >>> at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36 >>> >>> [ERROR] [UHD] Device discovery error: AssertionError: >>> libusb_init(&_context) == 0 >>> in libusb_session_impl::libusb_session_impl() >>> at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36 >>> >>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >>> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg3,serial=313179A,claimed=False >>> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s). >>> [INFO] [MPM.PeriphManager] init() called with device args >>> `product=e310_sg3,mgmt_addr=127.0.0.1'. >>> [INFO] [0/Radio_0] Initializing block control (NOC ID: >>> 0x12AD10003310) >>> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) >>> [INFO] [0/DUC_0] Initializing block
Re: [USRP-users] RFNoC Radio Issue
Greetings Jason, I will give that a look. Seems like that is a change in the rfnoc block verilog and not the Python, so I can handle that if I find it. I am currently in 3.14.1.0 because that is the os version I am running. If I try 3.15 it errors out on the E312 bc the SD card image is missing necessary installed files. I have yet to venture into docker to try and build my own image. Do you know if this is corrected in the 3.14.1.1 release? Regards, Jon Lockhart On Fri, Nov 1, 2019, 2:11 PM Jason Matusiak wrote: > Jonathon, If you look at the more recent commits for UHD, they added in a > fix to the split_stream error. Basically you need to change a 1'b1 to a > 2'b11 in the noc_shell section (I think that is the section, I can't recall > off the top of my head). Try that and rebuild. > > -- > *From:* USRP-users on behalf of > Jonathan Lockhart via USRP-users > *Sent:* Thursday, October 31, 2019 3:30 PM > *To:* USRP-users@lists.ettus.com ; > supp...@ettus.com > *Subject:* Re: [USRP-users] RFNoC Radio Issue > > Apologies, the files are attached. > > On Thu, Oct 31, 2019 at 3:30 PM Jonathan Lockhart > wrote: > > Greetings, > > I was wondering if anyone else has had this issue with the RFNoC radio > block. > > So I was using the copy block with the rfnoc_fosphor_network_usrp.grc file > as I wanted to split off the signal before it went off to the RFNoC Window. > So I put in a copy block (since the RFNoC Split block appears to be broken) > and passed the data off to a ZMQ Push and back to the window to continue to > be processed by the FPGA. GNURadio says this is all well and good since all > vectors are 512 and builds the file. However, when I run the .py file on my > E312 it throws an error stating that the radio is providing data of size 8 > when the copy block expects to get data of size 512 (the vector size). > > [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; > UHD_3.14.1.HEAD-0-gbfb9c1c7 > [INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit... > [INFO] [E300] FPGA image loaded > [INFO] [E300] Detecting internal GPS > [INFO] [E300] GPSDO found > [INFO] [E300] Initializing core control (global registers)... > > [INFO] [E300] Performing register loopback test... > [INFO] [E300] Register loopback test passed > [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000) > [WARNING] [RFNOC] Can't find a block controller for key FFT, using default > block controller! > [INFO] [0/FFT_0] Initializing block control (NOC ID: 0xFF70) > [INFO] [0/Window_0] Initializing block control (NOC ID: 0xD053) > [WARNING] [RFNOC] Can't find a block controller for key fosphor, using > default block controller! > [INFO] [0/fosphor_0] Initializing block control (NOC ID: > 0x666F) > [INFO] [0/FIFO_0] Initializing block control (NOC ID: 0xF1F0) > [INFO] [0/FIFO_1] Initializing block control (NOC ID: 0xF1F0) > Traceback (most recent call last): > File "rfnoc_fosphor_network_usrp.py", line 282, in > main() > File "rfnoc_fosphor_network_usrp.py", line 271, in main > tb = top_block_cls(fft_size=options.fft_size, > fpga_path=options.fpga_path, freq=options.freq, gain=options.gain, > host_ip_addr=options.host_ip_addr, samp_rate=options.samp_rate, > tdecay=options.tdecay, trise=options.trise) > File "rfnoc_fosphor_network_usrp.py", line 166, in __init__ > self.connect((self.uhd_rfnoc_streamer_radio_0, 0), > (self.blocks_copy_0, 0)) > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", > line 47, in wrapped > func(self, src, src_port, dst, dst_port) > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/hier_block2.py", > line 110, in connect > self.primitive_connect(*args) > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", > line 3482, in primitive_connect > return _runtime_swig.top_block_sptr_primitive_connect(self, *args) > ValueError: itemsize mismatch: rfnoc_radio0:0 using 8, copy0:0 using 4096 > > I have attached my modified examples for anyone who is interested. I have > tried to modify the python and that just gets me into more trouble. > > Through my tracing of the files it appears that the RFNoC Radio block in > the .py file never actually uses the vector size, and that the force vector > length block is an additive to allow compliance when working in GNURadio, > as it will not generate python with mismatched types and sizes. Trying to > force the radio to take the 512 as an argument in the python throws a new > error that the
Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream
Greetings Nick and EJ, Yes you are correct, the split stream does require a FIFO after the output if I want to port to the arm or ZMQ. That resolved the run error. EJ, Currently I am just modifying the default installation example that comes with UHD for the fosphor GNR files, and by default Ettus has it set to 56 MHz, which does appear to be a valid sample rate for the E312 SG3. I haven't seen any odd behavior with the default example, albeit I am still playing with the split stream so I may run into issues still. Regards, Jon On Thu, Nov 14, 2019 at 6:11 PM EJ Kreinar wrote: > Cool! > > I'll point out that your new build actually got past the old failure point > you noted before, which was immediately after attempting to interact with > the SplitStream RFNOC block! > > ``` > [INFO] [0/SplitStream_0] Initializing block control (NOC ID: > 0x5757) > [ERROR] [UHD] Exception caught in safe-call. > [...etc...] > ``` > > I second Nick's thought. Try adding a FIFO after the second split-stream > port. > > Though on further inspection, I actually doubt this particular application > would work at all, since it looks like you're trying to push 56 MHz > through the RFNoC FPGA->ARM transport and then through ZMQ. The E310 > definitely cannot handle that sort of load, and you might get undefined > behavior in RFNOC fosphor because the underflow will propagate back to the > RFNoC Radio and momentarily stop the RF stream before restarting... > > EJ > > On Thu, Nov 14, 2019 at 6:05 PM Nick Foster wrote: > >> I also haven't tested to see if this is a gr-ettus limitation or a UHD >> limitation. >> >> On Thu, Nov 14, 2019 at 3:04 PM Nick Foster wrote: >> >>> You can't have heterogenous output destinations on RFNoC blocks -- i.e., >>> you can't send one output to the host and one output to another RFNoC block. >>> >>> I'm not sure why this limitation exists as there is no architectural >>> reason I can see. >>> >>> Nick >>> >>> On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart < >>> jlockhar...@gmail.com> wrote: >>> >>>> Greetings EJ, >>>> >>>> So went and dug out the E312 b/c I couldn't wait and unfortunately that >>>> didn't resolve the issue I was experiencing. I cherry picked the new >>>> split_stream block, I am using the same flow graph as provided before, but >>>> when it goes to run on the E312 I get the following error. >>>> >>>> Traceback (most recent call last): >>>> File "rfnoc_fosphor_radio_network_usrp.py", line 281, in >>>> main() >>>> File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main >>>> tb.start() >>>> File >>>> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", >>>> line 109, in start >>>> top_block_start_unlocked(self._impl, max_noutput_items) >>>> File >>>> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", >>>> line 3671, in top_block_start_unlocked >>>> return _runtime_swig.top_block_start_unlocked(*args, **kwargs) >>>> RuntimeError: uhd_rfnoc_SplitStream(9): missing connection from output >>>> port 0 >>>> >>>> Looks like something is missing from the split stream. I assume it >>>> needs to be fixed in the verilog. >>>> >>>> I attached a screenshot of the new, cleaned up GNU radio file. I had to >>>> remove a FIFO and switch to using a throttle b/c I wasn't able to get it >>>> all to fit in the bit file. >>>> >>>> Regards, >>>> Jon >>>> >>>> On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart < >>>> jlockhar...@gmail.com> wrote: >>>> >>>>> Greetings EJ, >>>>> >>>>> Thanks for the info. I haven't had time to grab the new block as my >>>>> dev box is packed for moving this weekend. I will get it downloaded and >>>>> try >>>>> it as soon as I can. >>>>> >>>>> Regards, >>>>> Jon >>>>> >>>>> On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar wrote: >>>>> >>>>>> Hi there, >>>>>> >>>>>> Just want to chime in since I recently went through the upgrade >>>>>> process to UHD-3.14... >>>>>> >>>>>> Can you confirm you
[USRP-users] E312 - Migrating OOT Modules to the USRP
Greetings, I am having some issues completing the RFNOC build tutorial on the Ettus E312. The reference documentation is using an X3xx series radio, and from the final python script it appears to be running the GNR script natively on the host. I built the exact script from the KB but when running on the radio it fails stating it can't "import tutorial." I realized all the files that were installed were placed on the host but not cross compiled for the E3xx using the SDK and ARM cross compile tool. I tried to complete this task, but unfortunately the compilation dies here. /home/jon/rfnoc/oe/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-soft.h: No such file or directory # include ^~ compilation terminated. Now I did find the stubs-soft.h file in the libc6-dev-armel-cross in the apt repo. I installed it and tried to cp the file into the /home/jon/rfnoc/oe/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/gnu/ location but it still doesn't like that. I verified that on my echo $CC that the -mfloat is set to hard as shown here. jon@jon-OptiPlex-9020:~/rfnoc/src/rfnoc-tutorial$ echo $CC arm-oe-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon --sysroot=/home/jon/rfnoc/oe/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi So I am not sure why the gain module in the tutorial is looking for the soft file. If anyone has experience in porting their OOT modules over to the E-series of radios I would appreciate the help. Regards, Jon ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues Completing Radio Build and Installation
Greetings Nate, Thanks for getting back to me so quickly. I will be sure to flash the OS to release 4 and roll back my dev environment to match the instructions. Regards, Jon Lockhart On Fri, Oct 11, 2019, 1:20 PM Nate Temple wrote: > Hi Jon, > > If you are following this app note [0], I would recommend starting with > the release-4 image. The pre-3.15 MPM based image that has been released is > currently a "beta" release. It lacks several of the dependencies required > to build out GNU Radio. We are working on a new release and hope to have it > posted soon. > > [0] - > https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source > > > Regards, > Nate Temple > > On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart > wrote: > >> Greetings Ettus Radio List, >> >> I have recently acquired and began using an Ettus E312 and have been >> trying to configure the dev host and the cross compile environment. >> Unfortunately I am having issues completing some of these tasks with the >> pre-release version of 3.15 image that Ettus mentions you should use in the >> manual for the E312. I forward those issues to support but have heard no >> reply. Please refer below to the issues I am reporting. The GNURadio cross >> compile issue with the SDK and environment is the more crucial one at the >> moment. I was wondering if anyone else has been experiencing these issues >> and if so how did you proceed to get it resolved. Is there an image, sdk, >> GNURadio version that I should be using other than the 3.15 image and >> instructions that Ettus currently recommends using until a stable RC is >> provided? >> >> Thanks for your help and feedback. >> >> Regards, >> Jon Lockhart >> >> >> -- Forwarded message - >> From: Jonathan Lockhart >> Date: Mon, Oct 7, 2019 at 3:16 PM >> Subject: Issues Completing Radio Build and Installation >> To: >> >> >> Greetings Ettus Support, >> >> I recently acquired an Ettus E312 and I was looking to do some >> development on it. Unfortunately I am have been having some issues. The >> manual via files.ettus.com and the "Getting Started" both failed to >> provide a working environment. >> >> The farthest I got was downloading the meta section direction for the >> E312 to get 3.15.0 image and sdk for the radio, and then following this >> guide page for 3.14, correcting the UHD install accordingly to comply with >> 3.15. (Guide >> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor >> ) >> >> When mounting the cross compiled UHD folders via the instructions on the >> radio, and using the uhd_usrp_probe command, there is an error checking for >> the libusb_init information. >> >> root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe >> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600; >> UHD_3.15.0.HEAD-0-g6563c537 >> [ERROR] [UHD] Device discovery error: AssertionError: >> libusb_init(&_context) == 0 >> in libusb_session_impl::libusb_session_impl() >> at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36 >> >> [ERROR] [UHD] Device discovery error: AssertionError: >> libusb_init(&_context) == 0 >> in libusb_session_impl::libusb_session_impl() >> at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36 >> >> [ERROR] [UHD] Device discovery error: AssertionError: >> libusb_init(&_context) == 0 >> in libusb_session_impl::libusb_session_impl() >> at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36 >> >> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg3,serial=313179A,claimed=False >> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s). >> [INFO] [MPM.PeriphManager] init() called with device args >> `product=e310_sg3,mgmt_addr=127.0.0.1'. >> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003310) >> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) >> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2) >> [INFO] [0/Radio_0] RX freq = 2.4e+09 >> [INFO] [0/Radio_0] RX band = 6 >> [INFO] [0/Radio_0] RX SW1 = 5 >> [INFO] [0/Radio_0] RX SWC = 0 >> [INFO] [0/Radio_0] RX SWB = 1 >> [INFO] [0/Radio_0] RX VCRX_SW = 1 >> [INFO] [0/Radio_0] RX VCTXRX_SW = 0 >> [INFO] [0/Radio_0] RX freq = 2.4e+09 >> [INFO] [0/Radio_0] RX band = 6 >> [INFO] [0/Radio_0] RX SW1 = 5 >> [INFO] [0/Radio_0] RX SWC = 0 >> [INFO] [0/Radio_0] RX SWB = 1 >> [INFO] [0/Radio_0] RX VCRX_SW = 1 >> [INFO] [0/Radio_0] RX VCTXRX_SW = 0 >> [INFO] [0/Radio_0] RX freq = 2.4e+09 >> [INFO] [0/Radio_0] RX band = 6 >> [INFO] [0/Radio_0] RX SW1 = 5 >> [INFO] [0/Radio_0] RX SWC = 0 >> [INFO] [0/Radio_0] RX SWB = 1 >> [INFO] [0/Radio_0] RX VCRX_SW = 1 >> [INFO] [0/Radio_0] RX VCTXRX_SW = 0 >> [INFO] [0/Radio_0] RX freq = 2.4e+09 >> [INFO] [0/Radio_0] RX band = 6 >> [INFO] [0/Radio_0] RX SW1 = 5 >> [INFO] [0/Radio_0] RX SWC = 0 >>
