• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 79 subscribers
  • Views 1113 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.

MSP430 memory usage, overwriting adresses Problem

seb
Genius 4170 points

Other Parts Discussed in Thread: MSP430F5437A

Hello,

we were just experiencing some really stange problem, it is kind of half half SW HW related, since the code runs on a MSP430F5437A:

This uC has about 16 kBytey RAM which should be plenty, we set the Stack really high to 560 ( i think this is decimal and Bytes) for not running into stack overflow problems.

Now I can see in my mapfile that we have about 0x1000 Bytes free, which is 4 kByte of free RAM for my global or volatile or any variable that i want to use.

Now comes the really strange problem, when combining different variables in one function, there are some global ones, and some local ones. For example we did use one global array[512], which starts at RAM address 0x4AC8 ( I can see that variable in the RAM memory view, so I know it is really there, and I know it is right,or at least filles with my values)

So global unsigned int array[512] starts at: 0x4AC8

                                                              ends at: 0x4CC8

Now since it is global, I thought the compiler CCS 4.3.x would reserve enough memory, since there still is plenty of unused RAM, and locate that variable where it wont be overwritten. In fact I know now, that one local variable will overwrite my global one at around the middle ( address 0x4BC8) and I simply dont know enough C to say why the hell is it doing so.

My beginners point of view was, global variables will be in the memory of my uC and will not be overlapped with other variables, local variables will only allocate memory, when a function, in which they appear is calles, am I wrong?

Reality did proof me wrong once again :)

Now comes a funny part, we found a workaround: not use a global unsigned int array, but a even longer and volatile unsigned long array.

Can anyone answer why that works and the other way not, always keeping in mind that I have a lot of free space left ( ca. 4 kB)?

Thanks for reading,

best wishes,

Seb

  • 0
    Guru 227245 points

    seb said:
    we set the Stack really high to 560

    No.
    You cannot 'set the stack'.  The stack grows and shrinks as the program flow requires. The setting only ensures that after all global and static variables are placed, at least this much is still available (or else the linekr will throw an error).
    However, changing this value will not change a single bit in the generated binary.

    The 'Stack settign' will not prevent the stack from growing as large as the program flow requires. Adn the linekr does not know nor care for local funciton variables, as the reis no analysis of which function could be called by which other function, or maybe with recursions.

    So if indeed your global array is overwritten by local variables, then because the stack has grown so large that it reaches into the ram area for variables. Due to recursions, local variables, deep function nesting, ISRS (whcih need to save all used registers) or, or, or.

    seb said:
    My beginners point of view was, global variables will be in the memory of my uC and will not be overlapped with other variables, local variables will only allocate memory, when a function, in which they appear is calles, am I wrong?


    Yes and no.Yes, local variables (unless 'static') are only taking up memory when you call the function they belong to. And take this memory until the function exits (whether they are still used or not). So local variables inside main are always taking up memory, since main never exits. But are not counted in the memory map.

    And on recursive functions, each recursion adds a new load of local variables to the stack. And saved register, and...

    Not knowing your code, I cannot say anything final about the issue.

    seb said:
    Now comes a funny part, we found a workaround: not use a global unsigned int array, but a even longer and volatile unsigned long array.


    Maybe the problem has just moved where you don't see it anymore (and it bites you in the heinie when you least expect it).

**Attention** This is a public forum