[USRP-users] Error RFnOC USRP E310

[Ivan Zahartchuk via USRP-users]

Hello. I'm having an error after installing the software-office. Tell me
how can I fix this error ??
root@ettus-e3xx-sg3:~/newinstall/usr/lib/uhd/examples# ./rx_samples_to_file
--freq 100e6 --gain 0 --ant TX/RX --rate 1e6 --null

Creating the usrp device with: ...
[INFO] [UHDlinux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.rfnoc-ofdm-408-gf3a40f9a]
[INFO] [E300] Loading FPGA image:
/home/root/newinstall/usr/share/uhd/images/usrp_e310_fpga_sg3.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Initializing core control (global registers)...

[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[WARNING] [RFNOC] [0/fosphor_0] defines 2 input buffer sizes, but 1 input
ports
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [AD936X] Performing CODEC loopback test...
[INFO] [AD936X] CODEC loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [E300] Loading FPGA image:
/home/root/newinstall/usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit...
[INFO] [E300] FPGA image loaded
[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/jammer/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
  in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr]
  at /home/jammer/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257

[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/jammer/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
  in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr]
  at /home/jammer/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257

[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/jammer/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
  in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr]
  at /home/jammer/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257

[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/jammer/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
  in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr]
  at /home/jammer/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257

[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/jammer/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
  in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr]
  at /home/jammer/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257

[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/jammer/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
  in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr]
  at /home/jammer/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257

[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/jammer/e300/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> AssertionError: (sts >> 7) & 0x1
  in typename T::sptr e300_transport::get_buff(double) [with T =
uhd::transport::managed_send_buffer; typename T::sptr =
boost::intrusive_ptr]
  at /home/jammer/e300/src/uhd/host/lib/usrp/e300/e300_fifo_config.cpp:257

Error: RuntimeError: On node 0/FIFO_0, output port 0 is already connected.



Thanks for any help.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD not compatible with FPGA master noc_shell

[Juan Francisco via USRP-users]

It seems that this issue has tripped up several people.  It might be
prudent to not push the FPGA changes to master until you have the
corresponding UHD updates ready to go.

On Thu, Aug 30, 2018 at 12:49 PM Brent Stapleton 
wrote:

> Hi Juan,
>
> In general, FPGA images built from the submodule in the uhd repository
> will be compatible with UHD built from that commit. The HEADs of the two
> master branches (uhd and fpga) do not have that guarantee. For example, the
> HEAD of uhd master branch (as I write this email) is the git
> commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga.
> Those both use NoC shell compat number 4.
>
> We'll get the noc shell compat 5 changes out ASAP though, so don't throw
> away that image.
>
> Regards,
> Brent
>
> On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> There appears to be a compatibility mismatch for the latest FPGA master
>> and UHD.  I built a new image from fpga master today, but uhd_usrp_probe
>> from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message below:
>>
>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>> 0xF1F0D000)
>> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
>> Expecting 4, got 5.
>> Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
>> supports revision 4. Please either upgrade UHD  (recommended) or downgrade
>> the FPGA image.
>>
>> Thanks,
>> Juan
>> ___
>> 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

[USRP-users] Issue with rfnocmodtool generated NOC IDs with leading 0's

[Andrew Danowitz via USRP-users]

I used rfnocmodtool from UHD3.13 to generate a new noc block. The id it
assigned the block had a leading 0. Unfortunately, the tool appears to have
dropped the leading 0 in the auto-generated xml file, which led to grc and
uhd_usrp_probe not being able to find the controller and name for the block.

I don't know if this has been fixed in the latest version, but definitely
something to look into.

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD not compatible with FPGA master noc_shell

[Andrew Danowitz via USRP-users]

As a note, these mismatches can occur if you use pybombs to manage your
install and do pybombs update uhd-fpga. If you're a pybombs user, my
recommendation is to ignore the uhd-fpga directory altogether, and from
within uhd/fpga run git submodule init, followed by git pull.

Brent, is this something ettus can change in the pybombs recipes?

Thanks,
Andrew

On Thu, Aug 30, 2018 at 9:49 AM, Brent Stapleton via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Juan,
>
> In general, FPGA images built from the submodule in the uhd repository
> will be compatible with UHD built from that commit. The HEADs of the two
> master branches (uhd and fpga) do not have that guarantee. For example, the
> HEAD of uhd master branch (as I write this email) is the git
> commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga.
> Those both use NoC shell compat number 4.
>
> We'll get the noc shell compat 5 changes out ASAP though, so don't throw
> away that image.
>
> Regards,
> Brent
>
> On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> There appears to be a compatibility mismatch for the latest FPGA master
>> and UHD.  I built a new image from fpga master today, but uhd_usrp_probe
>> from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message below:
>>
>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>> 0xF1F0D000)
>> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
>> Expecting 4, got 5.
>> Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
>> supports revision 4. Please either upgrade UHD  (recommended) or downgrade
>> the FPGA image.
>>
>> Thanks,
>> Juan
>> ___
>> 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
>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B205-mini GPIO

