discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Tsou
Subject: Re: [Discuss-gnuradio] Can't find firmware: std.ihx
Date: Thu, 22 Jul 2010 11:15:09 -0700

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
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]