Re: [USRP-users] [EXT] Re: Configuration in sysctl.conf

[Johannes Demel via USRP-users]

Hi Daniele,

all of what you describe is intended behavior.

First off, UHD tells you *exactly* what to do. Run:
`sudo sysctl -w net.core.wmem_max=24862979`
Nothing else. Just copy the previous line without the ``.
The same goes for the rmem part.
These changes are valid as long as your machine runs. It is not a 
permanent change. Thus, you need to rerun this command after every 
reboot. This is also intended. Reasonable defaults are set for your 
everyday use. UHD does stress the network quite a lot with a lot of IQ 
samples, thus, you see a warning that tells you what to do to improve 
performance. Other applications might work worse then. But as long as 
you want to use a USRP and UHD, this is fine.

The whole `/proc` folder structure exists for the purpose that your 
Linux kernel communicates information to you. Lots of tools make use of 
that [0]. This is nothing UHD related but Linux in general. Certainly 
worthwhile to learn about it.
Starting from there, you can figure out what the actual command does and 
how you would proceed if you would want to make this change permanent.

Cheers
Johannes

[0] https://en.wikipedia.org/wiki/Procfs

Am 09.05.19 um 16:40 schrieb Disco Daniele via USRP-users:
> The number that seems configured every time I run uhd_usrp_probe is
> 
> 1048576 that is the value present in the file wmem_max in the directory
> 
> /proc/sys/net/core/
> 
> I searched also the way to modify this value and I found:
> 
> sudo -s -H
> 
> echo 24862979 > /proc/sys/net/core/wmem_max
> 
> If now I test the number present in the file:
> 
> cat   /proc/sys/net/core/wmem_max
> 
> the result is 24862979
> 
> and the command uhd_usrp_probe does not report warning.
> 
> But if I restart the linux box,
> 
> cat   /proc/sys/net/core/wmem_max
> 
> produce 1048576 again
> 
> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf 
> Of *Rob Kossler via USRP-users
> *Sent:* giovedì 9 maggio 2019 16:28
> *To:* Marcus D. Leech 
> *Cc:* usrp-users 
> *Subject:* [EXT] Re: [USRP-users] Configuration in sysctl.conf
> 
> Have you done the same for "rmem_max"?   Perhaps the continued warning 
> messages are related to this rather than wmem_max?
> 
> Rob
> 
> On Thu, May 9, 2019 at 10:01 AM Marcus D. Leech via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> 
> On 05/09/2019 08:25 AM, Disco Daniele via USRP-users wrote:
> 
> Hi!
> 
> I’m using a X310 on a linux box UBUNTU 18.04
> 
> Executing the command “uhd_usrp_probe”
> 
> I obtain a lot of [WARNING][UDP] related to the dimension of the
> send buffer
> 
> Then there is the sentence:
> 
> Please run: sudo sysctl -w net.core.wmem_max=24862979
> 
> So I’ve written in the file /etc/sysctl.conf, at the end
> 
> net.core.wmem_max=24862979
> 
> I restarted the host but rerunning uhd_usrp_probe I reobtain the
> same warning.
> 
> Could you help me?
> 
> PS: Now I’m using a 10GB Ethernet board plugged in the
> workstation, using a couple of fiber optics between the X310 and
> the work station
> 
> Thank you
> 
> Perhaps you have a syntax error in your sysctl file?
> 
> 
> 
> _
> 
> logo1
> 
> Direzione e Coordinamento Vivendi SA
> 
> *
> **Daniele Disco*
> *CT.TA.EI*
> 
> 
> Via Reiss Romoli, 274 – 10148 Torino
> tel . +39 011 228 7271
> cell. +39 331 600 1113
> 
> Fax. +39 06 4186 5196
> Tim Official: *Facebook*
>  - *Twitter*
> 
> *www.tim.it* 
> 
> Questo messaggio e i suoi allegati sono indirizzati
> esclusivamente alle persone indicate. La diffusione, copia o
> qualsiasi altra azione derivante dalla conoscenza di queste
> informazioni sono rigorosamente vietate. Qualora abbiate
> ricevuto questo documento per errore siete cortesemente pregati
> di darne immediata comunicazione al mittente e di provvedere
> alla sua distruzione, Grazie.
> 
> /This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please
> delete this message and any attachments and advise the sender by
> return e-mail, Thanks. /
> 
> *Rispetta l'ambiente. Non stampare questa mail se non è
> necessario.*
> 
> ___
> 
> USRP-users mailing list
> 
> USRP-users@lists.ettus.com  
> 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> ___

