Fast Fourier Transform (KISSFFT) issue

Despite the 5-year old 6865 post about a similar issue with CMSIS FFT, I still wish to ask about debugging memory corruption issues when using an FFT library. I successfully used CMSIS to run a FFT (correlation) in QEMU for the TI Stellaris as shown with

void do_fft(void* param)
{char c[20];
 q31_t *in=param;
 arm_cfft_q31(&arm_cfft_sR_q31_len256, in, 0, 1); // FFT
 while(1) {vTaskDelay(301/portTICK_RATE_MS);}
}   

int main()
{// static uint32_t c1[2*N],c2[2*N],meas[2*N]; // N*4*2 bytes crashes
 static int32_t *c0,*c1,*c2,*meas; // N*4*2 bytes OK
 int k;

 c0=(int32_t*)malloc((2*N+1)*sizeof(int32_t));
 c1=(int32_t*)malloc((2*N+1)*sizeof(int32_t));
 c2=(int32_t*)malloc((2*N+1)*sizeof(int32_t));
 meas=(int32_t*)malloc((2*N+1)*sizeof(int32_t));

#define S 4096
 if (!(pdPASS == xTaskCreate( do_fft, (const char*) "fft1", STACK_BYTES(S), c1,  1,NULL ))) {uart_puts("1\0");goto hell;}
 if (!(pdPASS == xTaskCreate( do_fft, (const char*) "fft2", STACK_BYTES(S), c2,  3,NULL ))) {uart_puts("2\0");goto hell;}
 if (!(pdPASS == xTaskCreate( do_fft, (const char*) "fftm", STACK_BYTES(S), meas,2,NULL ))) {uart_puts("3\0");goto hell;}

However CMSIS uses ARM assembly language, preventing cross-platform portability amongst non-ARM architectures. I hence wish to replace CMSIS with KISSFFT. To avoid al FPU related issues, I compile KISSFFT as a Q31 fixed point library I link against. Baremetal examples works well as shown below

void do_fft(kiss_fft_cpx *in,kiss_fft_cpx *out,int direction)
{char c[20];
 kiss_fft_cfg cfg;
 uart_puts("fft\0");
/* solution 1
 if (direction==0) kfc_fft(N,in,out);
   else            kfc_ifft(N,in,out);
 kfc_cleanup();
*/

/* solution 2 */
 if ((cfg = kiss_fft_alloc(N, direction, NULL, NULL)) != NULL)
   {kiss_fft( cfg , in , out );
    kiss_fft_free(cfg);
   }
 else uart_puts("FFT out of memory\0");
 uart_putc(':');hex(in[N].r,c); uart_puts(c);uart_puts("\n\0");
}   

int main()
{kiss_fft_cpx *in,*out1,*out2,*outm;
 int k;
 char c[9];
 in =(kiss_fft_cpx*)malloc((N+1)*sizeof(kiss_fft_cpx));
 out1 =(kiss_fft_cpx*)malloc((N+1)*sizeof(kiss_fft_cpx));
 out2 =(kiss_fft_cpx*)malloc((N+1)*sizeof(kiss_fft_cpx));
 outm =(kiss_fft_cpx*)malloc((N+1)*sizeof(kiss_fft_cpx));

 for (k=0;k<N;k++) {in[k].r=(pattern1[k]<<30);in[k].i=0;}
 for (k=0;k<3;k++) 
    {hex(k,c);uart_puts(c);uart_putc(':');
     do_fft(in,out1,0); 
    }
 
 for (k=0;k<N;k++) {in[k].r=(pattern2[k]<<30);in[k].i=0;}
 for (k=0;k<3;k++) 
    {hex(k,c);uart_puts(c);uart_putc(':');
     do_fft(in,out2,0); 
    } 

However, calling the do_fft() function found in the baremetal example as a FreeRTOS task crashes at the third instance (the first two tasks complete properly). I have stack corruption detection active, am using heap_4.c from the CM4, and gdb tells me that after the second task completed the FFT and the third do_fft() is supposed to be launched, the CPU hangs in a blocking_handler(void) infinite loop which is the libopencm3 way of handling hard_fault_handler, mem_manage_handler, or bus_fault_handler.
I have no clue how to debug this as it sounds like a kernel task launching issue, happening whether the *in and *out buffers used for the FFT are created within the task or in the main() and passed as void*(pointer), whether I statically allocate in[N] and out[N] or whether I pvPortMalloc and vPortFree, even protecting the task with a mutex to make sure it is not preempted.
Any clue on how to debug this issue?
Thanks

replace the call to arm_cfft_q31 with a dummy and see if the problem persists. That tells you if you have an infrastructure issue or a problem inside the lib.

I presume this refers to stack overflow detection. Do you have configCHECK_FOR_STACK_OVERFLOW set to 2?

This may also help: Debugging and diagnosing hard faults on ARM Cortex-M CPUs

In tp_freertos/8_xcorr_fft at master · jmfriedt/tp_freertos · GitHub I have indeed removed the kiss_fft( cfg , in , out ); call and that allows completion of the execution of all three tasks. hence my confusion between FreeRTOS memory allocation/task spawning v.s KISSFFT memory handling.
Thanks

May be a dead end, but some users of libopencm3 encounter context corruption due to incorrect installation of the FreeRTOS interrupt vectors. Do you have a file called opencm3.c? Don’t use it. Instead, use 3 #define statements (in FreeRTOSConfig.h) to map the FreeRTOS handler names to the libopencm3 names in the vector table.

The #define statements use the libopencm3 names instead of the more traditional CMSIS names. Like this:

#define vPortSVCHandler     sv_call_handler
#define xPortPendSVHandler  pend_sv_handler
#define xPortSysTickHandler sys_tick_handler

@jmfriedt I just updated your profile to enable you to post links.

Thank you: indeed tp_freertos/freertos_opencm3.c at master · jmfriedt/tp_freertos · GitHub is providing in my development framework the functions you #define, although in a slightly different format.
Thanks

This is not correct. As @jefftenney mentioned, do not compile this file and add the define statements mentioned by Jeff in your FreeRTOSConfig.h file.

Have you serialized your memory manager via correct malloc_lock overrides?

For the record … KISSFFT is internally using floating point number calculation even when requesting fixed point FFT implementation. Even avoiding the dynamic memory allocation when providing as argument of kiss_fft_alloc a pointer to a statically allocated memory range and its size as the last two arguments (which I have never found being documented other than reading the source), the error I hit was related to

        for (i=0;i<nfft;++i) {
            const double pi=3.141592653589793238462643383279502884197169399375105820974944;
            double phase = -2*pi*i / nfft;
            if (st->inverse)
                phase *= -1;
            kf_cexp(st->twiddles+i, phase );

so although this exercise was the opportunity to be exposed to thread safety of dynamic memory allocation in Tasks, the issue ends up being with floating point calculation and its emulation in qemu. As stated in the various FAQs, nothing to do with FreeRTOS. Apologies for the noise, and thanks for the support.

Thanks for taking the time to report back.