Re: [Discuss-gnuradio] usrper fails in usb_claim_interface

[James Cooley]

THAT is exactly it. I think I have a scenario where it happens:

You've done some stuff with usrp so that it and daughter card gets 
loaded up.
You finish up, exit, rip out the power cable, plug in the power again 
and the usrp USB gets re-registered.
Then, (with the verbose flag turned on) I see that the usrp and daughter 
card think the firmware is already loaded. Yes, even though I just 
ripped the power cable out for 30 seconds. Maybe the RAM that holds the 
valid flag is randomly corrupt or something as things are powered up? 
Maybe the randomness differs as the usrp has been used for a while and 
heats up?

In any case, a quick force reload does the trick.
> usrper load_standard_bits

-j


Eric Blossom wrote:

> On Wed, Apr 27, 2005 at 11:19:37PM -0400, James Cooley wrote:
>  
>
> > How does the USRP know to load its firmware?
> >    
>
> Every time you instantiate a usrp source or sink it checks to see if
> it needs firmware and/or an fpga bitstream.  The library code checks
> two MD5 hashes that are stored in the FX2 ram, one for the firmware
> and one for the fpga configuration.  Loading both takes about
> 12 seconds.
>
>  
>
> > I notice the first time I 
> > run, there's a bit of a delay as stuff happens behind the scenes. It may 
> > be the case that if it has already been loaded (or thinks it has), this 
> > situation happens. Is there a way to force a re-load or whatever else is 
> > going on?
> >    
>
> You shouldn't need to force a reload.
>
> If you want to try forcing a reload use this:
>
>  $ usrper load_standard_bits
>
>
> If you want to see diagnostic messages when it's checking and/or
> loading the firmware and/or fpga, change the definition of VERBOSE on
> line 47 of usrp_prims.cc from 0 to 1.
>
>  
>
> > This is a debian testing distro with a 2.6.10 kernel on top.
> >    
>
> Thanks,
> Eric
>
>