AVR Studio - watch/examine PROGMEM vars

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

Hi,

I am able to use the Watch window in teh AVR Studio simulator to examine variables by name/structure/class attribute etc if they are in RAM. If I have data in Flash.... is there way to examine this as part of the structure it belongs to rather than by calculating the address and then decoding in the Memory Window?

 

For example... I declare the var aTaskDescriptor below.

 

The Watch window tells me its base Flash address and after that I am decoding by hand.

 

I keep thinking that there must be an easier way.

Any thoughts appreciated.

typedef struct
{
	unsigned int topOfStack;
	unsigned char stackSize;
	const taskptr task;
	const char * name;
	const bool lightWeight;
} typeTaskDescriptor;

const typeTaskDescriptor aTaskDescriptor	PROGMEM = {useful data}

 

regards
Greg

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

Surely the fields are all contained in the "useful data"

So you know exactly what you put in the struct.

 

Since PROGMEM is read-only the contents can't change.   (as far as the Simulator is concerned)

 

David.

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

Thanks, and you are absolutely correct.... but the data are a bit scattered.

I can look up the task address, and the top of stack in the map. The stacksize is a #define. The name is a string definition.

 

Or.... if there is a way to just read the struct with Studio showing values of the data in Flash.... it would be very nice. smiley

regards
Greg

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

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

Thanks for this Morten.

I went and checked and found that in fact the problem seemd to have gone away!

 

So what was happening? surprise

 

In fact the problem I had (have) is that I have a class with a number of attributes. One of these is a pointer to a struct in PROGMEM. This is done to save RAM usage.

 

So....

1. if I watch pStruct (in progmem) this is fine with the data displayed more or less as desired.

2. if I watch rObj (the object in RAM) this is fine also. The pointer to pStruct shows the correct flash address.

 

However,

3. if I click on the pointer to rObj, the de-referenced data is taken from RAM and is meaningless and

4. trying to watch "rObj.pStruct, flash" causes an error.

 

If there is something obvious I am missing, any feedback would be appreciated. This

is a common scenario for me where I try and put anything that is truly constant in flash.

 

Otherwise I guess my work around is to do 1) and 2)

 

Thanks

Greg

 

Edited....

Watching the expression below works... but that is a lot of typing.

tickTcb.taskDescriptor->topOfStack,flash	0x0588	unsigned int{prog}@0x0308

 

regards
Greg

Last Edited: Sun. Mar 27, 2022 - 11:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just open a memory window to show the target of the pointer if it's in a different memory space. 

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

clawson wrote:

Just open a memory window to show the target of the pointer if it's in a different memory space. 

Yep. This is what I have done for years, and decoded data by hand.

Much more sophisticated than decoding the bits.... but nowhere nears as good as the Watch capability with its knowledge of structures/classes and data types.

regards
Greg

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

I've not explored this so don't know if it might work but note table 2 in the following...

http://atmel-studio-doc.s3-websi...

 

So using a watch window but adding ",flash" to the struct you want to look at MAY work.

 

(off to try an experiment..)

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


I so wanted this to work...

 

and I've tried just about every conceivable combination of expression formatting but I can't find anything to apply the struct format to the pointer. If I just try the simplistic:

 

 

then the silly debugger thinks the type is "void" rather than data_t[] :-(

 

Hopefully Morten (from Atmel) will be along in a minute to explain how to use this feature !

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

Maybe see if the gdb engine has a better take on this? You can turn in on in Project/Properties/Advanced/Use GDB

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

I tried that but seems like gdb is not keen on "flash" as a modifier for the watch. How can it be instructed to different memory spaces?

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

I would have expected gdb to be able to read the flash modifiers in the debug symbols directly... is it not?

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

What am I missing here, why does flash need to be "watched", is it going to change?!!

 

 

FF = PI > S.E.T

 

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

ki0bk wrote:
What am I missing here, why does flash need to be "watched", is it going to change?!!
A keen observation but you might still want to know what was being read from a specific address. You may know the data looks like:

const __flash data_t mydata[] = {
    { 'A', 2345, 0xDEADBEEF },
    { 'X', 5432, 0xACEB1ADE },
    { 'W', 3434, 0xBABEFACE }
};

You may even know that this data is positioned at 0x016A in flash (it was in my test example!) but say you had a pointer holding the value 0x017B where in that data is it actually pointing ? ;-)

 

Having said that I guess that looking at the LSS:

0000016a <mydata>:
 16a:	41 29 09 ef be ad de 58 38 15 de 1a eb ac 57 6a     A).....X8.....Wj
 17a:	0d ce fa be ba 00                                   ......

I guess 0x17B is pointing to the 0xCE in 0xBABEFACE  - but you don't get a full struct{} interpretation this way ;-)

Last Edited: Tue. Mar 29, 2022 - 02:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

A keen observation but you might still want to know what was being read from a specific address

You handle dumb questions with such grace!   Thanks Cliff.

 

 

 

FF = PI > S.E.T