• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 1342 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 local vs global 32 bit variable

seb
Genius 4170 points


Hello everyone,

I just came up with some strange behaviour of my MSP430 or rather the CCS.

GLOBAEL or EXTERN:

unsigned long ulong_zahler = 0;

extern unsigned long ulong_ergl;

bla_test ( void ) {

LOCAL:

unsigned long Temp_longint = 0;
unsigned long ulong_test = 0;
unsigned long ulong_temp=0;

for(i=U_MIN;i<U_MAX;i++)      
                    {
                        Temp_longint = Temp_longint + (unsigned long)Result[i];
                        ulong_ergl = ulong_ergl + (unsigned long)Result[i];
                        ulong_test = ulong_test + (unsigned long)Result[i];
                        ulong_zahler = ulong_zahler + (unsigned long)Result[i];
                        ulong_temp = ulong_temp + (unsigned long)Result[i];
                    }

so i only have 32 bit long variables in this cases.

First the really strange thing:

all extern or global variables DO count to 32 bit, so they wont roll over when hitting 2^16=65536.

the local 32 long variables test and temp_longint behave just like 16 bit variables.

Has anyone an explanatio for this, or has experienced something similar???

Or am i yet again missnig some C fundamelntals i just didnt or couldtn know???

Another thig to wonder about is the fact that in my debugging mode at first i couldnt reach some of the local variables, now , 1 or 2 hours simply passed without programming, i can see all variables in debugging except one local.

Which directly brings me to another question, wheather the MSP430 UIF FET Debugger deletes all code when uploading a new one.

Thanks for reading.

Seb

  • 0
    Genius 4925 points

    Hmm that's confusing - can you provide a full minimal sample (shortest possible code which fully recreates your problem but is compilable without modifications), so it can easily be tested?

    Just a blind shot (I don't think that will make a difference, but then I'm not 100% firm in C internals just yet):

    Temp_longint = Temp_longint + (unsigned long)(Result[i]);

    Maybe - I'm not sure on which comes first, the cast and then the array or the other way round?

    Edit: Hmm, on second thought - why would it work for the globally defined longs then - so scrap that.

  • 0
    Guru 227245 points

    seb said:
    the local 32 long variables test and temp_longint behave just like 16 bit variables.

    Local variables are probably never allocated on teh stack. If the code allows it, they are just held in a register (or a register pair).

    It is possible that the debugger has a bug, showing only the register content of the lower 16 bit register of such a register pair in the view. It is possible that the code runs perfectly, just the debugger is telling you something wrong.

    To be sure, you should take a look at the assembly code generated. (assember view).

    Actually, incrementing a 32 bit variable is a 16 bit increment with a following carry addition to the upper 16 bit. in case of a register pair, the debugger might just pick the result at the wrong moment.

    To check this, try assigning the temporary variabel to a global volatile one and then check its content. Mos tlikely the seemingly truncated upepr 16 bit mysteriously did reappear. :)

  • 0 in reply to Jens-Michael Gross
    Genius 4170 points

    Hmm i was afraid something like that could be the case, this always seems like voodoo to me.

    I tried to assign my debug variable to another global one, thought it was the same 16-bit result.

    I am not familiar with assembler. I mean i know what it is and i can read it, but i am missing a lot of commands, so for me it is the last possible step to look inside the disassambly, as i need a lot of time understanding it.

    For now im heading home, see You all tomorrow for a nother exciting day with problems you simply wouldnt have when there were no electricity.

    Cheers.

  • 0 in reply to seb
    Guru 227245 points

    seb said:
    n i know what it is and i can read it, but i am missing a lot of commands

    The machine-specific instruction (mnemonics) are in teh users guide.

    THe only thing that's missing (and where I have problems myself) are the compiler(actually the assembler)-specific pseudo-opcodes, as they differ on different IDEs even for the very same target CPU.

    But for analyzing the code flow, all you need are the CPU instructions found in the users guide. Also, it's easier to understand a disassembly output than writing code yourself.
    And as a last resort, you can post the assemly output of the suspicious part here in the forum. :)

**Attention** This is a public forum