crashing a Core-M4 MCU using the ```arm_rfft_fast_f32``` function for a specific FFT length

[jerabaul29]

I am programming an Ambiq Apollo 3 MCU (using a Sparkfun board and their "arduino core", if this is useful to know). The "arduino core" now gives access to the CMSIS function :) .

I have notived something weird though. I am looking at how to use the arm_rfft_fast_f32 function (I have a small example recipe here: https://github.com/jerabaul29/Artemis_MbedOS_recipes/blob/main/recipes/recipe_CMSIS_FFT_fft_init/recipe_CMSIS_FFT_fft_init.ino ). Basically just having a look around:

  // compute a FFT
  Serial.println(F("start init fast struct"));
  arm_rfft_fast_init_f32(&crrt_arm_rfft_fast_instance_f32, SAMPLES);                          // get ready
  Serial.println(F("done init fast struct"));
  Serial.println(F("start take FFT"));
  arm_rfft_fast_f32(&crrt_arm_rfft_fast_instance_f32, fft_input, fft_output, forward_fft);    // take the FFT
  Serial.println(F("done take FFT"));
  Serial.println();

I have tried all the FFT lengths listed on the documentation page here: https://www.keil.com/pack/doc/CMSIS/DSP/html/group__RealFFT.html#gac5fceb172551e7c11eb4d0e17ef15aa3 .

I noticed something weird. My recipe works fine for all FFT lengths in the documentation, except for a FFT length of 128, in which case the MCU crashes. I do not have a JTAG or similar debugger, but in the case of a FFT length 128, the last thing I see is the "start take FFT" message, after that things just stop.

• any idea what is causing this problem?
• any idea why this happens specifically if I use a length 128?
• where do you think the bug comes from / any idea of possible fixes?

[jerabaul29]

Is it possible that this may be a duplicate of https://github.com/ARM-software/CMSIS_5/issues/658 ? Do you know why / how this problem is still present? :) .

[christophe0606]

@jerabaul29 You are using the develop branch ?

Because I don't see anything special with the length 128 and the issue #658 has been corrected.

I'll rerun my tests.

Which compiler are you using ? gcc ?

[jerabaul29]

Mmmh, I do not want to give the wrong answer, @Wenn0101 do you think you could provide the information? :) Thanks :) .

[christophe0606]

My tests are passing for RFFT 128 on M4 using either gcc or clang.

Can you check the return status code of arm_rfft_fast_init_f32 and see if it is different for length 128 ?

[jerabaul29]

Nice catch, I think that is the root cause indeed :)

running:

  // compute a FFT
  Serial.println(F("start init fast struct"));
  crrt_arm_status = arm_rfft_fast_init_f32(&crrt_arm_rfft_fast_instance_f32, SAMPLES);                          // get ready
  Serial.print(F("done init fast struct, status: ")); Serial.println(crrt_arm_status);
  Serial.println(F("start take FFT"));
  arm_rfft_fast_f32(&crrt_arm_rfft_fast_instance_f32, fft_input, fft_output, forward_fft);    // take the FFT; no status here!
  Serial.print(F("done take FFT")); Serial.println();
  Serial.println();

I get with length 128:

start init fast struct
done init fast struct, status: -1
start take FFT

So I suppose this means there is a bug for this specific length in arm_rfft_fast_init_f32 rather? Should I guess that your tests use the precomputed tables and this is why they pass? :) .

[jerabaul29]

(for other lengths I get the expected 0 status return code for the init function call :) ).

[christophe0606]

It looks similar to the bug there was in the old issue #658 . The case for length 128 was wrong in the initialization function.

So I guess you may not have a recent enough CMSIS-DSP.

If you have access to the code of your version, can you have a look if the case for length 128 is calling function arm_rfft_128_fast_init_f32

It is in the switch / case at the very end of arm_rfft_fast_init_f32

[jerabaul29]

Ok, I think that I do not have access to the binaries (looks like it ships already compiled in my "bundle"), but it looks like the math headers are from 2019. Guess that could explain the problem. Many thanks for your help, waiting to see what @Wenn0101 can tell about that, sorry for the time you spent on it if this is just an old version issue...