Can't find firmware: std.ihx

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.

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

On Wed, Jul 21, 2010 at 1:36 AM, Craig Tong
[email protected] wrote:

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

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 ?

Craig Tong
Radar Remote Sensing Group
University of Cape Town

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 R. 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.

Craig Tong
Radar Remote Sensing Group
University of Cape Town

On Thu, Jul 22, 2010 at 4:35 AM, Craig Tong
[email protected] 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

On 07/23/2010 04:51 AM, Craig Tong 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 R. LLC” sticker on it with the “Ser” number and test date.

What is the serial number?

Philip

Hi Philip

its 712

Craig Tong
Radar Remote Sensing Group
University of Cape Town

On Fri, Jul 23, 2010 at 1:51 AM, Craig Tong
[email protected] 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

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.

Craig Tong
Radar Remote Sensing Group
University of Cape Town

On Mon, Jul 26, 2010 at 1:39 AM, Craig Tong
[email protected] 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

On Tue, Jul 27, 2010 at 1:25 AM, Craig Tong
[email protected] 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

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.

Thanks so much for the help guys.
Regards

Craig Tong
Radar Remote Sensing Group
University of Cape Town