[Derek Kozel via USRP-users]

Hello Arun,

The gpio example is the first place to look for a reference.
https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp

A description of the GPIO header on the B20xmini can be found here
http://files.ettus.com/manual/page_usrp_b200.html#b200_hw_ref_ext

Regards,
Derek

On Thu, Aug 30, 2018 at 7:43 PM, Arun kumar Verma via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi
>
> We brought B205mini recently and we want to use three GPIO to control some
> external device which require SPI interface, in the schematics the header
> mentioned is J5 for GPIO while website USRP Hardware Driver and USRP
> Manual: USRP B2x0 Series
>  is mentioning J6 as
> GPIO header. Can you please suggest some example source code for GPIO, so
> that we can incorporate in our software.
>
> Arun Verma
>
> USRP Hardware Driver and USRP Manual: USRP B2x0 Series
> 
>
>
> ___
> 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

Re: [USRP-users] B205-mini GPIO

[Marcus Müller via USRP-users]

Hi Arun,

in the uhd/host/examples directory, you'll find gpio.cpp !

Note that you'll need to bitbang SPI that way from the host; that can
work, but it's going to be slow.

Alternatively, if you are familiar with FPGA development, implementing
another SPI host in the FPGA should be thoroughly possible. You'd then
need to find a smart way to talk to the SPI controller from the host,
which I'd say is the bigger challenge.

Honestly, if you just need *something* to talk SPI, getting an USB-to-
SPI adapter (of the popular FTDI variety, for example) is probably way,
way easier and faster. If you need timed execution of SPI transactions,
you could also combine the two: Use an easy-to-use SPI bridge or
microcontroller or … and just (de)assert the CS line of SPI using timed
commands and the standard GPIO.

From a bit of a long-time support perspective: 90% of people don't
actually need their GPIOs to talk full protocols; if your application
needs that, a minor adjustment to architecture is often easier.

Best regards,
Marcus
 
On Thu, 2018-08-30 at 18:43 +, Arun kumar Verma via USRP-users
wrote:
> Hi
> 
> We brought B205mini recently and we want to use three GPIO to control
> some external device which require SPI interface, in the schematics
> the header mentioned is J5 for GPIO while website USRP Hardware
> Driver and USRP Manual: USRP B2x0 Series is mentioning J6 as GPIO
> header. Can you please suggest some example source code for GPIO, so
> that we can incorporate in our software.
> 
> Arun Verma
> 
>USRP Hardware Driver and USRP Manual: USRP B2x0 Series   
> 
> ___
> 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

[USRP-users] B205-mini GPIO

[Arun kumar Verma via USRP-users]

Hi
We brought B205mini recently and we want to use three GPIO to control some 
external device which require SPI interface, in the schematics the header 
mentioned is J5 for GPIO while website USRP Hardware Driver and USRP Manual: 
USRP B2x0 Series is mentioning J6 as GPIO header. Can you please suggest some 
example source code for GPIO, so that we can incorporate in our software.
Arun Verma

  
|  
|   |  
USRP Hardware Driver and USRP Manual: USRP B2x0 Series
   |  |

  |

 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 FPGA image mismatch with UHD

[Brent Stapleton via USRP-users]

Hi Jose,

