• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 7251 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

IAR debugger says local in scope variables are "unavailable"

Dubs Mozz
Intellectual 330 points
Other Parts Discussed in Thread: MSP430F5659

Hello 

I am working along happily with my msp430f5659 on IAR 6.10 with a TI MSP430 USB- debug fet MSP-FET430UF and all seems fine, debugger working like a charm, I can see watch variables, I can hover my mouse over a var and it has an automatic popup that displays the value until I merge my code into a bigger build.  

Now debugger does not work.  Still works on my old simple build .I have compared all debugger settings and they are all  the same.   So it appears it is not the debugger, or even IAR, per se, since I can get the debugger to work on the pre-merged code.   I compared the micro processor initilization files, my working one and on this nonworking Debugger program, both looks pretty much the same .  Though the clock sources are different so some of the init setups are different I can't see why these would effect the debugger.  

does anyone know what would cause IAR to think an in- scope variable is 'unavailable" ? 

Thanks
 Dubs

  • 0
    TI__Guru**** 212667 points
    Hello Dubs,

    It seems to me like nothing is wrong with the debugger or IAR, this is more related to how you declare your variables inside of your code. Standalone, the code most likely used global (or static) variables that IAR could access at any time during the debugging process. Once part of a bigger build, however, the variables became local (or dynamic) and can only be properly viewed once inside the function for which the variables are being used. This is my best guess as to why IAR would declare a variable as being unavailable inside of a code build, you can try pausing the code inside of the function to which these variables are being used to confirm.

    Regards,
    Ryan
  • 0
    Guru 25210 points

    You are seeing the effect of register reuse by the compiler. If a variable is not used during the whole duration of a function, it can share the same register as another variable as long as the lifetime of the two variables do not overlap.

    My suspicion is that when your code is part of a bigger build, the compiler is more aggressive in its optimization.

    Example:

    void example(void)
{
    unsigned x,y;

    x=TA0CTL;
    x |= ID_3;
    TA0CTL = x;

    y=TA0CCTL1;
    y |= OUTMOD7;
    TA0CCTL1 = y;
}

    In this case, both x and y could share the same CPU register (for example, R10) since their usage does not overlap.

  • 0 in reply to Brian Boorman
    Guru 58965 points
    How about variables allocated in the stack? They are not always "available" too.
  • 0 in reply to old_cow_yellow
    Intellectual 330 points

    Thank you all for the suggestions the problem was the name of the variable i chose, "state".

    I changed it to mstate. problem solved.  next_state, problem solved. changed it back to 'state' problem reappeared.  

    So I dont know why, when I asked IAR to show me where "state' was defined it couldn't, yet if I tried to assign a variable to it I could not see on the compiler.

    So particularly if you're designing a state machine stay clear of the variable 'state"

  • 0 in reply to Dubs Mozz
    Guru 58965 points
    I suspect that your conclusion is not quite right. "state" is either in a register or inside the stack and not always "available".
    I would add "static" to the declaration of "state" to make it always "available".

**Attention** This is a public forum