# USRP1 FPGA modification problem

**URL:** <https://www.ruby-forum.com/t/usrp1-fpga-modification-problem/207555>\
**Category:** GNU Radio\
**Created:** [May 27, 2011, 9:51pm UTC](https://www.ruby-forum.com/t/usrp1-fpga-modification-problem/207555 "2011-05-27T21:51:52Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [May 27, 2011, 9:51pm UTC](https://www.ruby-forum.com/t/usrp1-fpga-modification-problem/207555/1 "2011-05-27T21:51:52Z")

</div>

Hi,

We have been working with an (old) USRP1 and doing some modifications in  
the  
FPGA code. After our modifications (we added an extra layer of DDCs to  
perform channel separation in the FPGA), the things didn’t work as  
expected.

In some Gnuradio applications the USRP stops sending samples after some  
time. For example, usrp\_fft.py runs just fine all the time, but  
usrp\_rx\_cfile.py and usrp\_wfm\_rcv.py work for some secs and then the  
USRP  
stops sending samples.

I added some pics of our preliminary debugging. In the figures, the  
yellow,  
blue and red signals refer to the have\_pkt\_rdy, RD and OE signals,  
respectively. After some time, the Cypress stops setting RD and OE  
signals  
in response to the assertion of have\_pkt\_rdy (first figure). Latter, the  
USB  
FIFO in the FPGA overflows and then have\_pkt\_rdy goes down (figure 2).  
So it  
seems the problem is not with our modifications in the FPGA code but  
with  
something related to the Cypress.

Have someone ever had a similar problem ? Any clue in how to solve this  
would help a lot. We are using Gnuradio 3.2.2.

The funny thing is that usrp\_fft.py works perfectly (we double checked  
all  
\*.py to make sure our new bitstream is always being loadded and our new  
DDCs  
are being properly configured).

Thanks.

Regards,  
Tiago.

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 14, 2011, 9:20pm UTC](https://www.ruby-forum.com/t/usrp1-fpga-modification-problem/207555/2 "2011-06-14T21:20:14Z")

</div>

Hi,

Have anyone taken a look at this ?

We are still struggling to find a solution to this problem. Any tip  
would  
help a lot.

Thanks,  
Tiago

Em 27 de maio de 2011 16:51, Tiago Rogrio Mck  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)escreveu:

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 15, 2011, 8:55pm UTC](https://www.ruby-forum.com/t/usrp1-fpga-modification-problem/207555/3 "2011-06-15T20:55:15Z")

</div>

Tiago,

It is very hard to help you. You are basically saying “we did something  
different and it doesn’t work.” You haven’t posted code, you’re using  
an old version of GNU Radio, and not using the latest drivers (UHD).  
This all makes it hard to help you.

If the FPGA is asserting have\_pkt\_rdy, the FX2 is not setting RD and OE,  
and you haven’t changed the code running in theFX2, then it is likely  
that your app on the host has died or closed.

Matt

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 15, 2011, 10:06pm UTC](https://www.ruby-forum.com/t/usrp1-fpga-modification-problem/207555/4 "2011-06-15T22:06:22Z")

</div>

Hi,

Thank you for your attention.

We know that we are working with old versions and this is a problem.  
We’ve  
had some previous modifications, and it seemed easier to keep working  
with  
them instead of porting everything to the latest firmware/drivers.

Anyway, we will take a closer look into what is happening on the host.

Thanks,  
Tiago

Em 15 de junho de 2011 14:05, Matt E. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) escreveu:
