Stack Pointer problem

[lpcware]

Content originally posted in LPCWare by ozgozkan on Thu Mar 25 07:13:13 MST 2010
Hi.
I have a problem with stack pointer. I call a function like the others. But turning back of this function, program counter sometimes goes different places.
When It intends to go back from function this message appears:
<No source available for "ReadCont()">

Thanks.

[lpcware]

Content originally posted in LPCWare by ozgozkan on Fri Mar 26 05:11:49 MST 2010
Hi,
Thanks your reply.
First of all, I'd like to talk about <No source available for "ReadCont()"> message. When I changed "Optimization Level" from -O0 to -O1, I was get rid of this message. Why? What happened ?

When I changed the option --gc-sections I didn't realize something different.

"it doesn't come back properly" means after calling the function or subroutine, PC went right address and started to execute instructions. When PC pointed "return" and tried to execute it, <No source available for "ReadCont()"> message appears and PC goes to somewhere where it shouldn't have been there. I figured out it accedentally. While I was trying to fix it by writing and erasing somethings I lost the point where PC returned. Now It seems working. To be honest, I'm a little bit worried about it. It could happen again. There is something about stack and heap.  Is there any way to initialize and control them in software?
Thanks again for your all help.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Thu Mar 25 14:42:02 MST 2010
I presume that you are debugging a build that was compiled -O0 ? One thing to check is whether your link step has the option --gc-sections on it. If so, try removing this option and rebuilding. Do you now see any difference in behaviour?

If this does not improve matters, can you please explain in a little bit more detail exactly what you are doing and what you mean by "it doesn't come back properly". I assume that you are trying to step the last statement in your subroutine, or you are "stepping out" from somewhere in the middle of the subroutine?

Regards,

CodeRedSupport

[lpcware]

Content originally posted in LPCWare by ozgozkan on Thu Mar 25 08:46:38 MST 2010
Thanks for your reply.

I see your points and I totally agree with you. But my point is that I call that function in main(). PC goes to just one function deep and it doesn't come back properly. Also, I call another functions in the function and they come back. I'm a little bit frustrated. Let me send my code;
//-----------------------------------------------------
int main (void) {
......
   command[0] = IRQStatus;
   command[1] = IRQMask;
   [COLOR=red]ReadCont(command, 2);            //this is the function it doesn't come back.[/COLOR]
}
//----------------------------------------------
[COLOR=red]void ReadCont(unsigned char *buf, int lenght)
[/COLOR]{
    GPIOSetValue( SSEL_PORT, SSEL, LOW );   /* Start SPI Mode    */
    *buf = (0x60 | *buf);       /* address, read, continous */
    *buf = (0x7f & *buf);      /* register address   */
    [COLOR=darkorange]SPISend(buf);           // Also I call a function in here but it works normally.[/COLOR]
    while(lenght > 0)
    {
         [COLOR=darkorange]SPIReceive(buf);  // It works [/COLOR]
         buf++;
         lenght--;
     }
     GPIOSetValue( SSEL_PORT, SSEL, HIGH );   [COLOR=#ff8c00]// It works [/COLOR]
     return;
}
//-------------------------------------------------------------------------

Have I explained my problem? It seems to me it isn't sensible :) I guess I didn't adjust something. I really need help.

Is it about the memory address of the function?
How can I manage SP and heap?

Thanks.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Thu Mar 25 07:43:53 MST 2010
This is most likely caused by stack corruption. There is no stack  checking on the Cortex-M families, so you have to be careful where you  place the stack, program data, and the heap (malloc space).

If you are using the standard linker scripts, stack is placed at the top  of RAM, program data is at the bottom on RAM, and the heap immediately  after that.

If you are using a lot of stack, it can grow into the heap or even the  program data space. If the stack has 'overflowed' into those spaces,  when you write to the heap/program data it can overwrite values on the  stack and thus corrupt it.

The stack is used for both your application AND any interrupts that may  be firing (including nested interrupt), so you need to ensure there is  enough space for the worst-case scenario.

Also, check that you are not allocating large amounts of data on the  stack (e.g. allocating a local array, as this will be placed on the  stack).

I see you are building for an LPC1114. This only has 8k of RAM, so you will not have a lot to play with.