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 <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> 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> 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 < > 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> 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> 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 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> 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> 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> 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> 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> 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> wrote: >>> >>>> …able to ping 192.168.10.2 successfully. >>>> >>>> On May 9, 2019, at 1:54 PM, Joe Martin <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> 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 >>>> 2) 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> 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> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> USRP-users mailing >>> listUSRP-users@lists.ettus.comhttp://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 > > > > 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> 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> 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 < > 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> 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> 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 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> 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> 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> 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> 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> 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> wrote: >>> >>>> …able to ping 192.168.10.2 successfully. >>>> >>>> On May 9, 2019, at 1:54 PM, Joe Martin <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> 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 >>>> 2) 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> 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> 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