Re: [USRP-users] [EXT] Re: Configuration in sysctl.conf

[Disco Daniele via USRP-users]

OK!
Thank you Johannes for your clarifications!
Now I know that this is, as you say, the << intended behavior >>.

Best Regards
Daniele

-Original Message-
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
Johannes Demel via USRP-users
Sent: venerdì 10 maggio 2019 11:39
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] [EXT] Re: Configuration in sysctl.conf

Hi Daniele,

all of what you describe is intended behavior.

First off, UHD tells you *exactly* what to do. Run:
`sudo sysctl -w net.core.wmem_max=24862979` Nothing else. Just copy the 
previous line without the ``.
The same goes for the rmem part.
These changes are valid as long as your machine runs. It is not a permanent 
change. Thus, you need to rerun this command after every reboot. This is also 
intended. Reasonable defaults are set for your everyday use. UHD does stress 
the network quite a lot with a lot of IQ samples, thus, you see a warning that 
tells you what to do to improve performance. Other applications might work 
worse then. But as long as you want to use a USRP and UHD, this is fine.

The whole `/proc` folder structure exists for the purpose that your Linux 
kernel communicates information to you. Lots of tools make use of that [0]. 
This is nothing UHD related but Linux in general. Certainly worthwhile to learn 
about it.
Starting from there, you can figure out what the actual command does and how 
you would proceed if you would want to make this change permanent.

Cheers
Johannes

[0] https://en.wikipedia.org/wiki/Procfs

Am 09.05.19 um 16:40 schrieb Disco Daniele via USRP-users:
> The number that seems configured every time I run uhd_usrp_probe is
> 
> 1048576 that is the value present in the file wmem_max in the 
> directory
> 
> /proc/sys/net/core/
> 
> I searched also the way to modify this value and I found:
> 
> sudo -s -H
> 
> echo 24862979 > /proc/sys/net/core/wmem_max
> 
> If now I test the number present in the file:
> 
> cat   /proc/sys/net/core/wmem_max
> 
> the result is 24862979
> 
> and the command uhd_usrp_probe does not report warning.
> 
> But if I restart the linux box,
> 
> cat   /proc/sys/net/core/wmem_max
> 
> produce 1048576 again
> 
> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On 
> Behalf Of *Rob Kossler via USRP-users
> *Sent:* giovedì 9 maggio 2019 16:28
> *To:* Marcus D. Leech 
> *Cc:* usrp-users 
> *Subject:* [EXT] Re: [USRP-users] Configuration in sysctl.conf
> 
> Have you done the same for "rmem_max"?   Perhaps the continued warning 
> messages are related to this rather than wmem_max?
> 
> Rob
> 
> On Thu, May 9, 2019 at 10:01 AM Marcus D. Leech via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> 
> On 05/09/2019 08:25 AM, Disco Daniele via USRP-users wrote:
> 
> Hi!
> 
> I’m using a X310 on a linux box UBUNTU 18.04
> 
> Executing the command “uhd_usrp_probe”
> 
> I obtain a lot of [WARNING][UDP] related to the dimension of the
> send buffer
> 
> Then there is the sentence:
> 
> Please run: sudo sysctl -w net.core.wmem_max=24862979
> 
> So I’ve written in the file /etc/sysctl.conf, at the end
> 
> net.core.wmem_max=24862979
> 
> I restarted the host but rerunning uhd_usrp_probe I reobtain the
> same warning.
> 
> Could you help me?
> 
> PS: Now I’m using a 10GB Ethernet board plugged in the
> workstation, using a couple of fiber optics between the X310 and
> the work station
> 
> Thank you
> 
> Perhaps you have a syntax error in your sysctl file?
> 
> 
> 
> _
> 
> logo1
> 
> Direzione e Coordinamento Vivendi SA
> 
> *
> **Daniele Disco*
> *CT.TA.EI*
> 
> 
> Via Reiss Romoli, 274 – 10148 Torino
> tel . +39 011 228 7271
> cell. +39 331 600 1113
> 
> Fax. +39 06 4186 5196
> Tim Official: *Facebook*
>  - *Twitter*
> 
> *www.tim.it* 
> 
> Questo messaggio e i suoi allegati sono indirizzati
> esclusivamente alle persone indicate. La diffusione, copia o
> qualsiasi altra azione derivante dalla conoscenza di queste
> informazioni sono rigorosamente vietate. Qualora abbiate
> ricevuto questo documento per errore siete cortesemente pregati
> di darne immediata comunicazione al mittente e di provvedere
> alla sua distruzione, Grazie.
> 
> /This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please
> delete this message and any attachments and advise the sender by
> return e

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Ian, 

