Re: [Discuss-gnuradio] Can't find firmware: std.ihx

[Thomas Tsou]

On Fri, Jul 23, 2010 at 1:51 AM, Craig Tong <address@hidden> 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<address@hidden>
>>  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<address@hidden>
>>>>  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
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>