Forum: GNU Radio Re: USB2 problems with Fedora/USRP

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
83cfe44af85b7477257ed37b0037e2d4?d=identicon&s=25 Alberto Trentadue (Guest)
on 2009-01-15 22:53
(Received via mailing list)
> Hello
>
...
> The next step is to try out some example, e.g. usrp_benchmark_usb.py or usrp_wfm_rcv.py.
> Whatever
the test I try, I can see that blinking led is switched of for a couple
seconds, then it blinks at lower
> rate, and
another led near to it turns on  (don't remember which is D402 and
D403).
>
> On console, i get this kind of error:
>

> usb_control_msg failed: error sending control message: Connection timed out
> usrp: failed to load fpga bitstream
/opt/gnuradio/share/usrp/rev4/std_2rxhb_2tx.rbf
> Traceback (most recent call last):
>     File "./usrp_benchmark_usb.
py", line 106, in ?
>         main ( )
>     File "./usrp_benchmark_usb.py", line 96, in main
>         ok=run_test
(rate, verbose)
>     File "./usrp_benchmark_usb.py", line 63, in run_test
>         usrp_tx=usrp.sink_s(0, tx_interp)

>     File "/usr/local/hamradio/gnuradio/lib/python2.5/site-packages/gnuradio/usrp.py", 
line 230, in __init__
>
fpga_filename, firmware_filename)
>     File "/usr/local/hamradio/gnuradio/lib/python2.5/site-packages/gnuradio/usrp1.
py", line 940, in  sink_s
>         return _usrp1.sink_s(*args)
> RuntimeError: can't open usrp1
...
====  Eric Blossom
wrote

>Confirm that your computer has an EHCI host controller.
...
=====

Hello

The PC has the EHCI host controller:


[root@iz0cez usb]# lspci
...
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
Controller #2
(rev 03)

Now, I've tried again launching the usrp_benchmark_usb.py and then
[root@iz0cez usb]# cat
/proc/bus/usb/devices
...
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.)
Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=fffe ProdID=0002 Rev= 1.04
S:  Manufacturer=Free Software Folks
S:
Product=USRP Rev 4
S:  SerialNumber=480f9a8a
C:* #Ifs= 3 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 0 Cls=ff
(vend.) Sub=ff Prot=ff Driver=(none)
I:* If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=02(O)
Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=86(I) Atr=02
(Bulk) MxPS= 512 Ivl=0ms

It seems that I was wrong: USB2 driver seems to be working well, at
least for the first
configuration steps, because I am successful in configuring the Cypress
FX2.
Then it looks like the problem is actually
in the next step, that is, loading the fpga bitstream
/usr/local/hamradio/gnuradio/share/usrp/rev4/std_2rxhb_2tx.rbf


So I have 3 questions:
1. What can I use to trace/debug/investigate the final fpga load
operation?
2. Where is the
source code of the program performing the actual fpga load?
3. What does it mean that led D402 turns on during this?

t.
i.a. for help
Alberto



Attiva Tiscali Voce 8 Mega: telefoni e navighi senza limiti a soli €15
AL MESE PER 1 ANNO. Dopo paghi €29,90 al mese. Attiva entro il 15/01/09!
http://abbonati.tiscali.it/promo/voce8mega/
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-01-15 23:26
(Received via mailing list)
On Thu, 2009-01-15 at 22:37 +0100, Alberto Trentadue wrote:

> It seems that I was wrong: USB2 driver seems to be working well, at least for the first
> configuration steps, because I am successful in configuring the Cypress FX2.
> Then it looks like the problem is actually
> in the next step, that is, loading the fpga bitstream 
/usr/local/hamradio/gnuradio/share/usrp/rev4/std_2rxhb_2tx.rbf

In my experience, a successful FX2 load followed by a failed FPGA load
is often due to poor USB physical integrity, such as a cable, connector,
or hub.  I know it sounds formulaic, but for whatever reason, I've
encountered this with the USRP on multiple occasions, where replacing
the cable with a different one, ensuring that has the 2.0 compliance
logo on it, fixes it.  YMMV, of course.

(Even more often it is due to not having a 2.0 controller, but you've
ruled that out already.)

-Johnathan
This topic is locked and can not be replied to.