|
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 256-pt 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 256-pt 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, 20042004-10-05
|
Deepak- You are trying to debug too much at one time. Try passing this to rfft(): -x[0] = 1 -x[2, 4, ...NX-2] = 0 -x[1, 3, ...NX-1] = 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 256-pt 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 256-pt 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, 20042004-10-05
|
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 (p-33) 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 512-word 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, ...NX-2] = 0 > -x[1, 3, ...NX-1] = 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 256-pt 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 256-pt 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, 20042004-10-06
|
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 (p-33) 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 512-word 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 chip-level "circular address mode". Some DSP devices even offer "bit-reversed" 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, ...NX-2] = 0 > > -x[1, 3, ...NX-1] = 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 256-pt 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 256-pt 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 > > |
