On Mon, Jul 26, 2010 at 1:39 AM, Craig Tong <[email protected]> wrote: > Hi > > bcdDevice is 0.00 for the verbose lsusb output. Also there doesn't seem to a > be a burn-usrp4-eeprom anymore but there is a burn-db-eeprom, unless I'm > missing something.
The script you need to run can be found in the built source. usrp/firmware/src/usrp2/burn-usrp4-eeprom Disregard the directory naming. Thomas > Craig Tong > Radar Remote Sensing Group > University of Cape Town > > > On 23/07/2010 19:49, Thomas Tsou wrote: >> >> On Fri, Jul 23, 2010 at 1:51 AM, Craig Tong<[email protected]> >> wrote: >> >>> >>> This USRP has been here since before my time but the other guys in the >>> lab >>> seem to think that it was bought directly from Ettus. It has the "Ettus >>> Research LLC" sticker on it with the "Ser" number and test date. >>> >>> As for the lsusb. It reports: >>> Bus 001 Device 007: ID fffe:0002 >>> >>> similar to lsusb for the working USRP. >>> >> >> That means the EEPROM is being read correctly. Try running "lsusb -v" >> and look for the line bcdDevice under the fffe:0002 section. You >> should be seeing 0.04, which means unconfigured (high byte) and rev4 >> (low byte). >> >> Thomas >> >> >>> >>> Craig Tong >>> Radar Remote Sensing Group >>> University of Cape Town >>> >>> >>> On 22/07/2010 20:15, Thomas Tsou wrote: >>> >>>> >>>> On Thu, Jul 22, 2010 at 4:35 AM, Craig Tong<[email protected]> >>>> wrote: >>>> >>>> >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the help, I tracked through the functions that are used to >>>>> load >>>>> up the firmware and it turns out that this USRP is reporting its >>>>> revision >>>>> number as 0. As such the path to the firmware is always invalid. I >>>>> managed >>>>> to get my hands on another USRP just now and it returns revision 4 so >>>>> my >>>>> code seems to work correctly. >>>>> >>>>> Is this likely to be an EPROM corruption ? >>>>> >>>>> >>>> >>>> That is likely. At usrp power-up, the USB controller reads the eeprom >>>> data, which is reported to the host as various identifiers. Either the >>>> data is somehow corrupt or not being read. >>>> >>>> What appears when you run lsusb on the command line? >>>> >>>> Thomas >>>> >>>> >>>> >>>>> >>>>> Craig Tong >>>>> Radar Remote Sensing Group >>>>> University of Cape Town >>>>> >>>>> >>>>> On 21/07/2010 19:15, Thomas Tsou wrote: >>>>> >>>>> >>>>>> >>>>>> On Wed, Jul 21, 2010 at 1:36 AM, Craig >>>>>> Tong<[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm having some trouble getting my USRP board running with just about >>>>>>> any >>>>>>> software. It always seems to die with "Can't find firmware: std.ihx". >>>>>>> I've >>>>>>> tried a whole array of applications including usrp_fft.py and >>>>>>> similar, >>>>>>> usrp_probe and then also the C++ progs (test_usrp_standard_rx and the >>>>>>> like). >>>>>>> >>>>>>> It dies with the same complaint when running the C++ software that >>>>>>> we're >>>>>>> busy writing. It fails on the line "usrp_standard_rx::make( ... )" >>>>>>> where >>>>>>> the >>>>>>> firmware file is specified. It is currently blank (i.e. default) but >>>>>>> even >>>>>>> if >>>>>>> the file is specified explicitly, it still claims that it cannot be >>>>>>> found. >>>>>>> From what I understand from what is going on in >>>>>>> "usrp_prims_common.cc" >>>>>>> if >>>>>>> the user specifies a path it should override the default one. Exactly >>>>>>> how >>>>>>> it >>>>>>> formats this path I can't really keep track of and I think something >>>>>>> is >>>>>>> going wrong there. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Under typical installations the path is constructed with >>>>>> "/usr/local/share/usrp" appended with rev2 or rev4 and the filename. >>>>>> If environment variable USRP_PATH is set, then the revision and >>>>>> filename are appended to that path instead. Read permissions are also >>>>>> checked before the path is returned. >>>>>> >>>>>> As you already suspect, the problem is most likely something minor. >>>>>> Try printing out the path in the find_file() call to see what you're >>>>>> searching for. >>>>>> >>>>>> Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> I had it working on Ubuntu 9.04 x86 but it stopped working when I >>>>>>> updated >>>>>>> to >>>>>>> 10.04. I tried reinstalling gnuradio 3.2 several times. And also >>>>>>> tried >>>>>>> the >>>>>>> versions from synaptic but always came down with the same error. I've >>>>>>> since >>>>>>> wiped the system and installed Ubuntu 10.04 x86_64 with new 3.3.0 >>>>>>> version >>>>>>> of >>>>>>> gnuradio but the problem continues. >>>>>>> >>>>>>> I do have "usr/local/share/usrp/rev4/std.ihx" and all that goes with >>>>>>> it. >>>>>>> I >>>>>>> can also load the firmware with usrper and then put LED1 on and off >>>>>>> so >>>>>>> the >>>>>>> USRP seems to be working correctly. >>>>>>> >>>>>>> I do get the feeling I'm missing something very obvious here because >>>>>>> it >>>>>>> seems the last instances of this sort of problem date back to 2007. >>>>>>> Still >>>>>>> I >>>>>>> just can't put my finger on whats wrong. >>>>>>> >>>>>>> Any advice would be greatly appreciated. >>>>>>> >>>>>>> regards >>>>>>> Craig >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] >>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