Very good, that’s encouraging at least.  Yes, I am familiar with using ISE 
iMPACT to load the FPGA with .bit code and even how to create the .bit from the 
associated .bin file and did try doing that earlier but perhaps not identically 
to your prescribed steps below.  I’ll revisit it.  I successfully built UHD 
003_009_000 earlier so I can probably also successfully build UHD 003_009_007 
too.  I’ll do that and give it a go.  I am familiar with the documents you 
mentioned.  Generally things have gone exactly as described right up until UHD 
needs to communicate with the stored images at which point it never does; so 
far anyway.

Thanks much for the additional information.  I’ll certainly hammer on it some 
more now that I have a few more pertinent details under my belt to guide the 
process appropriately. 

Joe

> On May 10, 2019, at 12:32 AM, Ian Buckley  wrote:
> 
> Joe, 
> This is generally all good news and somewhat hopeful. The fact you can ping 
> 192.168.10.2 in safe mode tell’s you that the FPGA has loaded an image from 
> Flash, that it’s passed CRC and booted the embedded micro controller on the 
> FPGA and run the firmware that replies to ICMP packets…that’s a sign the 
> hardware is in reasonable shape, regardless of what actually version of image 
> ins currently loaded. If you had the internal UART connected to a 3.3V 
> interface you would be seeing the FPGA and FW compatibility numbers for this 
> image printed at boot if it got this far.
> (Sorry if I’m telling you stuff you know here, too many messages in this 
> thread to go reread them)
> 
> You should now refer to these 2 pages:
> https://kb.ettus.com/N200/N210_Device_Recovery 
> 
> http://files.ettus.com/manual/page_usrp2.html#usrp2_load 
>  (N-series 
> sections, not USRP2)
> 
> The general outline of what to try is as follows:
> 1) Start with a relatively modern and stable UHD version: Any 3.9.x version 
> is pretty ideal, it’s well supported in Gnuradio, is perhaps the most stable, 
> and has N210 support. If you are building UHD yourself from GitHub, then 
> checkout the tag “release_003_009_007”.
> (Note there is no reason to look for old UHD versions to support your H/W, 
> the N210 specific code has changed very little for some time, but you will 
> benefit from much improved general UHD functionality and much better 
> community support)
> 2. (Given you understand how to load a new image via JTAG) Follow the 
> procedure outlined in “Unbricking an N Series Device”. Run 
> “uhd_images_downloader” under UHD3.9.x to be sure you have a compatible set 
> of FPGA images for this version of UHD. Use an R3 .bit file (Stay away from 
> R4 images since we know that is electrically incompatible with your H/W) and 
> load this via JTAG. Verify you can ping this once it’s loaded. Remember this 
> is a volatile load, no flash has changed yet, if you reset the H/W this 
> download is lost. The goal now is to use the embedded firmware in this JTAG 
> image to load the same images in .bin format via the ethernet network and 
> update both slot’s in the flash memory with non-volatile images that load 
> automatically after reset/power cycle.
> 3) Follow the instructions in 
> http://files.ettus.com/manual/page_usrp2.html#usrp2_load 
>  to perform the 
> image update via the network. You can also take a peek at the settings in 
> your EEPROM (“Recovery process” instructions) to verify that all fields are 
> sane and match your case label.
> 4) At this point, if all has gone as intended, USRP and UHD should be in 
> sync, power cycling H/W should work, and tools like “uhd_usrp_probe” should 
> find the USRP and print it’s detailed H/W config. There are a few common 
> useful things to check in the “Troubleshooting” section if things still don’t 
> seem to have worked.
> 
> -Ian
> 
> 
>> On May 9, 2019, at 2:48 PM, Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Oh, okay, I didn’t get that.  Understood now.  I have UHD 3.14.0 running on 
>> my main machine so I could try again some newer .bit files into the FPGA 
>> than I previously have tried (I tried the current version of UHD and N210 
>> usrp_n210_r4_fpga.bit to no avail) to see if any of them are compatible.  I 
>> also was able to build UHD 3.9.0 on a different machine so I can try that 
>> too with some of the other .bit files.  Will hold the safe button down while 
>> loading the FPGA this time around.  
>> 
>> Joe
>> 
>>> On May 9, 2019, at 3:38 PM, Nick Foster >> > wrote:
>>> 
>>> I'm saying that you might try to continue the effort to JTAG load a more 
>>> modern FPGA image. It's possible you have to hold down the safe mode button 
>>> while loading the image. 
>>> 
>>> On Thu, May 9, 2019, 2:22 PM Joe Martin >> > wrote:
>>> Thanks 