In general, FPGA images built from the submodule in the uhd repository will
be compatible with UHD built from that commit. The HEADs of the two master
branches (uhd and fpga) do not have that guarantee. For example, the HEAD
of uhd master branch (as I write this email) is the git commit 3b42e6f0,
and the submodule points to the commit c3987555 on fpga. Those both use NoC
shell compat number 4.

We'll get the noc shell compat 5 changes out ASAP though, so don't throw
away that image.

Regards,
Brent

On Thu, Aug 30, 2018 at 7:51 AM Avila, Jose A via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
> I created an image for the N310 with the fpga master branch commit
> 615d9b8eeb94ee2d19c3b1e7aa526d4999495e05.
>
> I have UHD installed master branch commit
> 3b42e6f029f0d3de0f54d720964357aa0a32986f. When I go to probe the N310 I
> get the following error
>
>
> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
> Expecting 4, got 5.
> [ERROR] [MPMD] Failure during block enumeration: RuntimeError: FPGA
> component `noc_shell' is revision 5 and UHD supports revision 4. Please
> either upgrade UHD  (recommended) or downgrade the FPGA image.
> Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
>
> Which fpga commit do I need to downgrade to in order to get a compatible
> FPGA image?
> ___
> 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

Re: [USRP-users] UHD not compatible with FPGA master noc_shell

[Brent Stapleton via USRP-users]

Hi Juan,

In general, FPGA images built from the submodule in the uhd repository will
be compatible with UHD built from that commit. The HEADs of the two master
branches (uhd and fpga) do not have that guarantee. For example, the HEAD
of uhd master branch (as I write this email) is the git commit 3b42e6f0,
and the submodule points to the commit c3987555 on fpga. Those both use NoC
shell compat number 4.

We'll get the noc shell compat 5 changes out ASAP though, so don't throw
away that image.

Regards,
Brent

On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
usrp-users@lists.ettus.com> wrote:

> There appears to be a compatibility mismatch for the latest FPGA master
> and UHD.  I built a new image from fpga master today, but uhd_usrp_probe
> from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message below:
>
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
> Expecting 4, got 5.
> Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
> supports revision 4. Please either upgrade UHD  (recommended) or downgrade
> the FPGA image.
>
> Thanks,
> Juan
> ___
> 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

Re: [USRP-users] Ettus AN 315 Building rfnoc-devel UHD failure:

[Marcus D. Leech via USRP-users]

On 08/30/2018 12:59 AM, Bob Conley via USRP-users wrote:
While following the  procedure outlined in AN315 "Software Development 
on the E3xx USRP - Building RFNoC UHD / GNU Radio / gr-ettus from 
Source"  I get the following error during make in the "Building 
rfnoc-devel UHD" procedure:


Tail of console output
-
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/single_pole_iir_filter_cc_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/single_pole_iir_filter_ff_impl.cc.o
[ 76%] Linking CXX shared library libgnuradio-filter-3.7.10.2.so 


[ 76%] Built target gnuradio-filter
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
e310@edcf-vv-pc:~/rfnoc/gnuradio/build$ vi 
transcript_GNU_Radio_v3.7.10.2_Fail

---
Is the recipe for E310 development broken?

Any Ideas on how to proceed in building a E310 focused environment are 
appreciated.

Development OS is Ubuntu 16.04
Regards,
Bob


a more complete tail with first errors leading up to termination of 
the make process:

--
[ 75%] Building CXX object 
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_sc_list.cc.o
[ 75%] Building CXX object 
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/fractional_interpolator_ff_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/fractional_resampler_cc_impl.cc.o
/home/e310/rfnoc/gnuradio/gr-fec/lib/polar_decoder_common.cc: In 
member function ‘void 
gr::fec::code::polar_decoder_common::butterfly_volk(float*, unsigned 
char*, int, int, int)’:
/home/e310/rfnoc/gnuradio/gr-fec/lib/polar_decoder_common.cc:128:95: 
error: too many arguments to function
 volk_32f_8u_polarbutterfly_32f(llrs, u, block_size(), 
block_power(), stage, u_num, row);

   ^
gr-fec/lib/CMakeFiles/gnuradio-fec.dir/build.make:1070: recipe for 
target 
'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o' failed
make[2]: *** 
[gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o] Error 1

make[2]: *** Waiting for unfinished jobs
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/fractional_resampler_ff_impl.cc.o
CMakeFiles/Makefile2:4632: recipe for target 
'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all' failed

make[1]: *** [gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/hilbert_fc_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/iir_filter_ffd_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/iir_filter_ccc_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/iir_filter_ccf_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/iir_filter_ccd_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/iir_filter_ccz_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_arb_resampler.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_arb_resampler_ccf_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_arb_resampler_ccc_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_arb_resampler_fff_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_channelizer_ccf_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_decimator_ccf_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_interpolator_ccf_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/pfb_synthesizer_ccf_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/single_pole_iir_filter_cc_impl.cc.o
[ 75%] Building CXX object 
gr-filter/lib/CMakeFiles/gnuradio-filter.dir/single_pole_iir_filter_ff_impl.cc.o
[ 76%] Linking CXX shared library libgnuradio-filter-3.7.10.2.so 


[ 76%] Built target gnuradio-filter
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
e310@edcf-vv-pc:~/rfnoc/gnuradio/build$ vi 
transcript_GNU_Radio_v3.7.10.2_Fail


--
Bob Conley
bconle...@gmail.com 
509-953-2182


This looks to me like a mis-match between GR and VOLK -- like they 
weren't both at compatible versions during the build.




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] N310 FPGA image mismatch with UHD

[Avila, Jose A via USRP-users]

Hello,


I created an image for the N310 with the fpga master branch commit 
615d9b8eeb94ee2d19c3b1e7aa526d4999495e05.

I have UHD installed master branch commit  
3b42e6f029f0d3de0f54d720964357aa0a32986f. When I go to probe the N310 I get the 
following error


[ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell: Expecting 4, 
got 5.
[ERROR] [MPMD] Failure during block enumeration: RuntimeError: FPGA component 
`noc_shell' is revision 5 and UHD supports revision 4. Please either upgrade 
UHD  (recommended) or downgrade the FPGA image.
Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()


