Local variable in global array space

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi
Studio 6 with latest GCC etc.
I declared an array at the top of a module and then in main in that same module declared a local variable. I noticed that when I used memset to clear the array my local was being deleted as well. Using the debugger I can see what the problem is, the compiler / linker has placed the local inside my global array.
Global defined as:
char PktBuf[200];
Local defined as:
uint8_t RetryCount;
Debugger shows:
+PktBuf {char[200]{data}@0x2ec1} char[200]{data}@0x2ec1
RetryCount 0x66 uint8_t{data}@0x2f67 ([R28]+9)

As can be seen the loacal is at address 0x2f67, which is inside the 200 byte array which is from 0x2ec1 to 0x2f88.
I have the compiler / linker set to no optimising and debug mode. Any suggestions as to what could cause this will be great. Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much RAM do you have and what is the total size of your data ?

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the hint from Sid is that you have overflowed your data space and that the local (on the stack) has collided with the heap/globals.

a 200 byte array with an avr is not at all impossible but that can be a big chunk out of soem of the smaller ram spaces.

at the end of the build you will get a message that explains your ram/flash/eeprom usage.

regards
Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using an Xmega with 4K ram. Everything is declared statically. That been said I must admit it has been a while since I looked at how much ram is left so this might be the cause. I will investigate the stack overflow possibility. Currently the compiler reports:
Data Memory Usage : 3979 bytes 97.1 % Full
This figure includes the 200 byte array.

Thanks for the suggestion

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With 117 bytes of RAM left after static data, it is not a possibility that you will get a stack overflow, it is pretty much guaranteed.

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok checked the stack and you guys were spot on :oops: I have been working on this project for a while and whenever I looked at the ram usage it showed plenty of ram remaining. I think because of that I just stopped looking at it :?
Thanks once again for the speedy replies

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Data Memory Usage : 3979 bytes 97.1 % Full

As a rough rule of thumb if this figure is ever more than 75% you are probably in for trouble. It does depend on how you split your usage of global/static and automatics but on the whole 75:25 is about right.

If you are using so much RAM you may want to look at whether there's anything "const" that could benefit from being in PROGMEM (and not eating RAM). Things like text strings, font and fixed graphic definitions etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using PROGMEM already thanks, although do still have many #defines. I have managed to get it down to 75%. The main culprits are the 3 independed serial port buffers. I have reduced their sizes.
I think I am going to have to re-look at some of the memory use in the system because I still need to add code for an SD card which I am sure will use up quite a bit of memory :roll:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

do still have many #defines.

That's nothing to do with the C compiler and cannot pssibly account for flash or RAM usage.
Quote:

I think I am going to have to re-look at some of the memory use in the system because I still need to add code for an SD card which I am sure will use up quite a bit of memory

Use the Petit version of FatFs instead of the full thing. It only needs a handful of byes of RAM. The downside, of course, is performance.