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 <ian.buck...@gmail.com> 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 <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 <ian.buck...@gmail.com >>> <mailto:ian.buck...@gmail.com>> 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 >>> <https://kb.ettus.com/N200/N210_Device_Recovery> >>> http://files.ettus.com/manual/page_usrp2.html#usrp2_load >>> <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 >>> <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 >>>> <usrp-users@lists.ettus.com <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 <bistrom...@gmail.com >>>>> <mailto:bistrom...@gmail.com>> 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 <k...@k5so.com >>>>> <mailto:k...@k5so.com>> wrote: >>>>> Thanks for digging into that for us, Nick. Interesting. As the hardware >>>>> change to rev4 occurred around mid 2011 and the earliest UHD version that >>>>> exists on the files.ettus.com/uhd <http://files.ettus.com/uhd> page is >>>>> Feb 2104, what is the likelihood in your opinion that the UHD version >>>>> will be compatible with the rev2/3 hardware from 2011? >>>>> >>>>> So far I’ve not been successful in reviving the 2014 UHD version so I’m >>>>> asking to determine whether continued effort to do so is likely to yield >>>>> anything positive with respect to interfacing with the 2011 hardware. >>>>> >>>>> Joe >>>>> >>>>>> On May 9, 2019, at 3:06 PM, Nick Foster <bistrom...@gmail.com >>>>>> <mailto:bistrom...@gmail.com>> wrote: >>>>>> >>>>>> So I really dug into the old archives here and literally pulled an old >>>>>> hard drive out of a closet, and found a copy of the old hardware >>>>>> repository from back in the days when N210 was called "USRP2+". Best >>>>>> that I can tell, we only ever released two versions to the public. We >>>>>> might have sold R3 stickered as R2 -- I don't see anything in the >>>>>> repository that would indicate otherwise. Rev 2/3 was sold until around >>>>>> June or July 2011, when we moved to rev 4. The only firmware/host code >>>>>> changes I can see between any of the versions are that R4 used LVDS >>>>>> clocking to the daughterboard where previous versions used CMOS. So I >>>>>> think you should be able to run r3 firmware on your N210. >>>>>> >>>>>> That said, the very very old N210s with very very old firmware might not >>>>>> have used the same safe/production firmware/fpga image arrangement that >>>>>> we later arrived at. The hardware is still fine, but you might be in for >>>>>> a bit of a deep dive to get it all running again. >>>>>> >>>>>> If you have a TTL-serial adapter or a logic analyzer that works as such, >>>>>> you can connect to the debug UART header and get printout information >>>>>> from the firmware at boot time. Another good idea would be to take a >>>>>> video of the front panel LEDs as you apply power -- the boot LED lights >>>>>> give good indication of the firmware/FPGA image loading process. >>>>>> >>>>>> Nick >>>>>> >>>>>> On Thu, May 9, 2019 at 1:42 PM Joe Martin via USRP-users >>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >>>>>> Thanks for the info, Marcus. However, seeing that Jason went through >>>>>> this last year with a couple of N210 he has it would seem unlikely that >>>>>> all three of the N210 are broken. That being said and considering what >>>>>> you jus said it seems that I should’ve been able to find some version of >>>>>> UHD that will successfully communicate with the firmware and fpga images >>>>>> stored in the unit; I have not, using UHD versions from 3.9.0 to >>>>>> 3.14.0. >>>>>> >>>>>> I wanted to try with even earlier versions of UHD but am finding trouble >>>>>> in utilizing UHD v3.4.0 (earliest version I could find) as it seems that >>>>>> “prebuilt” v3.4.0 needs only Ubuntu 10.10 or 11.10 which so far I’m not >>>>>> able to successfully install and run. Seems we’re running out of >>>>>> option on this one so the Deep Space Exploration Society, who I’m trying >>>>>> to help with this, may have to come to grasps with the notion that their >>>>>> N210 is a true brick. >>>>>> >>>>>> Joe >>>>>> >>>>>>> On May 9, 2019, at 2:23 PM, Marcus D. Leech via USRP-users >>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >>>>>>> >>>>>>> On 05/09/2019 04:18 PM, Joe Martin via USRP-users wrote: >>>>>>>> Nick, Ian, >>>>>>>> >>>>>>>> If this unit happens to be incorrectly labeled as a rev 2 N210 and it >>>>>>>> is actually a rev 3 N210, is there hope in being able to load rev 3 >>>>>>>> firmware and fpga images (which I have located previously and tried >>>>>>>> actually) with some available UHD version? If so, would you be able >>>>>>>> to tell me which UHD version(s) might be able to communicate with it? >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>> Theoretically, most versions in the last several years should be able >>>>>>> to talk to it. In *general* UHD never drops support for older hardware, >>>>>>> and tries to maintain compatibility. Now, it is the case that newer >>>>>>> features are almost never "back-ported", but basic functionality should >>>>>>> always be there. >>>>>>> >>>>>>> What this *should* mean is that you should be able to use the firmware >>>>>>> tools once the device is in "safe mode" to get yourself to where you >>>>>>> want to be. If that doesn't work, that may well mean that the >>>>>>> hardware is broken, and it's unlikely to be economical to repair. >>>>>>> >>>>>>> >>>>>>>>> On May 9, 2019, at 2:12 PM, Joe Martin via USRP-users >>>>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Okay. I’ve asserted from the outset that it’s a rev 2, based on the >>>>>>>>> factory label. Is this N210 a lost cause if it is actually a Rev2 >>>>>>>>> N210? >>>>>>>>> >>>>>>>>> Joe >>>>>>>>> >>>>>>>>>> On May 9, 2019, at 2:05 PM, Nick Foster <bistrom...@gmail.com >>>>>>>>>> <mailto:bistrom...@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> Well, it's not a rev 4. It's either 2 or 3 in terms of hardware >>>>>>>>>> revision. >>>>>>>>>> >>>>>>>>>> On Thu, May 9, 2019 at 12:58 PM Joe Martin <k...@k5so.com >>>>>>>>>> <mailto:k...@k5so.com>> wrote: >>>>>>>>>> …able to ping 192.168.10.2 successfully. >>>>>>>>>> >>>>>>>>>>> On May 9, 2019, at 1:54 PM, Joe Martin <k...@k5so.com >>>>>>>>>>> <mailto:k...@k5so.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> Ian, >>>>>>>>>>> >>>>>>>>>>> Yes, I have tried many times to boot in safe mode, same result >>>>>>>>>>> regardless. Yes, I am able to pin to 192.168.10.2 successfully. >>>>>>>>>>> >>>>>>>>>>> Joe >>>>>>>>>>> >>>>>>>>>>>> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users >>>>>>>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Ian and Nick, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the assistance. Attached are dropbox links to two >>>>>>>>>>>> snapshot photos: 1) the factory label on the back of the N210, >>>>>>>>>>>> showing N210 r:2.0 and 2) a top side view of the N210. >>>>>>>>>>>> >>>>>>>>>>>> 1) >>>>>>>>>>>> https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 >>>>>>>>>>>> <https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0> >>>>>>>>>>>> 2) >>>>>>>>>>>> https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 >>>>>>>>>>>> <https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0> >>>>>>>>>>>> >>>>>>>>>>>> Seems this unit is indeed a rev 2 N210, yes? >>>>>>>>>>>> >>>>>>>>>>>> Joe >>>>>>>>>>>> >>>>>>>>>>>>> On May 9, 2019, at 12:40 PM, Nick Foster <bistrom...@gmail.com >>>>>>>>>>>>> <mailto:bistrom...@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Moreover, the best "tell" is to look at the N210 motherboard. If >>>>>>>>>>>>> the SRAM chip is on the top side, it's a rev 2/3. If the SRAM is >>>>>>>>>>>>> on the bottom side, it's a rev 4. If you send a picture along of >>>>>>>>>>>>> the top of the N210, I can tell you if it's early or late rev. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users >>>>>>>>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> Joe, >>>>>>>>>>>>> So I scratched my head about this a little late last night and >>>>>>>>>>>>> looked back through the development repository for the N210 and >>>>>>>>>>>>> as far as I can tell there was never customer facing FPGA code >>>>>>>>>>>>> for a Rev2 N210. Chatting with Matt this morning he shared my >>>>>>>>>>>>> feeling that a Rev2 wasn't sold to customers, so I'm curious if >>>>>>>>>>>>> you have a unit that has a factory label that says N210Rev2 or if >>>>>>>>>>>>> you have seen "usrp2 rev2.0" on the PCB (which can be >>>>>>>>>>>>> missleading). >>>>>>>>>>>>> >>>>>>>>>>>>> Also have you tried booting into the safe image and verifying >>>>>>>>>>>>> that it at least pings on 192.168.10.2? >>>>>>>>>>>>> >>>>>>>>>>>>> If we can conclusively identify which rev of h/w you have I can >>>>>>>>>>>>> probably help further. >>>>>>>>>>>>> >>>>>>>>>>>>> Ian >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> USRP-users mailing list >>>>>>>>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> >>>>>>>>> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> >>>>>>>> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> >>>>>>> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> >>>>>> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> >>>> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > On May 10, 2019, at 9:31 AM, Ian Buckley <ian.buck...@gmail.com> 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 <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 <ian.buck...@gmail.com >>> <mailto:ian.buck...@gmail.com>> 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 >>> <https://kb.ettus.com/N200/N210_Device_Recovery> >>> http://files.ettus.com/manual/page_usrp2.html#usrp2_load >>> <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 >>> <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 >>>> <usrp-users@lists.ettus.com <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 <bistrom...@gmail.com >>>>> <mailto:bistrom...@gmail.com>> 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 <k...@k5so.com >>>>> <mailto:k...@k5so.com>> wrote: >>>>> Thanks for digging into that for us, Nick. Interesting. As the hardware >>>>> change to rev4 occurred around mid 2011 and the earliest UHD version that >>>>> exists on the files.ettus.com/uhd <http://files.ettus.com/uhd> page is >>>>> Feb 2104, what is the likelihood in your opinion that the UHD version >>>>> will be compatible with the rev2/3 hardware from 2011? >>>>> >>>>> So far I’ve not been successful in reviving the 2014 UHD version so I’m >>>>> asking to determine whether continued effort to do so is likely to yield >>>>> anything positive with respect to interfacing with the 2011 hardware. >>>>> >>>>> Joe >>>>> >>>>>> On May 9, 2019, at 3:06 PM, Nick Foster <bistrom...@gmail.com >>>>>> <mailto:bistrom...@gmail.com>> wrote: >>>>>> >>>>>> So I really dug into the old archives here and literally pulled an old >>>>>> hard drive out of a closet, and found a copy of the old hardware >>>>>> repository from back in the days when N210 was called "USRP2+". Best >>>>>> that I can tell, we only ever released two versions to the public. We >>>>>> might have sold R3 stickered as R2 -- I don't see anything in the >>>>>> repository that would indicate otherwise. Rev 2/3 was sold until around >>>>>> June or July 2011, when we moved to rev 4. The only firmware/host code >>>>>> changes I can see between any of the versions are that R4 used LVDS >>>>>> clocking to the daughterboard where previous versions used CMOS. So I >>>>>> think you should be able to run r3 firmware on your N210. >>>>>> >>>>>> That said, the very very old N210s with very very old firmware might not >>>>>> have used the same safe/production firmware/fpga image arrangement that >>>>>> we later arrived at. The hardware is still fine, but you might be in for >>>>>> a bit of a deep dive to get it all running again. >>>>>> >>>>>> If you have a TTL-serial adapter or a logic analyzer that works as such, >>>>>> you can connect to the debug UART header and get printout information >>>>>> from the firmware at boot time. Another good idea would be to take a >>>>>> video of the front panel LEDs as you apply power -- the boot LED lights >>>>>> give good indication of the firmware/FPGA image loading process. >>>>>> >>>>>> Nick >>>>>> >>>>>> On Thu, May 9, 2019 at 1:42 PM Joe Martin via USRP-users >>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >>>>>> Thanks for the info, Marcus. However, seeing that Jason went through >>>>>> this last year with a couple of N210 he has it would seem unlikely that >>>>>> all three of the N210 are broken. That being said and considering what >>>>>> you jus said it seems that I should’ve been able to find some version of >>>>>> UHD that will successfully communicate with the firmware and fpga images >>>>>> stored in the unit; I have not, using UHD versions from 3.9.0 to >>>>>> 3.14.0. >>>>>> >>>>>> I wanted to try with even earlier versions of UHD but am finding trouble >>>>>> in utilizing UHD v3.4.0 (earliest version I could find) as it seems that >>>>>> “prebuilt” v3.4.0 needs only Ubuntu 10.10 or 11.10 which so far I’m not >>>>>> able to successfully install and run. Seems we’re running out of >>>>>> option on this one so the Deep Space Exploration Society, who I’m trying >>>>>> to help with this, may have to come to grasps with the notion that their >>>>>> N210 is a true brick. >>>>>> >>>>>> Joe >>>>>> >>>>>>> On May 9, 2019, at 2:23 PM, Marcus D. Leech via USRP-users >>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >>>>>>> >>>>>>> On 05/09/2019 04:18 PM, Joe Martin via USRP-users wrote: >>>>>>>> Nick, Ian, >>>>>>>> >>>>>>>> If this unit happens to be incorrectly labeled as a rev 2 N210 and it >>>>>>>> is actually a rev 3 N210, is there hope in being able to load rev 3 >>>>>>>> firmware and fpga images (which I have located previously and tried >>>>>>>> actually) with some available UHD version? If so, would you be able >>>>>>>> to tell me which UHD version(s) might be able to communicate with it? >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>> Theoretically, most versions in the last several years should be able >>>>>>> to talk to it. In *general* UHD never drops support for older hardware, >>>>>>> and tries to maintain compatibility. Now, it is the case that newer >>>>>>> features are almost never "back-ported", but basic functionality should >>>>>>> always be there. >>>>>>> >>>>>>> What this *should* mean is that you should be able to use the firmware >>>>>>> tools once the device is in "safe mode" to get yourself to where you >>>>>>> want to be. If that doesn't work, that may well mean that the >>>>>>> hardware is broken, and it's unlikely to be economical to repair. >>>>>>> >>>>>>> >>>>>>>>> On May 9, 2019, at 2:12 PM, Joe Martin via USRP-users >>>>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Okay. I’ve asserted from the outset that it’s a rev 2, based on the >>>>>>>>> factory label. Is this N210 a lost cause if it is actually a Rev2 >>>>>>>>> N210? >>>>>>>>> >>>>>>>>> Joe >>>>>>>>> >>>>>>>>>> On May 9, 2019, at 2:05 PM, Nick Foster <bistrom...@gmail.com >>>>>>>>>> <mailto:bistrom...@gmail.com>> wrote: >>>>>>>>>> >>>>>>>>>> Well, it's not a rev 4. It's either 2 or 3 in terms of hardware >>>>>>>>>> revision. >>>>>>>>>> >>>>>>>>>> On Thu, May 9, 2019 at 12:58 PM Joe Martin <k...@k5so.com >>>>>>>>>> <mailto:k...@k5so.com>> wrote: >>>>>>>>>> …able to ping 192.168.10.2 successfully. >>>>>>>>>> >>>>>>>>>>> On May 9, 2019, at 1:54 PM, Joe Martin <k...@k5so.com >>>>>>>>>>> <mailto:k...@k5so.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> Ian, >>>>>>>>>>> >>>>>>>>>>> Yes, I have tried many times to boot in safe mode, same result >>>>>>>>>>> regardless. Yes, I am able to pin to 192.168.10.2 successfully. >>>>>>>>>>> >>>>>>>>>>> Joe >>>>>>>>>>> >>>>>>>>>>>> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users >>>>>>>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Ian and Nick, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the assistance. Attached are dropbox links to two >>>>>>>>>>>> snapshot photos: 1) the factory label on the back of the N210, >>>>>>>>>>>> showing N210 r:2.0 and 2) a top side view of the N210. >>>>>>>>>>>> >>>>>>>>>>>> 1) >>>>>>>>>>>> https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 >>>>>>>>>>>> <https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0> >>>>>>>>>>>> 2) >>>>>>>>>>>> https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 >>>>>>>>>>>> <https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0> >>>>>>>>>>>> >>>>>>>>>>>> Seems this unit is indeed a rev 2 N210, yes? >>>>>>>>>>>> >>>>>>>>>>>> Joe >>>>>>>>>>>> >>>>>>>>>>>>> On May 9, 2019, at 12:40 PM, Nick Foster <bistrom...@gmail.com >>>>>>>>>>>>> <mailto:bistrom...@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Moreover, the best "tell" is to look at the N210 motherboard. If >>>>>>>>>>>>> the SRAM chip is on the top side, it's a rev 2/3. If the SRAM is >>>>>>>>>>>>> on the bottom side, it's a rev 4. If you send a picture along of >>>>>>>>>>>>> the top of the N210, I can tell you if it's early or late rev. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users >>>>>>>>>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> Joe, >>>>>>>>>>>>> So I scratched my head about this a little late last night and >>>>>>>>>>>>> looked back through the development repository for the N210 and >>>>>>>>>>>>> as far as I can tell there was never customer facing FPGA code >>>>>>>>>>>>> for a Rev2 N210. Chatting with Matt this morning he shared my >>>>>>>>>>>>> feeling that a Rev2 wasn't sold to customers, so I'm curious if >>>>>>>>>>>>> you have a unit that has a factory label that says N210Rev2 or if >>>>>>>>>>>>> you have seen "usrp2 rev2.0" on the PCB (which can be >>>>>>>>>>>>> missleading). >>>>>>>>>>>>> >>>>>>>>>>>>> Also have you tried booting into the safe image and verifying >>>>>>>>>>>>> that it at least pings on 192.168.10.2? >>>>>>>>>>>>> >>>>>>>>>>>>> If we can conclusively identify which rev of h/w you have I can >>>>>>>>>>>>> probably help further. >>>>>>>>>>>>> >>>>>>>>>>>>> Ian >>>>>>>>>>>>
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
