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

[Thomas Tsou]

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