CMSIS DSP V5.6.0 RFFT function hard faults but CFFT works fine.

[JFitz]

Using Rowley Crossworks and CMSIS DSP V5.6.0 library. Function  arm_cfft_f32 works but arm_rfft_fast_f32 hard faults.

  arm_cfft_f32 (&arm_cfft_sR_f32_len16, TestInput, 0, 1);
 
  arm_cfft_f32 (&arm_cfft_sR_f32_len16, TestInput, 1, 1);
 
  status = arm_rfft_fast_init_f32(&S, 32);
  arm_rfft_fast_f32(&S, TestInput, TestOutput, 0); //FAULTS !

The call to arm_cfft_f32 works as forward and inverse and the call to initialise the fast rfft works but the call to arm_rfft_fast_f32 hard faults.

Anyone know if the CMSIS DSP 5.6.0 has problems?

I'm using the Cortex M7 little endian + FPU version and have added the appropriate preprocessor definitions.

[Ozone]

It would be helpful if you provided information about the hardfault (type), and the code location.

Perhaps just a stack overflow. Wasn't CW quite stingy with the default stack size ?

[JFitz · Accepted solution]

Hi Ozone. It's true that Crossworks default stack is 256 bytes but the problem seems to have been the FPU.

It looks like the Crossworks default new project FPU settings for the STM32F767 are "soft" and "double precision".

These can be changed in the Project properties (i.e. not Solution properties) to :

ARM FP ABI Type: Hard

ARM FPU Type: FPv5-SP-D16

which tells the compiler to make code using the hardware floating point unit and in single precision (as the STM32F767 FPU supports both single and double precision).

With these settings the code runs OK.

As an aside, the cfft was running without forcing a fault but I noticed its results were "bleeding" outside the designated arrays ... which made me think of single and double float sizes.

[Ozone]

> It looks like the Crossworks default new project FPU settings for the STM32F767 are "soft" and "double precision".

"soft" means all floating point code is emulated, no FPU at all required.

Does "double precision" make all "float" to doubles ? No wonder it breaks the code.

> As an aside, the cfft was running without forcing a fault but I noticed its results were "bleeding" outside the designated arrays ... which made me think of single and double float sizes.

Which is no surprise, single precision has just 24 bits mantissa. The accumulative error breaks quite a lot of algorithms assuming doubles.

With a single-precision FPU, you have to choose between either real-time speed of accuracy.