On Tue, Jul 27, 2010 at 1:25 AM, Craig Tong <tngcra...@rrsg.ee.uct.ac.za> wrote: > Ok. > > Didn't think it would be in there. Ran the script and it seems to be working > correctly now. The bcdDevice is now 1.04 though. I assume this is correct. > Looks like it only takes the 4 from the value.
Right. It changes to 1.04 after the firmware loads. Thomas > Thanks so much for the help guys. > Regards > > Craig Tong > Radar Remote Sensing Group > University of Cape Town > > > On 27/07/2010 02:36, Thomas Tsou wrote: >> >> On Mon, Jul 26, 2010 at 1:39 AM, Craig Tong<tngcra...@rrsg.ee.uct.ac.za> >> 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<tngcra...@rrsg.ee.uct.ac.za> >>>> 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<tngcra...@rrsg.ee.uct.ac.za> >>>>>> 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<tngcra...@rrsg.ee.uct.ac.za> >>>>>>>> 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 >>>>>>> Discuss-gnuradio@gnu.org >>>>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
