Global Variables changed in local context

[rdazcal]

Greetings,

If this question doesn't belong in here, please let me know where I should have posted it, instead.

I was debugging a program I've made for the MC9S08LC60, and I noticed something that was very strange to me.

I noticed that when the program enters some functions, it saves the local variables in the same physical address where some global variables reside, thus changing them!

Does that make any sense to any of you?

is it possible the compiler knows (or thinks it know) in advance which global variables it may change without affecting the program's logic?

I thank you in advance.

[Lundin]

The 3 most common causes for such bugs are: stack overflow, stack overflow and stack overflow.

[rdazcal]

Lundin,

You were right on spot!

The SP is pointing to the same addresses as the Global variables, which means it overflowed...

is there a way in C to reserve more space for the stack, or I have to change "manually" the SP at the program initialization?

[bigmac · Accepted solution]

Hello,

The PRM file for the project determines how the linker allocates memory.  The default PRM file contains a STACKSIZE entry, typically 0x50 (80 decimal) bytes.  This occupies the RAM space immediately above the global variables.  This parameter should be increased to a suitable value.  Are you using floating point operations within your code?  This will massively increase the stack size requirement.

My personal preference for limited RAM devices, is to use an alternate STACKTOP entry so that the start of the stack can be placed at the maximum RAM address, so as to maximize the distance between the stack and the global variables.

Regards,

Mac

[rdazcal]

Thank you bigmac, it worked beautifully.

Thank you all for the help!

[rdazcal]

Thank you J2ME and Lundin!

I am analizing the code to see if the problems I'm having are caused by Stack Overflow or code optimization.

I'll post soon what I discover

[J2MEJediMaster]

Usually the optimizer can track whether varaibles change or are accessed, and it uses this information to remove redundant operations. For example, if a certain variable in a function does not change, it can be eliminated from the code for the lifetime of the function, or treated as a constant which can affect the instructions that generate accesses to it. This is a great oversimplification of what goes on, of course. It can be stated concisely that when the optimizations are on, the generated assembly code may not match the intent or locations of the source code. You will have to look carefully at an assembly listing to see if this is case.

---Tom