Re: [Discuss-gnuradio] USRP1 FPGA modification problem.
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 On 06/14/2011 11:52 AM, Tiago Rogério Mück wrote: 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 Rogério Mück ti...@lisha.ufsc.br mailto:ti...@lisha.ufsc.br escreveu: 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 FPGA modification problem.
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 Ettus m...@ettus.com escreveu: 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 On 06/14/2011 11:52 AM, Tiago Rogério Mück wrote: 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 Rogério Mück ti...@lisha.ufsc.br mailto:ti...@lisha.ufsc.br escreveu: 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 FPGA modification problem.
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 Rogério Mück ti...@lisha.ufsc.brescreveu: 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 FPGA modification problem.
On 14/06/2011 2:52 PM, Tiago Rogério Mück wrote: 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 Rogério Mück ti...@lisha.ufsc.br mailto:ti...@lisha.ufsc.br escreveu: 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. The problem you'll have is that 99% of the people on this list use the stock FPGA images, and never venture into doing custom FPGA work. And the remainder, who *do* muck with the FPGA code, usually do so on the USRP2/N2xxx family. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
