debug variable and expressions windows are empty

Victor McBride said:

1. Variables must be type "volatile".

          eg not: "unsigned char x = 0x01;" , it should be: "volatile unsigned char x = 0x01;

For source level debugging one thing to be aware of is that the default optimization level of zero can still perform register optimizations, which means local variables held in registers may not be correctly displayed in the debugger. Setting the CCS Project Properties -> Build -> MSP430 compiler -> Optimization -> Optimization level to off prevents variables being held in registers and means the debugger can always show the correct values (at the expense that the code may run more slowly).

Chester Gillon said:

That is not entirely true. In your example code the variables x and y weren't used so the compiler / linker could validly "optimize" the program and remove them. In this case adding the volatile qualifier prevents the otherwise unused variables being optimized away.

Furthermore, even volatile variables can be optimized away if they are local variables and their reference is never passed to anyone outside the current function.In this case, the compiler is free to put them into a register or on the stack,and the volatile keyword is void. If you pass a reference of them to a funciton you call, then the compiler is forced to allocate stack space for them. The volatile keyword then will cause the compiler to do no optimizing (especially for the order in which values are read from or written to them) - at lease from the moment their reference was given away (but most compilers won't be smart enough to make this difference and stop optimizing them globally)

In theory, the compiler can pass information to the debugger when a value is in a register and when in memory location. But the problem with optimized variables is not that the variable is buffered in a register, but that a write to the register doesn't necessarily appear where the sourcecode makes it seem. E.g. an assignment that is done inside a loop may be moved out of the loop if it is redundant. It may be done before or after the loop. Or not at all, if the variable is writtne only once and then read - the compiler can turn it into a constant whereever used, saving the storage space and making the instructions smaller and faster.

Nevertheless, for first debugging, not using compiler optimization is a good thing. later, it must of course be checked whether hte code still runs as expected when the optimization is turned on. Especially the code execution time will most likely change a bit, which may negatively affect the (especially whe there are still race conditions in the code flow)

Hi all,

I have a similar problem. I use MSP 430FR5969 and CCS5. This is my simple code:

#include <msp430fr5969.h>

int main(void) {

volatile int a=0;

    WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer

while(1)

{

a++;

__no_operation();

}

return 0;

}

I have turned off optimizer as posted above, but when I read 'a' in Variables table during debug I got alway a=16383.

I've tried also to declare a as global variable before main() but it doesn't work. Any idea? Thank you!

Fabio Marinosci said:

I've tried also to declare a as global variable before main() but it doesn't work.

If it is a global variable, then the volatile keyword will ensure that every access to it is carried out as written in the code.

So 'a++' will directly result in incrementing the memory location of th evariable. No register buffering, no delayed access. And the debugger should be able to fetch it.

If defined inside main, the compiler knows that nobody has a reference to a (as no code is generated to give this reference to anyone). and therefore the volatile keyword will be ignored.

It 'Doesn't work' because when I run debug in Expression table I get 'Error: execution state prevented access'. I just want to see at every step a=0,1,....and so on. 

Put a breakpoint or pause the execution. The debugger can't read the memory content in real time, it needs the CPU to be stopped.

I've put breakpoints of course but nothing changes. If I just declare, but I don't use, the global variable in main loop my program works. If I use the global variable to write into a register (i.e. UCB0I2CSA = SlaveAddress, where volatile unsigned char Slave Address=0x50 is a global variable) or in any other way in the program, debug does not start. Could it be a problem of configuration or options? It happens also with code examples of my series MSP430FR5969 anytime global variables are defined. Sorry if I insist but this problem has stopped my work. Thank you again.

Fabio Marinosci said:

It happens also with code examples of my series MSP430FR5969 anytime global variables are defined.

Jens-Michael Gross said:

If defined inside main, the compiler knows that nobody has a reference to a (as no code is generated to give this reference to anyone). and therefore the volatile keyword will be ignored.

Hi Chester, I tried to change MSP430.dll with your edited version, CCS5 asked me to make a firmware update and I did it. Unfortunately nothing changes. Could it be because I use MSP430FR5969?

Fabio Marinosci said:

Could it be because I use MSP430FR5969?

Note:

1) I don't have a MSP430FR5969 so haven't been able to test the fix on that device