Re: [USRP-users] [EXT] Re: Configuration in sysctl.conf

[Marcus D. Leech via USRP-users]

On 05/10/2019 08:07 AM, Disco Daniele via USRP-users wrote:

OK!
Thank you Johannes for your clarifications!
Now I know that this is, as you say, the << intended behavior >>.

Best Regards
Daniele
Check for an overriding value in /etc/sysctl.conf.d in one of the files 
there.


If you just modified /etc/sys.conf, but there's another .conf file in 
/etc/sysctl.conf.d that specifies the same value, the one from

  /etc/sysctl.conf.d   takes precedence.




-Original Message-
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
Johannes Demel via USRP-users
Sent: venerdì 10 maggio 2019 11:39
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] [EXT] Re: Configuration in sysctl.conf

Hi Daniele,

all of what you describe is intended behavior.

First off, UHD tells you *exactly* what to do. Run:
`sudo sysctl -w net.core.wmem_max=24862979` Nothing else. Just copy the 
previous line without the ``.
The same goes for the rmem part.
These changes are valid as long as your machine runs. It is not a permanent 
change. Thus, you need to rerun this command after every reboot. This is also 
intended. Reasonable defaults are set for your everyday use. UHD does stress 
the network quite a lot with a lot of IQ samples, thus, you see a warning that 
tells you what to do to improve performance. Other applications might work 
worse then. But as long as you want to use a USRP and UHD, this is fine.

The whole `/proc` folder structure exists for the purpose that your Linux 
kernel communicates information to you. Lots of tools make use of that [0]. 
This is nothing UHD related but Linux in general. Certainly worthwhile to learn 
about it.
Starting from there, you can figure out what the actual command does and how 
you would proceed if you would want to make this change permanent.

Cheers
Johannes

[0] https://en.wikipedia.org/wiki/Procfs

Am 09.05.19 um 16:40 schrieb Disco Daniele via USRP-users:

The number that seems configured every time I run uhd_usrp_probe is

1048576 that is the value present in the file wmem_max in the
directory

/proc/sys/net/core/

I searched also the way to modify this value and I found:

sudo -s -H

echo 24862979 > /proc/sys/net/core/wmem_max

If now I test the number present in the file:

cat   /proc/sys/net/core/wmem_max

the result is 24862979

and the command uhd_usrp_probe does not report warning.

But if I restart the linux box,

cat   /proc/sys/net/core/wmem_max

produce 1048576 again

*From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
Behalf Of *Rob Kossler via USRP-users
*Sent:* giovedì 9 maggio 2019 16:28
*To:* Marcus D. Leech 
*Cc:* usrp-users 
*Subject:* [EXT] Re: [USRP-users] Configuration in sysctl.conf

Have you done the same for "rmem_max"?   Perhaps the continued warning
messages are related to this rather than wmem_max?

Rob

