1. Home
  2. Embedded Programming
  3. Global Variables Being Overwritten

Global Variables Being Overwritten

Is there a better way of doing this:

LCDWrite("This is a test");

void LCDWrite(char *buffer) { while(*buffer) /* loop until buffer is empty */ { PortC = *buffer; /* write data to LCD data port */ LCDEnable(); /* clock the LCD to accept data */ buffer++; /* increment the pointer to the next character */ } }

This works fine but it seems that if I use this function a too many times it starts to overwrite some of my global variables I have declared in "main" for an interrupt routine I am using.

The above was written in C with Code Warrior for use on an 8 bit Freescale 68HC08 microcontroller.

Any help would be greatly appreciated!

JimG

Reply to
jgurtner
Loading thread data ...

It should be fine - unless there's something in LCDEnable() that's doing it. The code you're showing has precisely one variable that gets written to (char *buffer), and that's an automatic variable. I'm also assuming that the definition of "PortC" has no side-effects.

Some suggestions: - Check your stack placement. Make sure it's not colliding with data space. - Look for instances of incrementing write pointers (the above is an incrementing read pointer). Be sure you're ending where you think you are. - If you have a debugger, watch the variables that are getting hit to narrow down what's clobbering them.

In other circumstances, I'd also say "avoid global variables", but a bug like the one you describe is a bug - it'd still break something.

HTH,

Steve

formatting link

Reply to
Steve at fivetrees

BINGO! Thanks a million!

you wrote: "Some suggestions: - Check your stack placement. Make sure it's not colliding with data space. "

My compiler automatically placed the stack right in the middle of my data. The stack was set to 80 bytes. I reset the size to 255 bytes and the compiler moved it out in the open away from my other data. (Not an major issue, but still not sure how to specify the exact placement of the stack with my compiler).

Now the stack has plenty of room to expand!

Thanks again! JimG

Reply to
jgurtner

Excellent - glad to have been of service.

FWIW: I sometimes implement a "stack trap" - meaning that I assign a (small) no-man's-land between stack and data, write some magic numbers there at startup, and periodically check that the values have not been corrupted. If they have been, I shout and wave... and then usually reset, since there's not much point in continuing with corrupted data and/or stack... This is useful in development for obvious reasons, but also in production, where the idea isn't so much to catch bugs (there shouldn't be any!) but to catch a runaway CPU... (I also always use a hardware watchdog too, but that's another story...)

Steve

formatting link

Reply to
Steve at fivetrees

You want to look for a thing called a 'linker command file'. If you're lucky the extension will be documented. If you're _really_ lucky about

30% of the syntax will be documented. After that you're on your own. Usually these have a way of locating segments -- you need to figure out how to tell it not to let data and stack collide. 
--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.