Hi Rob, We are looking into it. It should have been fixed as of UHD 3.13.0.0 as Sayyed stated. Which version of the SD card image are you currently using? Are you running uhd_usrp_probe directly on the device or from a remote host? If from a remote host, what version of UHD are you currently using on the remote host? The output says UHD_3.13.0.1-0-g5b236772, but I am trying to figure out if that is on the host side or on the device or both so we can replicate your set up.
Sayyed - If the SD card is not unmounted properly when writing an image to it the image can become corrupted and fail to boot. Rewriting it and unmounting properly usually makes it work. Regards, Michael On Wed, Aug 15, 2018 at 1:00 PM, Sayyed Dormiani Tabatabaei via USRP-users < usrp-users@lists.ettus.com> wrote: > There is a small reset button on the back. You need a paperclip to push it. > > Also keep in mind that Micro SD cards use mmc flash. This is really low > quality flash memory that has poor write endurance. > > I had an N310 that would not boot. Replaced the SD card and it booted on > the first try. You could have just killed your micro SD by re-imaging too > many times. > > On Wed, Aug 15, 2018 at 12:13 PM, Rob Kossler <rkoss...@nd.edu> wrote: > >> Thanks for the suggestion, but no luck. Just tried the latest off of >> 3.13 branch. >> >> Given that I've been using this N310 for weeks on the original UHD >> version, I didn't expect that an update would cure it. >> >> It seems that maybe EEPROM has been corrupted for some reason. I hope >> there is a reset option because my N310 is basically brick-ed now. >> >> Rob >> >> On Wed, Aug 15, 2018 at 2:55 PM Sayyed Dormiani Tabatabaei < >> sdorm...@eng.ucsd.edu> wrote: >> >>> Well I had this problem with UHD 3.12 but 3.13 fixed it. Do not know why >>> it is back. >>> >>> The github has 13.0.0.2 now and it seems some N310 related things are in >>> that mini patch. Last commit was 20 hours ago so that may be it? >>> >>> ## 003.013.000.002 >>> * N3xx: Fix issue where changing the clock/time source could result in >>> clocks becoming unlocked >>> * N3xx: Improve error messages for invalid clock/time settings >>> * N3xx: Add support for Rev G mboard >>> * MPM: Add function parameter to support holding AD9371 in reset >>> * Docs: Add section on building fs/SD images for N3xx >>> * Docs: Fix Doxygen warnings >>> >>> On Wed, Aug 15, 2018 at 11:46 AM, Rob Kossler via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Anyone know the cause & solution to the following startup error? This >>>> just started today after a cascade of problems which ultimately required me >>>> to reflash the SD card. >>>> >>>> $ uhd_usrp_probe --args="addr=192.168.61.2" >>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; >>>> UHD_3.13.0.1-0-g5b236772 >>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: >>>> mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial=315A34B >>>> ,claimed=False,addr=192.168.61.2 >>>> [INFO] [MPM.PeriphManager] init() called with device args >>>> `mgmt_addr=192.168.61.2,product=n310'. >>>> [ERROR] [RPC] RuntimeError: AD9371 product ID does not match expected >>>> ID! Read: 1 Expected: 3 >>>> [ERROR] [MPM.RPCServer] init() failed with error: RuntimeError: AD9371 >>>> product ID does not match expected ID! Read: 1 Expected: 3 >>>> Error: RuntimeError: Error during RPC call to `init'. Error message: >>>> RuntimeError: AD9371 product ID does not match expected ID! Read: 1 >>>> Expected: 3 >>>> >>>> >>>> _______________________________________________ >>>> 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
