variable not allocated + variables dont refresh

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

variable not allocated + variables dont refresh

1,647 Views
Nanouser
Contributor I

Hey Guys,

 

i am using a MC9S12x and corewarrior 5.9.0.

 

i got two questions:

 

first one is: ALL variables that are declared in a function (and not global) get greyed out while debugging "not allocated". I need to attach "volatile" before every single one. Example:

 

void myfunction(void){ int i = 0; for (i=0;i<10;i++) {          //here is some very very important code reading temperature from a sensor(IIC), to regulate a system, setting i/o ports for the heating etc.        }}

 what happens: i is greyed,"not allocated" the whole loop is skipped totally.  nothing happens. why the f*** is this happening? why do i need to write volatile before EVERY single variable?? this is annoying and make the code slow... another example:

 

main(){ int i = 3; int k = 0; if (i == 3) {  k = 5; }...}

 the if is totally ignored and not processed at all. i think "optimisation" is a bit over aggressiv isn´t it? i mean... skipping the whole code really makes the code run very very fast! :smileyvery-happy:

 

 

next problem: my programm runs smooth (i use volatile before every variable now). but in the debugger my variables aren´t updated although i set the mode to automatic, or periodic. they are only updated in the moment my programm is stopped or restarted (they refresh once at both times) i tried to use the manual refresh button. no function here too. if i set a watchpoint to the variable, the programm stops, as it should and the variable is updated. so i can garuantee my programm passes this point over and over (still reading the temperature via iic). how do i see my variable in realtime? this is really important to test my regulation system... cant click every second to restart the program and see my variables updated.

 

 

 

hope you guys can help me.

Labels (1)
0 Kudos
3 Replies

644 Views
kef
Specialist I

By default compiler does some optimizations, including one, which makes so variables allocated in CPU registers and not allocated in memory,  which makes debugger unable to show you this variable. In case you are unable to debug some code, try moving Debug Complexity smart slider to Low position. This should ease debugging. To restore compiler options later, it is the easiest to copy and save whole compiler command line string. Just restore old settings string.

 

It is OK for compiler to ignore whole loops, provided result of loop execution is the same with optimization and without it. Execution time is not taken into account. Volatile variable of course disables such optimizations. Don't use for loops for timing delays, it is bad practice. Better use free running timer counter for short delays and periodic interrupt incremented variable for long delays. Say you have some counter variable (or timer counter register) running

 

volatile int cntr; // incremented by interrupt

 

// delay function.

// ticks has to be  0 <= ticks <= INT_MAX (defined in limits.h)

void WaitTicks(int ticks)

{

   ticks += cntr;

   while( (signed int)(cntr - ticks) < 0 )

   {

   }

}

 

You can't see function scope nonstatic variables updated in run mode. This is because they are allocated on stack, and stack pointer changes back and forwards when running, so debugger can't show such variables reliably in run mode.

The same problem is guaranted with variables, allocated in paged memory. Since page register changes at run time, debugger is not allowed to change page at run time, you won't be able to see such variables updated at run time.

0 Kudos

644 Views
drummer
Contributor IV

I often use sprintf to view variables I know will be hidden from the debugger. I have to admit that the code optimization is amazing and I am suprised that all the code I have imported from an old 68000 platform fits so well. But code optimization is a double edged sword.

 

I use #define DEBUG_WHATEVER 1 follwed by #if DEBUG_WHATEVER to turn on and off the sprintf functions.

 

The old 68000 code was compiled using batch files in DOS mode and had plenty of debug defines due to the fact there wasnt a development system back in nine-teen dickity six.

 

So bottom line is "it may not be pretty but its a lot better then it used to be".

0 Kudos

644 Views
Nanouser
Contributor I

Hmm... can no one help me with this problem? Cant be the only one annoyed about this.

 

 

thanks in advance

0 Kudos