Forums

Global Variables Being Overwritten

Started by jgurtner May 30, 2006
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

"jgurtner" <jgurtner@abraxis.com> wrote in message 
news:1148964547.983744.326300@j33g2000cwa.googlegroups.com...
> 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.
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 http://www.fivetrees.com
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

"jgurtner" <jgurtner@abraxis.com> wrote in message 
news:1149033509.463217.49670@i40g2000cwc.googlegroups.com...
> 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!
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 http://www.fivetrees.com
jgurtner wrote:

> 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 >
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