Which fpga commit do I need to downgrade to in order to get a compatible FPGA 
image?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210's FPGA programming dangers

[Javier Coronel (Expo Impex, S.L.) via USRP-users]

Michael and Sylvain, thank you very much for your answers!
I will start hacking right now!.

Have a nice day!



El jue., 30 ago. 2018 a las 15:42, Sylvain Munaut (<246...@gmail.com>)
escribió:

> Yeah the FPGA and even the FX3 are fully loaded from the host. There is
> nothing permanent written on the B2xx devices, so worst case you unplug /
> replug and it will reprogram everything starting from the FX3 ROM loader
> which you can't possible overwrite.
>
> As for FPGA mods, as long as you don't change the UCF/Pin Assignments,
> then it would be pretty hard to cause any damage to the board that a reboot
> wouldn't fix.
>
> Cheers,
>
> Sylvain
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210's FPGA programming dangers

[Sylvain Munaut via USRP-users]

Yeah the FPGA and even the FX3 are fully loaded from the host. There is
nothing permanent written on the B2xx devices, so worst case you unplug /
replug and it will reprogram everything starting from the FX3 ROM loader
which you can't possible overwrite.

As for FPGA mods, as long as you don't change the UCF/Pin Assignments, then
it would be pretty hard to cause any damage to the board that a reboot
wouldn't fix.

Cheers,

Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210's FPGA programming dangers

[Michael Don via USRP-users]

I'm pretty sure you can't break the loader by changing the FPGA image.  The
cypress IC handles the loading.  I've played around with the FPGA image a
lot, including some broken images, and never had a problem loading a new
image.

On Mon, Aug 27, 2018 at 4:38 PM Javier Coronel (Expo Impex, S.L.) via
USRP-users  wrote:

> Hi all!
>
> I want yo do some experiments on the FPGA firmware. Is there any danger on
> this?. I mean, can I accidentally break the firmware loader?
> Thank you all.
>
> --
>
>
>Un saludo,
>
>Javier Coronel
>
> Visite nuestra web: www.expoimpex.com
>
> ___
> 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