On 05/08/2019 07:34 PM, Joe Martin via USRP-users wrote:
Thanks Philip, I’ll check out the precompiled versions on the link Robin
provided, to see if they go back far enough first. I tried the 3.9.0 so I’m
thinking 3.8.x might still be too recent but if none of these work perhaps I
can ask you to take a look for something earlier. Thanks!
Joe
The basic issue is that there never were that many R2s about that I
recall, before the R3 and the ADC input change was made, so I don't
think there
was much push to retain compatibility for modern versions.
On May 8, 2019, at 4:02 PM, Philip Balister <phi...@balister.org> wrote:
I've got the 3.8.4 images zipfile lying around in my OE download
directory, if it helps I can put it on dropbox. I might be able to find
some older ones if needed.
Yeah, I save ancient source in case of a GPL compliance exercise :)
Philip
On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:
You could try using the .deb or .rpm pre-built binaries if you're running
on Linux. See, for instance:
http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/
On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:
I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
complains that it is expecting compatibility number 11 but is receiving 6.
So I think that means I need an earlier version of UHD than 3.9.0.
I will dig into the earliest version in the git tag -l, namely
003_007_002_rc1, that would not build without errors and try to work out
the compiler errors then. Unless someone has a better idea to try.
Thanks!
Regards,
Joe
On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:
Okay, thanks, that’s what I thought but that isn’t useful for me until I
find a UHD version that can communicate with it. I’ve been trying to build
older UHD versions from 003_007_002_rc1 forward but all so far fail to
build due to compiler errors. Am up to 003_008_005_rc1 now, moving forward
until I can successfully build one to try. Are there any old pre-built
versions I could simply try without having to build each one myself?
Joe
On May 8, 2019, at 2:31 PM, Nick Foster <bistrom...@gmail.com> wrote:
Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
way to figure out what image is loaded other than asking UHD to query it
for FPGA compat number.
On Wed, May 8, 2019 at 1:04 PM Joe Martin <k...@k5so.com> wrote:
I guess the proper way to ask is “Is there a way to determine what fpga
.bin file is in the N210?”, since the .bit file that I loaded into the fpga
is volatile code that disappears upon power cycling to be reloaded from an
EEPROM or something, yes?
Joe
On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:
Hi Nick,
Thanks for the comments. Is there a way to determine what bit file is
currently in the N210? If so, how please?
Joe
On May 8, 2019, at 1:33 PM, Nick Foster <bistrom...@gmail.com> wrote:
I see you got there already! If you're still having trouble, I'll see
what I can dig up over here.
On Wed, May 8, 2019 at 12:31 PM Nick Foster <bistrom...@gmail.com> wrote:
You might be best off reverting to a UHD old enough to support the
bitfile currently loaded on your N210. You could then bootstrap your N210
by using the old UHD to load a newer FPGA image.
Otherwise, it's fairly simple to convert the binfiles (which still exist
-- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
usrp_n210_r3_fpga.bit and just stick it onto the front of
usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
header is everything up until FF FF FF FF AA 99 55 66.
Lastly, the source is all there, so building using ISE should still be
possible.
Nick
On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:
Wow, okay; that’s disheartening. Thanks much for the info, Jason.
Nope, the Rev3 bit file doesn’t work; tried it. I’ll see if the support
email adr can be of use.
Joe
On May 8, 2019, at 10:44 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:
Joe, I think you might be SOL. If you take a look at this thread from
me last year, I had no luck:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
Also, when I pinged Ettus directly, here is some info I got back from
them (from two different emails in the thread):
"we've been having some trouble tracking down Rev2 bitfiles, because no
one here was around when that was built. If you're trying to unbrick
them, Rev3 bitfiles might be OK, but I'm not completely sure.
supp...@ettus.com might know more by know.
really sorry, but those Rev2s are just so old. And all the people from
that era seem to be gone. Sorry, can't help you with those Rev2s."
------------------------------
*From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of
Joe Martin via USRP-users <usrp-users@lists.ettus.com>
*Sent:* Wednesday, May 8, 2019 11:55 AM
*To:* Joe Martin via USRP-users
*Subject:* [USRP-users] Bringing an elderly N210 to life by loading
current firmware/fpga images
I am trying to bring an elderly N210 r2.0 with unknown history to life
by loading current UHD firmware and fpga images from a 1Gigabit ethernet
connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
and N2x0 Series”:
My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
Succeeded” for the action. Ethernet LEDs on the N210 are variously lighted
showing activity on the connection port.
With the N210 connected to the Linux PC 1Gbps ethernet port, issuing
the following commands result in the responses shown in the screenshot
image below:
<Screenshot from 2019-05-08 08-46-52.png>
My (naive!) interpretation of the above responses is that the FPGA may
not actually have been programmed with the *.bit code even though iMPACT
reported success in programming. Can someone assist me in understanding
whether my interpretation is correct or not and, most importantly, suggest
what I might try next to bring this N210 to life?
The “Please run:” suggestion results in the “Received invalid reply 32
from device” error. It seems no matter what I try the “Received invalid
reply 32 from device” RuntimeError is reported back when I try to load any
new firmware/FPGA images.
Thanks!
Joe
_______________________________________________
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 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 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
