STM32 freezing

[zexx86]

Posted on October 03, 2011 at 23:06

Hello

I got implementation of the cosine function, it works correctly, but sometimes, randomly, it hangs processor.I dont know exact reason, it could be some memory corruption or just weird loop.Input for variable x is 360� = 720; 1� = 2. Output is from -10000 to 10000.Here it is 

http://pastebin.com/ggajpE76

I just calling it with some values (angle) obtained from sensor, but I dont know, why it randomly freezing, even when there are additional conditions (if). Somebody know, where could be a problem ?It seems it is not OK even when this function is compiled and I dont call it - it could be called when some other variable enable it during execution.Thanks #jtag---just-do-it #jtag---just-do-it

[Tesla DeLorean]

Posted on October 04, 2011 at 00:09

Perhaps you're just observing a side effect of heap/stack corruption. Or it otherwise gets stuck in an infinite loop somewhere.

Do you have a proper Hard Fault handler that could provide more details about when it ''freezes''? If you break-in with JTAG, where is the program stuck? Perhaps you should consider using const so that it might ROM the code as apposed to it eating RAM. const short cos_half[] = { .. };

[zexx86]

Posted on October 04, 2011 at 16:05

Thanks

I tried const but with same result as well as replacing while loops with modulo + one if. I dont have a JTAG, but HardFault_Handler is not probably called, I added there loop with serial output, but nothing comes out.I dont know where is a problem at all.

[Tesla DeLorean]

Posted on October 04, 2011 at 16:28

I dont have a JTAG, but HardFault_Handler is not probably called, I added there loop with serial output, but nothing comes out. I dont know where is a problem at all.

Well without the right tools you're going to spend man-days of effort chasing this down. Your options would seem to be to instrument your application code, and bisect the problem using the serial port. The code you posted doesn't seem to be the problem, unless the compiler fouled it up. So you're going to need to step back and look at more code, and the interaction this code has with other routines. If you think there are problems outputting serial data, or calling subroutines from fault routines, consider toggling a GPIO pin, or two, to indicate failure/function conditions.

[emalund]

Posted on October 04, 2011 at 22:06 I dont have a JTAG just curious, how do you then get the code into the processor? Erik

[Tesla DeLorean]

Posted on October 04, 2011 at 23:28

From previous posts, Tomas has this board :

http://tmp.www.lcsoft.net:8080/Hardware/Detail.aspx?id=d749d444-0927-4358-a229-c643d0e9c97d

just curious, how do you then get the code into the processor? I would imagine he uses the serial flash loader implemented in the system ROM. It's certainly the most simple and cost effective ways to factory program these parts.

[Andrew Neil]

Posted on October 04, 2011 at 23:29

''I dont have a JTAG''

Then Get One!!

It really is folly to mess about without one! You are deliberately crippling your efforts without it. If you're really stuck for cash, get a Discovery board:  they're only about $10 - and that includes the debug probe!

[zexx86]

Posted on October 06, 2011 at 18:56

Thanks

Actually, I found a source of the problem - just missing conversion between short and int. So solution was to add (int) in good places.I dont use so much mentioned development board, but my own - 

http://4d.zexos.org/media/new/1.jpg

There is just serial port.

[Andrew Neil]

Posted on October 06, 2011 at 22:11

''There is just serial port''

Again, it is pure folly to not provide access to JTAG! If you're stuck for space, SWD uses less pins.