Global Variables changed in local context

cancel
Showing results for 
Search instead for 
Did you mean: 

Global Variables changed in local context

Jump to solution
1,381 Views
rdazcal
Contributor III

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.

Labels (1)
Tags (1)
0 Kudos
1 Solution
103 Views
bigmac
Specialist III

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

 

View solution in original post

0 Kudos
6 Replies
103 Views
Lundin
Senior Contributor IV

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

 

:smileyhappy:

0 Kudos
103 Views
rdazcal
Contributor III

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?

0 Kudos
104 Views
bigmac
Specialist III

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

 

View solution in original post

0 Kudos
103 Views
rdazcal
Contributor III

Thank you bigmac, it worked beautifully.

 

Thank you all for the help!

0 Kudos
103 Views
rdazcal
Contributor III

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

0 Kudos
103 Views
J2MEJediMaster
Specialist I

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

0 Kudos