On Thu, May 9, 2019 at 10:01 AM Marcus D. Leech via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

 On 05/09/2019 08:25 AM, Disco Daniele via USRP-users wrote:

 Hi!

 I’m using a X310 on a linux box UBUNTU 18.04

 Executing the command “uhd_usrp_probe”

 I obtain a lot of [WARNING][UDP] related to the dimension of the
 send buffer

 Then there is the sentence:

 Please run: sudo sysctl -w net.core.wmem_max=24862979

 So I’ve written in the file /etc/sysctl.conf, at the end

 net.core.wmem_max=24862979

 I restarted the host but rerunning uhd_usrp_probe I reobtain the
 same warning.

 Could you help me?

 PS: Now I’m using a 10GB Ethernet board plugged in the
 workstation, using a couple of fiber optics between the X310 and
 the work station

 Thank you

 Perhaps you have a syntax error in your sysctl file?



 _

 logo1

 Direzione e Coordinamento Vivendi SA

 *
 **Daniele Disco*
 *CT.TA.EI*


 Via Reiss Romoli, 274 – 10148 Torino
 tel . +39 011 228 7271
 cell. +39 331 600 1113

 Fax. +39 06 4186 5196
 Tim Official: *Facebook*
  - *Twitter*
 
 *www.tim.it* 

 Questo messaggio e i suoi allegati sono indirizzati
 esclusivamente alle persone indicate. La diffusione, copia o
 qualsiasi altra azione derivante dalla conoscenza di queste
 informazioni sono rigorosamente vietate. Qualora abbiate
 ricevuto questo documento per errore siete cortesemente pregati
 di darne immediata comunicazione al mittente e di provvedere
 alla sua distruzione, Grazie.

 /This e-mail and any attachments is confidential and may contain
 privileged information intended for the addressee(s) only.
 Dissemination, copying, printing or use by anybody else is
 unauthor

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Ian and all, 

I have been very careful to avoid the pitfalls you detailed.  I began with a 
fresh installation of Ubuntu 18.04 then performed a successful build of UHD 
3.9.7, then used command:

uhd_images_downloader

to load the appropriate/associated images into the PC. 

Then used ISE iMPACT to load the “usrp_n210_r3_fpga.bit” file into the FPGA of 
the N210.  iMPACT reports “PROGRAM SUCCESSFUL”. 

Then without power cycling the N210 used the command: 

usrp_image_loader —args=“type=usrp2,addr=192.168.10.2,overwrite-safe” 
—fw-path=/usr/local/share/uhd/images/usrp_n210_fw.bin 
—fpga-path=/usr/local/share/uhd/images/usrp_n210_r3_fpga.bin

To load the non-volatile memory of the N210 but I always get the “RuntimeError: 
Received invalid 32 reply from device” error when running usrp_image_loader. 

I am able to successfully ping 192.168.10.2 but no matter what combinations of 
r2 or r3 .bit file and firmware and fpga image .bin files I use the response 
when invoking the usrp_image_loader is always the same, namely “invalid reply 
32 from device”.  

The command uhd_find_devices returns by reporting it can find a usrp2 device at 
address 192.168.10.2, as you would hope.  

After trying every conceivable combination of these actions with numerous 
versions of UHD and r2/r3 .bit FPGA files and r2/r3 .bin files on several fresh 
installations of Ubuntu 18.04 and 16.04 the result is always the same in that 
things proceed normally as the various documents concerning un-bricking an N210 
explains, until the step of using the usrp_image_loader is executed, at which 
point a RuntimeError returns stating that the “invalid 32 reply” has occurred.  

I was hopeful that careful use of rev3 .bit and .bin files with UHD 3.9.7 would 
do the trick but alas that is not the case.  

I suspect that you are near the bottom of the list of suggestions for me and I 
do appreciate the time and thinking you have afforded me on this issue.  If 
there is anything remaining to try I’d be most willing to try it. 

BTW, the suggestion made by someone earlier to try holding the safe button down 
during the loading of the FPGA from iMPACT causes the programming to fail (as 
reported by iMPACT), so that’s apparently not a good thing to do.  But one can 
recover from that state by simply by re-programming with the safe button not 
held but the fundamental problem with the uhd_image_loader step in the 
unbricking process always seems to result. 

Joe

