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

[Thomas Tsou]

On Tue, Jul 27, 2010 at 1:25 AM, Craig Tong <address@hidden> 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<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
>>>
>>>
>