2012-08-07 10:42 AM
Hello
I dont know why, but when I use FFT code, STM32F103RBT6 just stop running in totally different part of code - mostly in parts of STD library where asserts are defined. So I think it can corrupt memory or something in weird way. It can work for hours, but when I create some input to other parts of the software it stop working as I described.For example - I reading data from sensor with I2C and running FFT every loop. In this loop I can do some additional inputs as PWM. When I dont change PWM signal it just work, but after few minutes of input it ends in Assert of I2C.But when I dont use FFT, there is no problem with hangs.Different implementation of the FFT works fine too, but that one which meets my requirements dont. This thing happened for me with very simple Kalman filter too (sw float).Sources are in C. I use -0s, -thumb optimization, Summon GCC toolchain.It seems like a compiler problem, I dont trust GCC very much since I found more bugs now.I dont use any memory operations, all stuff is done by compiler.Code of the FFT and Kalman is attached - both caused me a problems after 1 - 100 minutes. Do you know good implementation of a FFT with inverse FFT for 16bit/32bit integers? Radix 4 implementation by Ivan Mellen is not good, since it divide output by N and I need all 16bit range. Important thing is, that after this hang main loop stop working, but interrupts from system timer, pwm, serial are working without any problem.Thank you very much for any hints. #stm32-fft-hang2012-08-07 12:01 PM
q: are you using a RTOS?
guesses: stack overflow: not likely when the interrupts keep running but check. race condition: easy to check, insert a variable delay in one of the routines that work and see code 'bump': in this processor? I do not think so data 'bump': possibly GCC can't handle structs/arrays crossing a 64k barrier, see if one moves there code or data overflow: do not know GCC in Keil it would be ''check the .map file'' Erik2012-08-07 02:33 PM
I do not use RTOS.
It seems like a race condition, because with different delays it happen frequently or sporadicaly.Thanks very much, I'll check all situations.2012-08-07 02:47 PM
Sounds like an ideal case for firing up a trace module.
2012-08-08 08:43 AM
I do not use RTOS.
It seems like a race condition, because with different delays it happen frequently or sporadicaly.
no RTOS and a race typically is due to a) an interrupt being missed (happens twice before service) b) interrupt interdependency c) code reading a value written by an ISR twice and the result is ''supposed to'' be the same and the ISR executes again between the two reads my guess is that it, in your case, is c) Erik