• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 485 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Gaps In RAM 430F2619

Rkensparc
Prodigy 130 points


Because I know I'll be asked:

Micro: MSP430F2619

CCS version: 5.3.0.00090 - using TI's compiler

I'm working on an application that uses a lot of the 4K of RAM in 2619.  I've got it running, but I've been watching my RAM usage quite closely and discovered something in the MAP file that I don't understand.  When I scroll down through the MAP file I come to a section titled: GLOBAL SYMBOLS: SORTED BY Symbol Address.  Scrolling down to address 0x01100 my global variables are listed, with their respective addresses.  Most of them use exactly the amount of memory they need.  For example an unsigned int will take up 2 bytes, a long 4 bytes.  I've got a couple of arrays and they use exactly the amount of space I allocated in my program.  However, there are a few variables that have to have gaps in RAM between their address and the next variable.  Which would lead me to believe I have memory that is being wasted.

For example at address 0x1884 I have an unsigned int variable named "rawVcc"  this should only take up two bytes of RAM, the next variable is an unsigned char named "Sector" but it's mapped to address 0x188E - (10 bytes down). This means there are 8 bytes of unused RAM between rawVcc and Sector.  There's a few other variables  are doing the same thing- each having gaps between 8 to 12 bytes.   I have confirmed that these variables are declared as char, int, or long, etc. and not arrays.

Currently this isn't causing me problems, but before I'm done with this application, I'm going to be need more RAM and the 20 to 30 bytes being wasted might mean the difference between my code running and not running.

So.... Why is the compiler/linker leaving gaps in my RAM?  Is there anyway to force the compiler/linker to not leave these gaps? 

Thanks

  • 0
    Expert 2870 points

    What is with your _LOCAL_ symbols?  Any variables defined locally (i.e. static)?

    My way to determine current flash/RAM usage is done with this one liner:

    ofd430.exe <file>.out | $(PERL) -ne '$$b{$$1}+=hex($$2) if /\.(text\.1|text\.2|text_isr|data|bss|cinit|const|stack|sConst)\s+0x\S+ 0x\S+\s+0x(\S+)/; END { printf("%16d bytes in ROM\n%16d bytes in RAM\n",$$b{"text.1"}+$$b{"text.2"}+$$b{"text_isr"}+$$b{data}+$$b{cinit}+$$b{const}+$$b{sConst}+0x40,$$b{data}+$$b{bss}+$$b{stack}); }'

    Perhaps this could help you.

    Hardy

  • 0
    Guru 227245 points

    Hardy is right. Local static variables do not appear in the map file but also take space in the global ram space. Same for global static variables (explicitely static variables declared outisde a function).
    Also, it may be that arrays only appear as one element only in the map file and the rest of the array appears as gap. This is, however, linker specific. As teh whole map file generation is.

    And finally, there's the problem of padding. It appears if one compilation unit (obj file) contains variables with an odd size. The next units variables are then aligned at a word border with a paddign byte between. Or if you have structs with an odd size but contains word-sized members, then the struct itself is padded to have an even size.

    In some cases, the linker is smart enough, in other cases there's nothing the linker can do. And the rest is a gray space.

  • 0
    Prodigy 130 points

    Thanks both of you.- I think it's the global static variables.  I inherited this code, and noticed the previous programmer had few static variables outside of functions. I'll go back and confirm this is what's happening.

    Jens-Michael - I checked that they weren't arrays before posting, and confirmed that arrays have the correct amount a space allocated.

    Thanks

**Attention** This is a public forum