A nasty and undocumented bug in ICFFT_F32 function (DSP lib v1.31)

UPDATE:

This bug occurs as well in ICFFT_F32 routine in the newest DSP library v1.40.

It occurs when the .ebss section of the ICFFT_F32 aligns to the odd 16-bit address in memory. After calling the ICFFT, the 16-bit word above that address will be corrupted.

Example of alignment that causes the problem:

0000ffc0 00000025 FFT.obj (SaramSpecSection)
0000ffe5 00000014 c28x_fpu_dsp_library.lib : ICFFT_f32.obj (.ebss)

If you have a variable under the 0000ffe4 address it WILL be corrupted after calling ICFFT_F32().

Example of alignment when bug does not occur (even address):

0000ffc0 00000024 FFT.obj (SaramSpecSection)
0000ffe4 00000014 c28x_fpu_dsp_library.lib : ICFFT_f32.obj (.ebss)

To pinpoint this I've created a special section (SaramSpecSection) for variables of ICFFT and some dummy buffer, because the linker not always will align it to odd address.

You can workaround this problem by creating a special ebss section for ICFFT_F32 wit aligning to 32-bit memory address.

A question to TI folks: How about other FFT routines in the lib? I didn't check them yet.

Regards, Andy

Hi Andy,

I see the issue. Some of the global variables (32-bit vars) for the FFT routines are placed in the .ebss sector without aligning them on a long word boundary. For example, in the ICFFT routine we have

_CFFTF32_vars_InPtr         .usect .ebss,2,1,0

which should have been declared as 

_CFFTF32_vars_InPtr         .usect .ebss,2,1,1

That last 1 indicates alignment. if a 32-bit access is taking place it will always read from the even address, so if the variable is a@ 0x25 and you did a 

MOVL @0x25, ACC, what it actually does is 

MOVL @0x24, ACC thereby overwriting whatever was at 0x24.

I will file this as a bug, and yes, its in all the FFT routines in this library. For the time being, your solution of allocating a special .ebss section and aligning it is a good workaround till i release the next revision.

For example, you use CFFT and ICFFT in your project, in the linker command file add this

.ebss:fpu_lib      > RAML2, ALIGN=32, PAGE=1
{
 -l=c28x_fpu_dsp_library.lib<CFFT_f32.obj> (.ebss)
 -l=c28x_fpu_dsp_library.lib<ICFFT_f32.obj> (.ebss)
}
   
.ebss            : > RAML2,     PAGE = 1

In the map file you will see the aligned sections as follows:

.ebss      1    0000a002    00000019     UNINITIALIZED
                0000a002    00000010     test_fpu_icfftf32.obj (.ebss)
                0000a012    00000004     rts2800_fpu32.lib : _lock.obj (.ebss)
                0000a016    00000004                       : exit.obj (.ebss)
                0000a01a    00000001                       : errno.obj (.ebss)

.ebss:fpu_lib 
*          1    0000a020    00000034     UNINITIALIZED
                0000a020    00000014     c28x_fpu_dsp_library.lib : CFFT_f32.obj (.ebss)
                0000a034    0000000c     --HOLE--
                0000a040    00000014                              : ICFFT_f32.obj (.ebss)

I apologize for any setbacks this issue may have caused.

Code doesn't show up

"

For example, you use CFFT and ICFFT in your project, in the linker command file add this

.ebss:fpu_lib > RAML2, ALIGN=32, PAGE=1
{
-l=c28x_fpu_dsp_library.lib<CFFT_f32.obj> (.ebss)
-l=c28x_fpu_dsp_library.lib<ICFFT_f32.obj> (.ebss)
}

.ebss : > RAML2, PAGE = 1

In the map file you will see the aligned sections as follows:

.ebss 1 0000a002 00000019 UNINITIALIZED
0000a002 00000010 test_fpu_icfftf32.obj (.ebss)
0000a012 00000004 rts2800_fpu32.lib : _lock.obj (.ebss)
0000a016 00000004 : exit.obj (.ebss)
0000a01a 00000001 : errno.obj (.ebss)

.ebss:fpu_lib
* 1 0000a020 00000034 UNINITIALIZED
0000a020 00000014 c28x_fpu_dsp_library.lib : CFFT_f32.obj (.ebss)
0000a034 0000000c --HOLE--
0000a040 00000014 : ICFFT_f32.obj (.ebss)

Vishal_Coelho said:

I will file this as a bug, and yes, its in all the FFT routines in this library.

Are you sure that the bug occurs in all FFT routines in the library (v1.40)?

Only the following uses .ebss variables:

CFFT_F32

CFFT_F32U

ICFFT_F32

It seems that none of the RFFT routines are affected by the bug. Am I right?

Regards, Andy

Hi Vishal,

I'm experiencing bad performance of the cfft_f32 from fpu library.  Very infrequently, the output will be incorrect.  I found this problem because we take the rms value and with a return on a low rms value our software will set a flag.  Going to the root cause, I was able to verify the input buffer to the cfft was correct by performing an fft using excel.  The problem is with the output of the cfft.

Could this bug be related to my problem? I am using F28M35H52C device.

Sincerely,

Suzanne