> On May 10, 2019, at 9:31 AM, Ian Buckley  wrote:
> 
> Joe, 
> To save you time, It may well be worth you trying jumping to the 3) step 
> initially and seeing if your current loaded image or safe image is capable of 
> being upgraded …it likely is since that protocol is widely compatible across 
> UHD variants. The key here I have to emphasize (since you appear to have been 
> previously getting stuck with incompatibility between whatever is loaded in 
> the USRP and your host UHD installation) is to be sure your new UHD 
> installation is the only one on your system, and that you have the binary 
> images that are version matched with it…people often get caught out by 
> reminants of various UHD versions installed in various system directories 
> from different install methods.
> -Ian
> 
>> On May 10, 2019, at 5:58 AM, Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Ian, 
>> 
>> Very good, that’s encouraging at least.  Yes, I am familiar with using ISE 
>> iMPACT to load the FPGA with .bit code and even how to create the .bit from 
>> the associated .bin file and did try doing that earlier but perhaps not 
>> identically to your prescribed steps below.  I’ll revisit it.  I 
>> successfully built UHD 003_009_000 earlier so I can probably also 
>> successfully build UHD 003_009_007 too.  I’ll do that and give it a go.  I 
>> am familiar with the documents you mentioned.  Generally things have gone 
>> exactly as described right up until UHD needs to communicate with the stored 
>> images at which point it never does; so far anyway.
>> 
>> Thanks much for the additional information.  I’ll certainly hammer on it 
>> some more now that I have a few more pertinent details under my belt to 
>> guide the process appropriately. 
>> 
>> Joe
>> 
>>> On May 10, 2019, at 12:32 AM, Ian Buckley >> > wrote:
>>> 
>>> Joe, 
>>> This is generally all good news and somewhat hopeful. The fact you can ping 
>>> 192.168.10.2 in safe mode tell’s you that the FPGA has loaded an image from 
>>> Flash, that it’s passed CRC and booted the embedded micro controller on the 
>>> FPGA and run the firmware that replies to ICMP packets…that’s a sign the 
>>> hardware is in reasonable shape, regardless of what actually version of 
>>> image ins currently loaded. If you had the internal UART connected to a 
>>> 3.3V interface you would be seeing the FPGA and FW compatibility numbers 
>>> for this image printed at boot if it got this far.
>>> (Sorry if I’m telling

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Holy smoke!  SUCCESS!!  Nick pointed out that there are two switches on the 
N210; S1 and S2 and S1 is a reset, so an upload of FPGA code fails if that is 
held (which I was holding for his suggested test!).  Holding S2 during iMPACT 
loading of the .bit image results in the uhd_image_loader step being 
SUCCESSFUL!!  I am so happy to see that!  Uhd_usrp_probe works wonderfully.  
Finally.  We now can put this little to work doing some tough things!  

Thank you all SO MUCH for your assistance with reviving this N210.  A 
monumental achievement in my book!   I don’t know what to say except that we 
TOTALLY appreciate you efforts to get us running.  You guys are GREAT! 

Very best wishes to you each and every one!   

Joe

> On May 10, 2019, at 5:30 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Ian and all, 
> 
> I have been very careful to avoid the pitfalls you detailed.  I began with a 
> fresh installation of Ubuntu 18.04 then performed a successful build of UHD 
> 3.9.7, then used command:
> 
> uhd_images_downloader
> 
> to load the appropriate/associated images into the PC. 
> 
> Then used ISE iMPACT to load the “usrp_n210_r3_fpga.bit” file into the FPGA 
> of the N210.  iMPACT reports “PROGRAM SUCCESSFUL”. 
> 
> Then without power cycling the N210 used the command: 
> 
> usrp_image_loader —args=“type=usrp2,addr=192.168.10.2,overwrite-safe” 
> —fw-path=/usr/local/share/uhd/images/usrp_n210_fw.bin 
> —fpga-path=/usr/local/share/uhd/images/usrp_n210_r3_fpga.bin
> 
> To load the non-volatile memory of the N210 but I always get the 
> “RuntimeError: Received invalid 32 reply from device” error when running 
> usrp_image_loader. 
> 
> I am able to successfully ping 192.168.10.2 but no matter what combinations 
> of r2 or r3 .bit file and firmware and fpga image .bin files I use the 
> response when invoking the usrp_image_loader is always the same, namely 
> “invalid reply 32 from device”.  
> 
> The command uhd_find_devices returns by reporting it can find a usrp2 device 
> at address 192.168.10.2, as you would hope.  
> 
> After trying every conceivable combination of these actions with numerous 
> versions of UHD and r2/r3 .bit FPGA files and r2/r3 .bin files on several 
> fresh installations of Ubuntu 18.04 and 16.04 the result is always the same 
> in that things proceed normally as the various documents concerning 
> un-bricking an N210 explains, until the step of using the usrp_image_loader 
> is executed, at which point a RuntimeError returns stating that the “invalid 
> 32 reply” has occurred.  
> 
> I was hopeful that careful use of rev3 .bit and .bin files with UHD 3.9.7 
> would do the trick but alas that is not the case.  
> 
> I suspect that you are near the bottom of the list of suggestions for me and 
> I do appreciate the time and thinking you have afforded me on this issue.  If 
> there is anything remaining to try I’d be most willing to try it. 
> 
> BTW, the suggestion made by someone earlier to try holding the safe button 
> down during the loading of the FPGA from iMPACT causes the programming to 
> fail (as reported by iMPACT), so that’s apparently not a good thing to do.  
> But one can recover from that state by simply by re-programming with the safe 
> button not held but the fundamental problem with the uhd_image_loader step in 
> the unbricking process always seems to result. 
> 
> Joe
> 
>> On May 10, 2019, at 9:31 AM, Ian Buckley > > wrote:
>> 
>> Joe, 
>> To save you time, It may well be worth you trying jumping to the 3) step 
>> initially and seeing if your current loaded image or safe image is capable 
>> of being upgraded …it likely is since that protocol is widely compatible 
>> across UHD variants. The key here I have to emphasize (since you appear to 
>> have been previously getting stuck with incompatibility between whatever is 
>> loaded in the USRP and your host UHD installation) is to be sure your new 
>> UHD installation is the only one on your system, and that you have the 
>> binary images that are version matched with it…people often get caught out 
>> by reminants of various UHD versions installed in various system directories 
>> from different install methods.
>> -Ian
>> 
>>> On May 10, 2019, at 5:58 AM, Joe Martin via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> Ian, 
>>> 
>>> Very good, that’s encouraging at least.  Yes, I am familiar with using ISE 
>>> iMPACT to load the FPGA with .bit code and even how to create the .bit from 
>>> the associated .bin file and did try doing that earlier but perhaps not 
>>> identically to your prescribed steps below.  I’ll revisit it.  I 
>>> successfully built UHD 003_009_000 earlier so I can probably also 
>>> successfully build UHD 003_009_007 too.  I’ll do that and give it a go.  I 
>>> am familiar with the documents you mentioned.  Generally things have gone 
>>> exactly as described right up until UHD needs to communicate with the 
>>> stored images at which point

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Nick Foster via USRP-users]

