Hello everybody, I am wondering if any experts here could help solve my problems with using rfft (routine from TI's dsplib) on a 5402 DSP. Here is my scenario, Codec > DMA (block size = 256 samples) > CPU (do 256pt FFT) > see results by plotting a graph (in CCS). The codec and DMA are setup correctly, the codec input is a 1Khz sine wave, and the codec samples @ 40KHz. I can see the input data in the dma destination buffer and it looks good. I copy the DMA destination buffer to an array x which is defined as, #define NX 256 #pragma DATA_SECTION (x,".inputdata") DATA x[NX]; The data copied into 'x' is not corrupted in any way, i checked that. Now i am trying to do a 256pt real FFT using the rfft routine from TI's dsplib library. This is the way i invoke rfft, cbrev(x,x,NX/2); rfft(x,NX,1); After this when i plot 'x', i don't see a single peak in the frequency domain, rather the o/p looks like the FFT of some broadband audio. Can somebody please explain what i am doing wrong? Thanks in advance, Deepak. 

RFFT from dsplib not working...
Started by ●October 5, 2004
Reply by ●October 5, 200420041005
Deepak You are trying to debug too much at one time. Try passing this to rfft(): x[0] = 1 x[2, 4, ...NX2] = 0 x[1, 3, ...NX1] = 0 That should produce all 1's in the magnitude domain (remember your basic impulse response, haha). If you don't get a correct result, then you know cbrev() or rfft() is the problem. You can try the same thing without calling cbrev() and eliminate it as well. Otherwise your audio/dma is the problem (which I suspect). Jeff pet_dsp wrote: > > Hello everybody, > I am wondering if any experts here could help solve > my problems with using rfft (routine from TI's dsplib) on a 5402 DSP. > Here is my scenario, > > Codec > DMA (block size = 256 samples) > CPU (do 256pt FFT) > > see results by plotting a graph (in CCS). > > The codec and DMA are setup correctly, the codec > input is a 1Khz sine wave, and the codec samples @ 40KHz. I can see > the input data in the dma destination buffer and it looks good. I > copy the DMA destination buffer to an array x which is defined as, > > #define NX 256 > #pragma DATA_SECTION (x,".inputdata") > DATA x[NX]; > > The data copied into 'x' is not corrupted in any > way, i checked that. Now i am trying to do a 256pt real FFT using > the rfft routine from TI's dsplib library. This is the way i invoke > rfft, > > cbrev(x,x,NX/2); > rfft(x,NX,1); > > After this when i plot 'x', i don't see a single > peak in the frequency domain, rather the o/p looks like the FFT of > some broadband audio. Can somebody please explain what i am doing > wrong? > > Thanks in advance, > Deepak. 

Reply by ●October 5, 200420041005
Jeff, Just figured out the problem. The problem is with the memory alignment of the array 'x' that is input to the cbrev funtion. Document spru518c (p33) says, "input data (x) must be aligned at 2*nx boundary. The log(nx) + 1 LSBits of address x must be zero." I did not align 'x' on a 512word boundary (log(256)+1 LSB's must have been 0). Once i fixed this in the linker definition file, i got the fft results as expected for a sine wave input. Anyways, thank you for a useful debugging tip. Best regards, Deepak.  In , Jeff Brower <jbrower@s...> wrote: > Deepak > > You are trying to debug too much at one time. Try passing this to rfft(): > > x[0] = 1 > x[2, 4, ...NX2] = 0 > x[1, 3, ...NX1] = 0 > > That should produce all 1's in the magnitude domain (remember your basic impulse > response, haha). If you don't get a correct result, then you know cbrev() or rfft() > is the problem. You can try the same thing without calling cbrev() and eliminate it > as well. Otherwise your audio/dma is the problem (which I suspect). > > Jeff > pet_dsp wrote: > > > > Hello everybody, > > I am wondering if any experts here could help solve > > my problems with using rfft (routine from TI's dsplib) on a 5402 DSP. > > Here is my scenario, > > > > Codec > DMA (block size = 256 samples) > CPU (do 256pt FFT)  > > > see results by plotting a graph (in CCS). > > > > The codec and DMA are setup correctly, the codec > > input is a 1Khz sine wave, and the codec samples @ 40KHz. I can see > > the input data in the dma destination buffer and it looks good. I > > copy the DMA destination buffer to an array x which is defined as, > > > > #define NX 256 > > #pragma DATA_SECTION (x,".inputdata") > > DATA x[NX]; > > > > The data copied into 'x' is not corrupted in any > > way, i checked that. Now i am trying to do a 256pt real FFT using > > the rfft routine from TI's dsplib library. This is the way i invoke > > rfft, > > > > cbrev(x,x,NX/2); > > rfft(x,NX,1); > > > > After this when i plot 'x', i don't see a single > > peak in the frequency domain, rather the o/p looks like the FFT of > > some broadband audio. Can somebody please explain what i am doing > > wrong? > > > > Thanks in advance, > > Deepak. 
Reply by ●October 6, 200420041006
Deepak > Just figured out the problem. The problem is with the memory > alignment of the array 'x' that is input to the cbrev funtion. > Document spru518c (p33) says, "input data (x) must be aligned > at 2*nx boundary. The log(nx) + 1 LSBits of address x must be zero." > I did not align 'x' on a 512word boundary (log(256)+1 LSB's must > have been 0). Once i fixed this in the linker definition file, i got > the fft results as expected for a sine wave input. > Anyways, thank you for a useful debugging tip. Ok then you're on your way. The 2*nx alignment is because the .asm language instructions inside rfft() uses a chiplevel "circular address mode". Some DSP devices even offer "bitreversed" addressing mode. Jeff >  In , Jeff Brower <jbrower@s...> wrote: > > Deepak > > > > You are trying to debug too much at one time. Try passing this to > rfft(): > > > > x[0] = 1 > > x[2, 4, ...NX2] = 0 > > x[1, 3, ...NX1] = 0 > > > > That should produce all 1's in the magnitude domain (remember your > basic impulse > > response, haha). If you don't get a correct result, then you know > cbrev() or rfft() > > is the problem. You can try the same thing without calling cbrev() > and eliminate it > > as well. Otherwise your audio/dma is the problem (which I > suspect). > > > > Jeff > > > > > > pet_dsp wrote: > > > > > > Hello everybody, > > > I am wondering if any experts here could help > solve > > > my problems with using rfft (routine from TI's dsplib) on a 5402 > DSP. > > > Here is my scenario, > > > > > > Codec > DMA (block size = 256 samples) > CPU (do 256pt FFT)  > > > > > see results by plotting a graph (in CCS). > > > > > > The codec and DMA are setup correctly, the codec > > > input is a 1Khz sine wave, and the codec samples @ 40KHz. I can > see > > > the input data in the dma destination buffer and it looks good. I > > > copy the DMA destination buffer to an array x which is defined as, > > > > > > #define NX 256 > > > #pragma DATA_SECTION (x,".inputdata") > > > DATA x[NX]; > > > > > > The data copied into 'x' is not corrupted in any > > > way, i checked that. Now i am trying to do a 256pt real FFT using > > > the rfft routine from TI's dsplib library. This is the way i > invoke > > > rfft, > > > > > > cbrev(x,x,NX/2); > > > rfft(x,NX,1); > > > > > > After this when i plot 'x', i don't see a > single > > > peak in the frequency domain, rather the o/p looks like the FFT of > > > some broadband audio. Can somebody please explain what i am doing > > > wrong? > > > > > > Thanks in advance, > > > Deepak. > > _____________________________________ > Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > > _____________________________________ > About this discussion group: > > To Join: Send an email to > > To Post: Send an email to > > To Leave: Send an email to > > Archives: http://www.yahoogroups.com/group/c54x > > Other Groups: http://www.dsprelated.com > > Yahoo! Groups Links > > 