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 <ian.buck...@gmail.com >> <mailto: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 >>> <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 >> <mailto: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
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