Great news! Also great that we have this on record for others with older
hardware they'd like to put to use again.

Nick

On Fri, May 10, 2019 at 4:54 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Holy smoke!  SUCCESS!!  Nick pointed out that there are two switches on
> the N210; S1 and S2 and S1 is a reset, so an upload of FPGA code fails if
> that is held (which I was holding for his suggested test!).  Holding S2
> during iMPACT loading of the .bit image results in the uhd_image_loader
> step being SUCCESSFUL!!  I am so happy to see that!  Uhd_usrp_probe works
> wonderfully.  Finally.  We now can put this little to work doing some tough
> things!
>
> Thank you all SO MUCH for your assistance with reviving this N210.  A
> monumental achievement in my book!   I don’t know what to say except that
> we TOTALLY appreciate you efforts to get us running.  You guys are GREAT!
>
> Very best wishes to you each and every one!
>
> Joe
>
> On May 10, 2019, at 5:30 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Ian and all,
>
> I have been very careful to avoid the pitfalls you detailed.  I began with
> a fresh installation of Ubuntu 18.04 then performed a successful build of
> UHD 3.9.7, then used command:
>
> uhd_images_downloader
>
> to load the appropriate/associated images into the PC.
>
> Then used ISE iMPACT to load the “usrp_n210_r3_fpga.bit” file into the
> FPGA of the N210.  iMPACT reports “PROGRAM SUCCESSFUL”.
>
> Then without power cycling the N210 used the command:
>
> usrp_image_loader —args=“type=usrp2,addr=192.168.10.2,overwrite-safe”
> —fw-path=/usr/local/share/uhd/images/usrp_n210_fw.bin
> —fpga-path=/usr/local/share/uhd/images/usrp_n210_r3_fpga.bin
>
> To load the non-volatile memory of the N210 but I always get the
> “RuntimeError: Received invalid 32 reply from device” error when running
> usrp_image_loader.
>
> I am able to successfully ping 192.168.10.2 but no matter what
> combinations of r2 or r3 .bit file and firmware and fpga image .bin files I
> use the response when invoking the usrp_image_loader is always the same,
> namely “invalid reply 32 from device”.
>
> The command uhd_find_devices returns by reporting it can find a usrp2
> device at address 192.168.10.2, as you would hope.
>
> After trying every conceivable combination of these actions with numerous
> versions of UHD and r2/r3 .bit FPGA files and r2/r3 .bin files on several
> fresh installations of Ubuntu 18.04 and 16.04 the result is always the same
> in that things proceed normally as the various documents concerning
> un-bricking an N210 explains, until the step of using the usrp_image_loader
> is executed, at which point a RuntimeError returns stating that the
> “invalid 32 reply” has occurred.
>
> I was hopeful that careful use of rev3 .bit and .bin files with UHD 3.9.7
> would do the trick but alas that is not the case.
>
> I suspect that you are near the bottom of the list of suggestions for me
> and I do appreciate the time and thinking you have afforded me on this
> issue.  If there is anything remaining to try I’d be most willing to try
> it.
>
> BTW, the suggestion made by someone earlier to try holding the safe button
> down during the loading of the FPGA from iMPACT causes the programming to
> fail (as reported by iMPACT), so that’s apparently not a good thing to do.
> But one can recover from that state by simply by re-programming with the
> safe button not held but the fundamental problem with the uhd_image_loader
> step in the unbricking process always seems to result.
>
> Joe
>
> On May 10, 2019, at 9:31 AM, Ian Buckley  wrote:
>
> Joe,
> To save you time, It may well be worth you trying jumping to the 3) step
> initially and seeing if your current loaded image or safe image is capable
> of being upgraded …it likely is since that protocol is widely compatible
> across UHD variants. The key here I have to emphasize (since you appear to
> have been previously getting stuck with incompatibility between whatever is
> loaded in the USRP and your host UHD installation) is to be sure your new
> UHD installation is the only one on your system, and that you have the
> binary images that are version matched with it…people often get caught out
> by reminants of various UHD versions installed in various system
> directories from different install methods.
> -Ian
>
> On May 10, 2019, at 5:58 AM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Ian,
>
> Very good, that’s encouraging at least.  Yes, I am familiar with using ISE
> iMPACT to load the FPGA with .bit code and even how to create the .bit from
> the associated .bin file and did try doing that earlier but perhaps not
> identically to your prescribed steps below.  I’ll revisit it.  I
> successfully built UHD 003_009_000 earlier so I can probably also
> successfully build UHD 003_009_007 too.  I’ll do that and give it a go.  I
> am familiar with the documents you mentioned.  Generally things have gone
> 

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Michael Dickens via USRP-users]

Excellent news, Joe! You're welcome for the assistance; any time! Congrats on 
persisting & now: have fun! - MLD

On Fri, May 10, 2019, at 7:55 PM, Joe Martin via USRP-users wrote:
> Holy smoke! SUCCESS!! Nick pointed out that there are two switches on the 
> N210; S1 and S2 and S1 is a reset, so an upload of FPGA code fails if that is 
> held (which I was holding for his suggested test!). Holding S2 during iMPACT 
> loading of the .bit image results in the uhd_image_loader step being 
> SUCCESSFUL!! I am so happy to see that! Uhd_usrp_probe works wonderfully. 
> Finally. We now can put this little to work doing some tough things! 
> 
> Thank you all SO MUCH for your assistance with reviving this N210. A 
> monumental achievement in my book! I don’t know what to say except that we 
> TOTALLY appreciate you efforts to get us running. You guys are GREAT! 
> 
> Very best wishes to you each and every one! 
> 
> Joe
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com