Re: [Discuss-gnuradio] USRP EEPROMs

[Eric Blossom]

On Thu, Feb 10, 2005 at 08:54:17PM -0500, kilian wrote:
> Hi,
> 
> On Thu, 2005-02-10 at 12:25, Eric Blossom wrote:
> 
> > > to it. After I found out that I had to upload the firmware first, using
> > > 'burn-usrp2-eeprom', I ran test_usrp0 and got the following output:
> > 
> > First off do you have a rev0 or rev2 board?  The rev0 board doesn't
> > have any daughterboards, just SMA connectors on the board.  The rev2
> > board has connectors for daughterboards and is 160 x 160 mm.
> > 
> I have a rev2 board. The silk screen says Gnuradio rev3 btw.

News to me ;-)

[Matt, probably ought to use a separate assembly number, or fab number
 to keep track of minor changes.]

> > If you used burn-usrp2-eeprom and you have a usrp0 board,  you just
> > fried the board.  In 99.9999% of the cases there is no reason to use
> > burn-usrp2-eeprom. 
> Now I wonder why I did it. Right, the error message! This message talks
> about it:
> 
> http://lists.gnu.org/archive/html/discuss-gnuradio/2005-01/msg00130.html
> 
> >> TX d'board A: Invalid EEPROM contents
> >> TX d'board B: Invalid EEPROM contents
> >>
> >> You just need to run the script
> >>
> >> .../usrp/host/apps/burn-basic-eeprom
                             ^^^^^

Sorry that there isn't a bit more clarity about all this (and thanks
for helping us see what's missing in the "getting started"
department).

Here's a bit of background on the EEPROMs on the USRPs:

There are small EEPROM's (256 byte) on the motherboard AND on the
daughterboards.

The motherboard EEPROM contains the USB Vendor ID, Product ID & Device
ID.  In addition, it runs a very short program at power up that puts
the AD9862's into a relatively low-power state.  It's not the "real"
firmware. 

We can tell the hardware versions apart and whether or not you've
loaded the "real" firmware by the Device ID's.  (You can see this info
with usbview)

The "real" firmware is loaded over the USB when you attempt to use the
board.  It gets loaded automatically if you are using GNU Radio's usrp
module, or are using programs like test_usrp_standard_tx or rx.  They
are all based on the C++ classes usrp_standard and usrp_basic.  usrp_basic
takes care of loading the firmware and fpga for you when you create an
instance of the class.


The daughterboard EEPROMS contain three basic piece of information.

(1) an identifier that says what kind of daughterboard this is

(2) information that tells us which of the digital i/o pins are inputs
    to the FPGA and which are outputs from the FPGA.

(3) Calibration constants that store the correction factor for
    subtracting off the DC-offset reported by the A/D when there's no
    signal present.  The library code reads the values from the
    d'board EEPROM and then writes them into the FPGA where they are
    subtracted from the raw data at the head of the signal processing chain.


> Well 'burn-usrp2-eeprom' doesn't resolve that when I run 
> test_usrp_standard_rx, I hope 
> I can ignore that for now though.

You can ignore that for now.

> (Can there be endianess issues? The Mac is big-endian.)

[It's possible there's an endianness problem with the I&Q sample data.
We know that we're getting firmware into it OK because of your timing
results, blinking LEDs, etc.  Lets try some other things first, before
we head down that path.]


To fix this message: 

> TX d'board A: Invalid EEPROM contents
> TX d'board B: Invalid EEPROM contents
> RX d'board A: Invalid EEPROM contents
> RX d'board B: Invalid EEPROM contents

...use the command below.  Please note that the middle word is "basic" not 
"usrp2"

$ usrp/host/apps/burn-basic-eeprom -a

> When I run test_usrp_standard_tx I get
> # ./test_usrp_standard_tx
> TX d'board A: Invalid EEPROM contents
> TX d'board B: Invalid EEPROM contents
> tx_underrun
> ...
> xfered 5.37e+08 bytes in 22.5 seconds.  2.385e+07 bytes/sec.  cpu time =
> 2.03
> 32768 underruns
> 
> This is very nice, now I'm getting informed about underruns.
> 
> The the CVS based test_usrp_standard_rx gives:
> 
> # ./test_usrp_standard_rx
> RX d'board A: Invalid EEPROM contents
> RX d'board B: Invalid EEPROM contents
> rx_overrun
> ...
> xfered 1.34e+08 bytes in 4.44 seconds.  3.024e+07 bytes/sec.  cpu time =
> 0.4289
> noverruns = 41
>
> I checked the Makefile:
> # cat ../../../usrp-0.7/Makefile |grep FUSB_TECH
> FUSB_TECH = linux
> FUSB_TECH_darwin_FALSE =
> FUSB_TECH_darwin_TRUE = #
> FUSB_TECH_generic_FALSE =
> FUSB_TECH_generic_TRUE = #
> FUSB_TECH_linux_FALSE = #
> FUSB_TECH_linux_TRUE =


Good reports.  This all looks OK. 

It looks like your USB host controller won't sustain 32MB/sec.

Try running it at 16MB/sec (== 4M samples/sec)

$ ./test_usrp_standard_tx -I 32

$ ./test_usrp_standard_rx -D 16

You might see 1 or 2 underruns at the beginning.  That's normal.


> > Try test_usrp_standard_tx and test_usrp_standard_rx.
> > 
> > With test_usrp_standard_tx mess around with the -I <interp> option to
> > control that data rate across the USB.  The sample rate across the USB
> > on transmit is 128e6 / <interp>.  The data rate in bytes/sec across
> > the USB is sample_rate * 4.  You should see a sine wave out I & Q.
> > 
> Well, not until I get a scope and/or an SMA cable. I guess I go and read
> up on some things until then. 
> 
> Regards,
> Kilian

Thanks for all your good reports.

Please keep us posted.

Eric