arm_rfft_fast_f32() fails with 128 points but works with 256 or 512?

[WP_it]

I have been trying to get the CMSIS DSP FFT function to work on my NUCLEO-F446RE and have a confusing observation after hours of troubleshooting: when I try to use 128 points for the FFT data I get a Hard Fault, but change the number of points to 256 or 512 and it works as expected. I'm only using sample data of a sin wave so no changes other than number of points.

Has anyone seen this before? As I step through trying to debug why 128 points doesn't work it looks like the arm_rfft_fast_init_f32() call is the issue. No doubt related, but when I try to Step Into the rfft_fast_init() call I get the following error:

Can't find a source file at "C:\Users\clamar01\fork3\CMSIS_5\CMSIS\DSP\Projects\GCC/../../Source/TransformFunctions/arm_rfft_fast_init_f32.c" 

Locate the file or edit the source lookup path to include its location.

Funny thing is I don't know who user clamar01 is...no user on my computer. I added the DSP module from X-CUBE-ALGOBUILD.

Snippet below of key statements in my sample project.

#define NUM_PTS 512 //For some reason fails with 128 samples!
 
float32_t vals[NUM_PTS];
float32_t fftout[NUM_PTS];
 
//Sample Data for FFT
for (int i=0;i<NUM_PTS;++i)
 {
	 vals[i]=AMPLITUDE*sin(i/SAMPLE_FREQ* 2.0*3.14159*FREQ);
 }
 
//Initialize
arm_rfft_fast_init_f32(&fft_instance, NUM_PTS);
 
//Do FFT. 0=regular FFT not Inverse FFT
arm_rfft_fast_f32(&fft_instance, vals, fftout, 0);

Any ideas why 128 isn't working when the documentation says otherwise?

Stupid user problem no doubt but I am out of ideas and appreciate your help.

Thank You

[LS1]

The absolute path ("...\Users\clamar01\...") seems to be a leftover from signal processing engineer "Claudio Martino" at ARM in their CMSIS library files. We get the same message when debugging, but in conjunction with a different function call ("arm_max_q15()").

Screen shot:

[MarcinEL83]

Hey,

did You manage to solve issue with this absolute path? We are facing the same problem with LMS function call (with cmsis downloaded from G4 Cube repository). When we integrated project with CMSIS 5 through software pack in CubeMX there is exactly the same problem but with another username...

[LS1]

The easy way is not to debug CMSIS functions. Simply skip the functions when debugging. The orderly way would be to report this problem to ARM. However, I suspect this way is unsuccessful as the code parts were probably intentionally hidden in a library. The harder solution would be to use the free Open CMSIS package instead of the original ARM CMSIS library. In case of doubt, however, this may lead to new problems.

[jbrUCLM]

Hello @WP_it !

I recently came accross the same problem as you did months ago. I've only discovered that the Hard Fault is caused due to a null pointer returned by the initialization function of the FFT instance. The reason? 128 is not supported "

ARM_MATH_ARGUMENT_ERROR".

I'm developing under Visual Studio Code SDK and, honestly, don't know the version of the CMSIS-DSP library I'm using. This is my next step.

 

In the meanwhile, does anybody find a solution or know the roor cause for this issue?

 

Regards,

 

JB

[Rob.Riggs]

@jbrUCLM 

https://github.com/ARM-software/CMSIS-DSP/blob/main/Source/TransformFunctions/arm_rfft_fast_init_f32.c

 

The code says otherwise. Something else is going on.