(I did check the fix was still being applied for a MSP430FR5739)

2) This time I have built the fix into MSP430.dll v3.2.5.4, whereas the previous fix was on MSP430.dll v3.2.4.5. This means if you try the new version you will be prompted to perform another firmware update.1121.FR_RAM_corruption_fix.zip

Chester Gillon said:

haven't checked what the ANSI C standard says,

However, an auto-variable whose reference (if it has one - as it has none if it is a register variable) is not given away to anyone, cannot change or have side-effects. So it is totally safe for the compiler to ignore the volatile keyword in this case. Note that wasting time by an empty loop is nothing of concern for the compiler. THe C standard only talks about a consistent memory state at a funciton call or function exit. Which isn't changed by an empty loop, so the loop can be discarded. If the coder tried to fill the memory with void code or waste time without doing anything, that's not the compilers fault. There are other means to achieve these goals. And at the same time document that it is intentional.

Chester Gillon said:

with the TI MSP430 compiler the volatile keyword isn't ignored when used on a variable which is local to main (or any other function)

Jens-Michael Gross said:

with the TI MSP430 compiler the volatile keyword isn't ignored when used on a variable which is local to main (or any other function)

Even if it is so, it still might change without notice with the next compiler version. Like the whole code won't look the same if compiled with a new compiler version.[/quote]MSP430 Optimizing C/C++ Compiler v 4.1 User's Guide SLAU132G contains the following:

5.6.4 The volatile Keyword

The compiler eliminates redundant memory accesses whenever possible, using data flow analysis to figure out when it is legal. However, some memory accesses may be special in some way that the compiler cannot see, and in such cases you must use the volatile keyword to prevent the compiler from optimizing away something important. The compiler does not optimize out any accesses to variables declared volatile. The number and order of accesses of a volatile variable are exactly as they appear in the C/C++ code, no more and no less.

Therefore, hopefully the handling of the volatile keyword won't change without notices with the next compiler version.

Chester Gillon said:

Therefore, hopefully the handling of the volatile keyword won't change without notices with the next compiler version.

Declaring local variables as volatile simply makes no sense, even though the compiler might promise to obey the volatile keyword. (exception: if you pass the reference to the local variable to a function or a volatile global pointer, but then, no compiler would ignore the volatile keyword).

Jens-Michael Gross said:

Declaring local variables as volatile simply makes no sense, even though the compiler might promise to obey the volatile keyword.

[Which is what this thread was about]

Chester Gillon said:

the only times I resort to declaring local variables as volatile is to inspect some intermediate result in the debugger when investigating a problem, when otherwise the compiler optimisation would render the variable not viewable to the debugger.

Chester, thank you.  Your patched MSP430.dll v3.2.5.4 cures the FR_RAM corruption for CCS V5.3 and MSP430FR5739.

It was driving me nuts.

Is there a version of the patch for CCSV5.4 and MSP430FR5739?

CCS V5.4 installed MSP430.DLL v3.3.0.6.

Bill Norton said:

Is there a version of the patch for CCSV5.4 and MSP430FR5739?

CCS V5.4 installed MSP430.DLL v3.3.0.6.

However, just noticed that two weeks ago the source code was released for v3.3.1.3 in SLAC460f, and on a quick look the FRAM files in which I made my previous modification been modified (to allow for new FRAM devices?). Will compile v3.3.1.3 from source and see if the bug is still present.

Chester Gillon said:

Will compile v3.3.1.3 from source and see if the bug is still present.

Edit: While there has been no update for CCS yet, Download DLL Developers Package v3.3.1.3 Released 06/28/2013 contains a pre-compiled MSL430.dll v3.3.1.3 (but only for Windows)

Thanks Chester!  Your patched DLL's worked fine under CCS v5.4 and the corruption no longer occurs.