CMSIS: DSP Lib - Frequency Bin Example

[rs2]

Posted on May 22, 2015 at 16:18

Estimated colleagues,

following I explain the strange behavior:

•     I am working the STM32F407 ARM processor,
•     compiling with the GNU Tools ARM (4_9-2014q4) ,
•     use the HAL provided by STM32CubeF4 v1.5.0,
•     using the DSPLib provided CMSIS Version 1.4.4 2014/07/31 ,
•     UPDATE 2015-05-22:    I also tried this with the last MDK-ARM version (uVIsion V5.14.0.0) and the provided CMSIS/DSP_Lib examples and the STM32F4-Discovery board and found the same effect.

During testing my board with the ''Frequency Bin Example'' provided with the DSP Lib I found following effects: A) The example test program provided by CMSIS works fine. That is testIndex equals to refIndex (which is 213) and goes to infinite loop. B) But when I modify the program e.g. with a while() in order to execute cyclically like this

...global and extern variables...

void main(void) {   arm_status status;   float32_t maxValue;     while(1)    {        status = ARM_MATH_SUCCESS;        /* Process the data through the CFFT/CIFFT module */        arm_cfft_f32(&arm_cfft_sR_f32_len1024, testInput_f32_10khz, ifftFlag, doBitReverse);        /* Process the data through the Complex Magnitude Module for        calculating the magnitude at each bin */        arm_cmplx_mag_f32(testInput_f32_10khz, testOutput, fftSize);        /* Calculates maxValue and returns corresponding BIN value */        arm_max_f32(testOutput, fftSize, &maxValue, &testIndex);        if(testIndex !=  refIndex)        {          status = ARM_MATH_TEST_FAILURE;        }      } } the program throws ARM_MATH_TEST_FAILURE the second time. C) If I define testInput_f32_10khz[] as a constant array on the flash then the program throws ARM_MATH_TEST_FAILURE always. The problem does not have to do with the bit reversal problem of old versions (so much as I could see from other discussions). I am using the sources not the library (because only the ARM library is provided with STMCube.   Why is a wrong calculation the second time? Is this an initialization problem? Hopefully someone can help me or give me some tip. Thank you in advance!. PS: I posted this in the ARM Community ten days ago without any answer (http://community.arm.com/message/27591&sharp27591). #arm-cmsis-dsp

[AvaTar]

Posted on May 22, 2015 at 20:15

Just looking at the calls

...

  arm_cfft_f32(&arm_cfft_sR_f32_len1024, testInput_f32_10khz, ifftFlag, doBitReverse);

 ...   arm_cmplx_mag_f32(testInput_f32_10khz, testOutput, fftSize); suggests an in-place operation - the fft function only takes a ''testInput'' array as parameter, but no output array. The 'arm_cmplx_mag' function, which (if I remember correctly) calculates the magnitudes from the real/imaginary components, accepts that ''testInput'' array as input. No wonder it fails with the second call ... To be sure, just check the source code for yourself.

[rs2]

Posted on May 27, 2015 at 10:54

Thank you for your response.

I tried with Keil uVision5 and it works correctly but I have problem when using GNU ARM compiler. The calculated refIdx is 615 (instead 213). In GNU ARM I have defined:

• ARM_MATH_CM4
• __USE_CMSIS
• __FPU_PRESENT=1
• __FPU_USED=1
• STM32F407xx

Target:

• cortex-m4
• Architecture-> Toolchain default
• Little Endian
• Float ABI -> Library with FP (softfp)
• FPU Type -> fpv4-sp-d16

I use softfp because I cant compile with hard float (I need the PDM Filter Library).

When I start a record the FFT seems to detect tones giving a fixed index and a high max value but with the example gives me a wrong index. Any suggestions? Thanks in advance!

[AvaTar]

Posted on May 27, 2015 at 12:37

The calculated refIdx is 615 (instead 213). ...

Any suggestions? Dunno. I had tried this FFT bin example about two years ago, using the gcc-based Crossworks toolchain. But this was, if I remember correctly, CMSIS 1.x. You can add debug code, and compare the input/output data the the cfft routine. BTW, I used the DSP Lib sources at this time, the precompiled libs did not work for me.I tried with Keil uVision5 and it works correctly... So why not sticking to Keil uV5 ?

[rs2]

Posted on May 27, 2015 at 16:44

I am sorry, it was my fault! It works perfectly!

In the program I was writting I set a bitreverse to zero (which obviously gave me another index)! When setting bitreverse to ''1'' I get the index 213 with the GNU ARM compiler too. Thank you for your time!!