Uspr2 working intermittently/segmentation fault

GNU Radio
1

Hello,

I am running gnuradio on a Linux x86_64 box, fedora10. I downloaded the
code from the development trunk on 2/26/09. Lately I notice that my
uspr2 has been working intermittently. Sometimes, even running the
example code would give me a segmentation fault error or errors like the
one listed below.

If I turn the uspr2 off and back on then rerun the program, the program
will run again okay.

Has someone seen this behavior before or had any explanation for why it
behaves that way.

Also, is there a command to reboot/reset the uspr2 instead of turning
the power off and on?

Thanks!

./usrp2_fft_copy.py (which is an exact copy of the usrp2_fft.py in
the example)

usrp2: failed to enable realtime scheduling

Traceback (most recent call last):

File “./usrp2_fft_copy.py”, line 290, in 

main ()

File “./usrp2_fft_copy.py”, line 286, in main

app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)

File
“/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 36, in init

wx.App.__init__ (self, redirect=False)

File
“/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7935, in init

self._BootstrapApp()

File
“/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7509, in _BootstrapApp

return _core_.PyApp__BootstrapApp(*args, **kwargs)

File
“/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 39, in OnInit

frame = stdframe (self.top_block_maker, self.title, self._nstatus)

File
“/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 60, in init

self.panel = stdpanel (self, self, top_block_maker)

File
“/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 81, in init

self.top_block = top_block_maker (frame, self, vbox, sys.argv)

File “./usrp2_fft_copy.py”, line 70, in init

self.u = usrp2.source_32fc(options.interface, options.mac_addr)

File “/usr/local/lib64/python2.5/site-packages/gnuradio/usrp2.py”,
line 577, in source_32fc

return _usrp2.source_32fc(*args, **kwargs)

RuntimeError: Unable to retrieve daughterboard info

2

On Wed, Apr 01, 2009 at 03:00:57PM -0600, Pham, Thanh wrote:

Has someone seen this behavior before or had any explanation for why it
behaves that way.

Also, is there a command to reboot/reset the uspr2 instead of turning
the power off and on?

Thanks!

It appears that you do not have the current firmware (and possibly
FPGA image) installed on the SD Card. Please grab the latest from:
http://gnuradio.org/releases/usrp2-bin/trunk/

Eric

3

Eric B. wrote:

It appears that you do not have the current firmware (and possibly
FPGA image) installed on the SD Card. Please grab the latest from:
http://gnuradio.org/releases/usrp2-bin/trunk/

Eric

set-curmudgeon-mode(True)

Segmentation Fault on the host should never be the correct response to
buggy firmware on the USRP2. Ever.

set-curmudgeon-mode(False)

–
Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium

4

On Wed, Apr 01, 2009 at 06:45:59PM -0400, Marcus D. Leech wrote:

buggy firmware on the USRP2. Ever.

set-curmudgeon-mode(False)

I agree whole heartedly. (There was no evidence of a segfault in the
back trace presented.) FWIW, Johnathan fixed a problem not long ago
where there was a missing throw(…) annotation in a .i file.

We’ve also got ticket:346 open, “write python QA code for all possible
exceptions from all blocks”. It’s on the list of tickets to be fixed
before 3.2.0 goes out the door.

For those of you wondering where we are on 3.2.0, this query
will get you all of the gating tickets:

http://gnuradio.org/trac/query?status=assigned&status=new&status=reopened&group=type&order=priority&col=id&col=summary&col=owner&col=priority&col=component&col=version&milestone=release-3.2.0

Eric

5

Marcus-

buggy firmware on the USRP2. Ever.
Not everything the FPGA does – register format/contents, FIFO widths,
etc – can be
error checked. There has to be some reasonable expectation on the
software side.
The typical method is a “revision id” register, the software checks this
and adjusts
capabilities. If the revision is too far behind or doesn’t match
expectation then
the software gives an error message.

-Jeff

6

Jeff B. wrote:

Not everything the FPGA does – register format/contents, FIFO widths, etc – can be
error checked. There has to be some reasonable expectation on the software side.
The typical method is a “revision id” register, the software checks this and adjusts
capabilities. If the revision is too far behind or doesn’t match expectation then
the software gives an error message.

-Jeff

An error in the (expected) format of an external input should never
result in a Seg Fault. Nothing wrong with doing
“Gee, this parameter seems rather odd, I’m leaving”.

Two decades of writing network protocol implementations has taught me
that making dangerous assumptions about external
inputs leads to various not-nice things happening, and notorious in
the press in the context of network protocols, those
assumptions often lead to ugly security problems (note the SNMPV3
parser issues of a few years ago!). No security issues
here, to be sure, but being insufficiently paranoid about external
inputs of any kind has leads to spectacular downfall…

Provoking a Segmentation Fault is just impolite, if nothing else.

–
Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium

7

I am using the two lines in the rx_nop_handler.h to print out the
timestamp.
printf(“W0: %08x TS: %08x\n”, metadata->word0,
metadata->timestamp);
printf(“I0: %08x\n”, items[0]);

Looking at the timestamp that was printed out from usrp2_fft.py, I
notice that there is always a few extra ticks in the first frame.
I’m trying to understand why. Does someone have an explanation? Thanks!

TS (hex) TS(decimal) # of ticks in frame
(decim_rate=16)
507c5e55 1350327893
507c7594 1350333844 5951 (1st frame has 15 extra ticks,
this number changes with decimation rate but not consistent)
507c8cc4 1350339780 5936
507ca3f4 1350345716 5936
507cbb24 1350351652 5936
507cd254 1350357588 5936
507ce984 1350363524 5936
507d00b4 1350369460 5936
507d17e4 1350375396 5936
507d2f14 1350381332 5936
507d4644 1350387268 5936
507d5d74 1350393204 5936
507d74a4 1350399140 5936
507d8bd4 1350405076 5936
507da304 1350411012 5936
507dba34 1350416948 5936
507dd164 1350422884 5936
507de894 1350428820 5936
507dffc4 1350434756 5936
507e16f4 1350440692 5936
507e2e24 1350446628 5936

8

It seems to run a lot better now after I reinstalled the latest firmware
on the SD Card.
Thank you.

Thanh