Is arm_rfft_q31 thread-safe and interrupt-safe?

[escherstair]

I did some tests with arm_rfft_q31.

If I call it in the main() everything works fine.

But if I call it in a more complex application, froma thread created with osThreadCreate() I see very strange behavior. Sometimes a hard fault is generated, sometimes an OS_ERROR_STACK_OVF condition (but svcThreadGetId() returns 0; moreover when I call it from main() I see that it doesn't use a lot of stack). This is the reason why I wonder if arm_rfft_q31 can be safely used in an application with threads and interrupts.

Other functions (arm_cmplx_mag_q31, arm_mult_q31, arm_var_q31, arm_sqrt_q31) can be safely called from a thread.

[JonatanAntoni]

Hi @escherstair,

That sounds strange, indeed. There should be not much difference whether you call the function in a single main or from a thread context as long as the stacks provided are sufficient.

Does your controller you are using provides an MPU? You might try to restrict memory access to valid areas prior running the FFT calculation. I guess this would help figuring out at which point in time the malicious memory access happens. Both the hardfault and the overflow condition are typically issued with a certain delay.

Another idea to figure out what exactly is going wrong would be using a trace.

I think we could enhance the CMSIS-DSP documentation stating the stack requirements of each of the functions. Thank you very much for reporting your experience on this level of detail. Its very helpful.

[escherstair]

I'm using Cortex-M4 of Vybrid VF61 and I need to search if it provides an MPU. This kind of debug requires some time (and some knowledge). I let you know when I get news.

[escherstair]

I can share the trace which shows the path to OS_ERROR_STACK_OVF. In happens while executing SVC_Handler Should I post it here? Are you interested in snapshot of other variables?

Moreover, when I try to open "OS Data" tab I see unexpected error messages, for example

[JonatanAntoni]

Hi @escherstair,

great analysis, thank you. May I ask you to share the example you created to reproduce the issue, please? I can forward this to our engineering team.

Cheers, Jonatan

[escherstair]

Hi @JonatanAntoni I can send you privately but I'm not allowed to share the whole project on this public repository. So I'm going to send you an email with the project attached.

Is this ok for you?

[JonatanAntoni]

Sure, you can send it by mail. But it sounds you have a complex example. Are you able to reproduce the problem with a minimal example?

Cheers, Jonatan

[escherstair]

I did my best removing a lot of code and I'm going to send you a simplified example. But some peripherals, threads and signals are involved.

[JonatanAntoni]

Great. Should be fine. Thanks.

[escherstair]

Just sent

[escherstair]

I'm going to check deeply, but probably this issue is related to issue #219 if the buffers are too short.

[JonatanAntoni]

Thank you very much for your detailed feedback. We will definitively work through this issues.

Please be patient and do not expect quick fixes. This is due to being conservative with changes, having only very restricted development capacities and the current vacation period.

[christophe0606]

Since it is a very old issue and I have not seen new report about it, I suggest to close it and replace it with a different issue.

I think the problem with rfft in general is that the output buffer is bigger than what people may intuitively think and it is not really documented.

[escherstair]

@christophe0606 I agree; the issue was produced by a wrong/poor documentation (and or implementation) of rfft (see #219 ) I ask you to review it and improve and/or fix this as soon as possible. I hope that you can work hard on the whole DSP library since it needs a lot of effort (since years).

[christophe0606]

https://github.com/ARM-software/CMSIS_5/issues/810 was created to track documentation issues with rfft.