evaluating global variables in debug mode [6.0.1882]

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

here the situation: I have successfully compiled my C code, then established a debug connection to my controller board (ATmega162 using AvrDragon). Running. Fine. Now I can step through the program and watch the variables (according to the structure definitions) by moving the MousePointer over the variables, opening the "Locals" view or inserting the variabl names into a "Watch" view. This works fine for LOCAL variables only.

As soon as I try to evaluate a GLOBAL variable, which is definitely visible within the current debug scope, I get the memory location tooltip but also the tooltip "Children could not be evaluated".

Does somebody know, how I should change the default configuration of AtmelStudio or modify my C code to be able to evaluate global variables?

Thanks.
Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make the thing you want to watch temporarily "volatile" or (God forbid) build -O0.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Make the thing you want to watch temporarily "volatile" or (God forbid) build -O0.

Thanks for the reply. I guess, it will not be as easy as you though...

Building with "-O0" as long as I am in this early stage of development is what I do generally. Why not? And declaring the global variable as "volatile" did not make the children visible.

Any other suggestions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never use -O0.
The default for AS6 'Debug' is -O1.
This should be a happy compromise for most people.

You should be able to see all your Global variables in Watch windows. Please post an example 'program' that exhibits any strange behaviour.

Note that sometimes aggressive optimisers will simply remove a redundant variable.

If you are determined to 'see' a redundant variable, simply assign a volatile local variable to it. This has the advantage of making it visible in your Local window.

Note that some things may be 'handy' for debugging, but affect the efficiency of the code.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

here is some example code

------------------------------------------------
APP_private.h
------------------------------------------------

...

typedef struct s_Config
{

	unsigned char	ucNumOfDevices;
	...
	
} t_Config;

...




------------------------------------------------
APP.c
------------------------------------------------

...

#include "APP_private.h"

volatile t_Config sConfig; // type declared in APP_private.h

unsigned char SYSTEM( unsigned char ucHandle )
{

	// check validity
	if( ucHandle > sConfig.ucNumOfDevices )
	{
		return ERROR_DEF;
	}

}

...




------------------------------------------------
MAIN.c
------------------------------------------------

...

#include "APP.h" // prototype of SYSTEM() function

void main( void )
{

	SYSTEM( 2 );

}

...

In debugging mode, I step into the SYSTEM() function and there (in APP.c) I try to evaluate sConfig by holding the mouse pointer above the variable name. Pressing on the first "+" the next message says "...evaluation not possible". Is there any structural detail which causes the evaluation of children of sConfig not to be possible?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recreated what you describe (after removing all the "..." that made it more work than it needed to be) and got...

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you saying that you can't see sConfig ?

It should exist in global .bss.

Note that if you never assign any data to sConfig, all the fields will be zero.

If your compilation units really are separate .C files, the optimiser should not make assumptions about the contents of a volatile variable.

Ideally, you post a complete minimal project. Then someone may try to reproduce your problem.

Your code looks as if it should all be visible to the debugger. But I have not hand-built your 'snippets'.

As I suggested earlier, you could simply assign a local static. e.g.

unsigned char SYSTEM( unsigned char ucHandle )
{
   static int localcopy = sConfig.ucNumOfDevices;
   // check validity
   if( ucHandle > sConfig.ucNumOfDevices )
   {
      return ERROR_DEF;
   }

} 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I recreated what you describe (after removing all the "..." that made it more work than it needed to be) and got...

I get this:

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Your code looks as if it should all be visible to the debugger. But I have not hand-built your 'snippets'.

...you could simply assign a local static. e.g.

unsigned char SYSTEM( unsigned char ucHandle )
{
   static int localcopy = sConfig.ucNumOfDevices;
   // check validity
   if( ucHandle > sConfig.ucNumOfDevices )
   {
      return ERROR_DEF;
   }
} 


I see the global variable within the code and even the tooltips work when editing the source code in that scope of e.g. the SYSTEM() function. sConfig shows up in the ".bss GLOBAL" section of the MAP file.

When I do an example like this within the SYSTEM() function

t_Config localcopy;
localcopy = sConfig;

even the children of "localcopy" will not be evaluated.

Could it be that "#define" within the structure definition of t_Config confuses the evaluability of children? Or maybe the structure is longer than the IDE will be able to display correctly? Here is the complete structure definition:

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Attached is the project where it works for me in AS6 SP2 (ie build 1996). Can you load this and see if it works for you or not?

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Attached is the project where it works for me in AS6 SP2 (ie build 1996). Can you load this and see if it works for you or not?

It does not work for me either. Look here:

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then we must have different versions of AS6. I supplied it "clean" so you must have rebuilt it which confirms we both used the same build options I guess.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Then we must have different versions of AS6. I supplied it "clean" so you must have rebuilt it which confirms we both used the same build options I guess.

I copied your small project into a folder and added an "existing project". Then pressed "Start debugging and break" from the tool bar. Don't know how to otherwise "load" a project into the simulator (don't have an ATmega8).

Could I try something else?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried Cliff's project. It worked fine for me.
I also tried the localcopy trick:

#include "APP_private.h"

volatile t_Config sConfig; // type declared in APP_private.h

unsigned char SYSTEM( unsigned char ucHandle )
{
    static t_Config local;
	local = sConfig;
	// check validity
	if( ucHandle > sConfig.ucNumOfDevices )
	{
		return 1;
	}
    return 0;
}

I could examine the local structure too!

I just copied Cliff's folder to disk.
Then 'opened' the AS6 project.

I found that there were some extraneous 'Watch' variables called 'Keys'. Possibly leftover from Cliff?

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I found that there were some extraneous 'Watch' variables called 'Keys'. Possibly leftover from Cliff?

Oh very likely. I have a couple of projects (test.atsln and ledblink.atsln, oh and testcpp.atsln) that I just use to test everything mentioned here on Freaks - simply deleting the existing code and then adding in the new code/files each time. So there could well be remnants from a previous experiment.

Again I change the build target around as appropriate so I guess the last time someone mentioned which AVR they were using was a thread that mentioned "mega8" so that's why this project was set to mega8. That's completely arbitrary, it could be set to any model and I bet the result would be the same.

Almost always I don't bother with actual AVR hardware (while I probably have some mega8s somewhere I can't think why anyone would ever use mega8) so, yes, I just checked this in the mega8 simulator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

any further suggestions for me to solve the problem of not being able to evaluate some of my variables? Maybe some common places to look within the AS6 configurations?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like I say if we use the same project (mine) and it works the same for David and I but not for you then it suggests your AS6 must be different to ours. I deliberately mentioned "build 1996" above. Can you confirm that your version is 1996 and that your avr-gcc is 3.4.1.95 ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff's minimal project shows that everything works ok for that minimal example.

If you really are struggling with this, zip up your complete buildable project. Either post here or send privately.

If the code is commercially sensitive, you will need to create an equivalent buildable project. Let's face it, Cliff went out of his way to produce something reproducible.

I am sure that we can help.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again,

and a happy new year.

Updating my AtmelStudio to version 6.0.1996 SP2 solved the problem. I now can view the members of global variables as expected.

Thanks to all.
Peter