CCSv5 debugger: Variables panel show wrong values

Hi John,

what version of CCS are you using?  What version code generation tools do you have?  I know we have seen some issues where in some of the views only the first byte gets taken.  Could this explain your issue?  Would you be able to send a screenshot?

Best Regards,
Lisa

First and foremost, thanks.

Sorry for the wait, I took my time to install CCSv5 1.1.00031 on a new windows 7 partition. There i copied the workspace folder as well.

In this way, I should be almost safe from softwaredriver conflicts since on the older sistem i had IAR as well.

Sorry to say that probably the issue I have is not the one you mentioned. My variable is only one byte long.

As for the screenshot here they are.

This is the first one:

RXBYTES  is a define whose value is 0x3B as shown in the highlight

addr is the only argument of the function read_reg, to whom i pass RXBYTES itself.

actually addr type is uint8_t which correspond to unsigned char and thus is one byte long.

as you can see there are no breakpoint set and the code is in free running mode.

http://s15.postimage.org/efa7537h5/debug_test_part1.png

that's the second one:

that's what happens when i press the pause button.

as you can see the code stops at the line

while( addr == RXBYTES );

which means that addr value currently is 0X3B, but looking at the variable panel

the addr value is 0xF2

http://s15.postimage.org/bazj8aqop/debug_test_part2.png

is the value shown correct?

PS.

i suppose the screenshots i posted are way to big, if there's a way to insert a preview i will happily oblige.

Hi John,

could you please try reposting the screenshots or sending them offline via a conversation or friend request.

What level of optimization do you have set?  What if you make addr static?

Best Regards,
Lisa

Sorry for the mess.

This is the first one:

RXBYTES  is a define whose value is 0x3B as shown in the highlight

addris the only argument of the function read_reg, to whom i pass RXBYTES itself.

actually addr type is uint8_t which correspond to unsigned char and thus is one byte long.

as you can see there are no breakpoint set and the code is in free running mode.

that's the second one:

that's what happens when i press the pause button.

as you can see the code stops at the line

while( addr == RXBYTES );

which means that addr value currently is 0X3B, but looking at the variable panel

the addr value is 0xF2

that's it...

Hi John,

did you try with a static declaration?  What does the memory browser show?  Ie does it agree with the variables view or with the expected?

Do you have a test case you could send for us to try and reproduce this?

Best Regards,
Lisa

Lisa TI said:

Hi John,

did you try with a static declaration?

I didn't.

I'll explain the whole thing at the end of the post.

What does the memory browser show?

if I a write "addr" without quotes in the memory browser it actually goes to the 0xF2 address.

if I look at the register panel, it actually show the value 0x05F2

actually

looking at the the variable panel better it not only states that addr is in R12 but also that the value 0x3B is in R15, which correspond to the variable named "status"

Do you have a test case you could send for us to try and reproduce this?

I have no idea how to reproduce this error, i'll work on it.

Now, back to the code:

The code I'm writing is C++. 

the function read_reg is a member function of a class called spi_t which is a data member of a static object called nwk_t

to put some pseudo code together is something like

class spi_t

{

public:

inline uint8_t read_reg( uint8_t addr);

};

class nwk_t

{

spi_t spi;

};

static nwk_t radio;

the routine who calls read_reg is the following.

while( rx_bytes != rx_bytes_bis)

{

rx_bytes = radio.spi.read_reg(RXBYTES);

rx_bytes_bis = radio.spi.read_reg(RXBYTES);

}

which is part of the port2 interrupt service routine.

aside the fact that the function are member function, those are the same identical function of the simpliciTI mrfi layer, cleansed of most of the preprocessor instructions.

I obviously don't have any problem to send you this part of the code, but i cannot guarantee that you can reproduce the code. I could send the whole workspace folder, but only the bare code are 109kb.

Since before i had a similar problem while doing the same thing with the  slaa325a before, i would check if i can reproduce this problem on the slaa325a source code, avoiding the whole C++ thing. In case i will send the whole workspace as it is.

By the way, i had the same identical problem on the CCSv5.1.0.009

After a better look at the assembly,  i see that the comparison within the while loop, check the register R15 against the number 0x003B, which conflict with the fact that addr is stored in R12. By the way, I didn't made use of any optimization.

Thanks again for your time.

Here we go again.

I tried to debug the slaa325a and it seem to pinpoint the problem.

I put a breakpoint at the beginning of the port 1 isr ( the one related to the push button of the ez430-rf2500)  then  i stepped forward

first the ISR calls the function RFSendPacket

then RFSendPacket calls the function TI_CC_SPIWriteBurstReg.

The first argument TI_CC_Cxxx0_TXFIFO, a define for the address 0x3F. This argument is stored inside the addr variable, stored in R12

after a couple of step inside the TI_CC_SPIWriteBurstReg, the register R12 is overwritten, but the association between R12 and the variable "addr" is not reset.

i hope this help.

HI John,

ok, let me dig into this as it does seem potentially like a bug.  I will get back to you as soon as I have further feedback.  By the way, what code generation tool version do you use?  Just in case it may already be fixed.

Best Regards,
LIsa

In all the screenshot i used CCSv5.1.1.00031 but the  CCSv5.1.0.0009 shows the same behaviour. 

Hi John,

I am beginning to wonder whether this is a question more for the SimpliciTI/MSP430 team who wrote the example. 

From this description in the slaa325a.pdf it does not seem that addr is necessarily static.  Perhaps this is why you feel the association is "lost"?

void TI_CC_SPIWriteBurstReg Writes values to multiple configuration registers, the first register being at
(char addr, char *buffer, char count) address addr. The first data byte is at buffer, and both addr and buffer are
incremented sequentially (within the CC1100/CC2500 and MSP430,
respectively) until count writes have been performed.

If I can track down everything I need for a reproduction attempt, I will try to dig a bit further. 

Best Regards,
Lisa

Lisa TI said:

Hi John,

I am beginning to wonder whether this is a question more for the SimpliciTI/MSP430 team who wrote the example. 

From this description in the slaa325a.pdf it does not seem that addr is necessarily static.  Perhaps this is why you feel the association is "lost"?

That's not what i mean.

I mean that the variable panel keep saying that the variable "addr" is stored in R12, even when it's not. In fact, looking at the last two screenshots I  posted, the value of  "addr" changes from 0x3F to 0x7F, but there's no assignment which involves "addr" at all, thus the value of "addr" shouldn't have changed.

From the look of it, what actually happens, is that at first R12, is used to store "addr", and in such way R12 is associated to "addr", but after two line of codes, R12 is used for something completely different, and thus it doesn't represent "addr" anymore, but strangely the variable panel keep saying otherwise.That's the kind of association i was talking about.

I don't actually know how the CCSv5 is supposed to work, but from what i saw  the value shown on the variable panel reflect the register content, not the variable content, and it's not the kind of thing i used to see in a debugger. To be honest i didn't realized this at first, i noticed this behaviour only when i tried to reproduce the problem i first had. From my point of view this behaviour can also explain the original problem, and i keep seeing such a thing everytime i look in the debugger.

I really hope i am in the wrong. If so,  i would really appreciate if you can tell me where.

Thanks again.

Hi John,

unfortunately I am not at all familiar with these examples.  However, a couple thoughts occured to me that you can check

- what refresh settings are you using on the variables view?

- I did try to look at the code some and it seems like it puts the msp into lpm3.  This will kill the connection with the debugger.  Could this be causing what you see?

Best Regards,
Lisa

Lisa TI said:

Hi John,

unfortunately I am not at all familiar with these examples.  However, a couple thoughts occured to me that you can check

- what refresh settings are you using on the variables view?

i usually keep the setting on automatic. when i took those screenshots it was on automatic

- I did try to look at the code some and it seems like it puts the msp into lpm3.  This will kill the connection with the debugger.  Could this be causing what you see?

I really don't have a deep insight of the whole workbench, so i suppose it really depends on what you mean exactly. The entire routine is executed by the pushbutton ISR so there shouldn't be a change in the power mode. The real problem  are the glitches on the CS signal, which is switched to enable the spi port, and which eventually triggers the receiver ISR, if IIRC. In these circumstances the context can be disrupted if that's what you're thinking

Actually in the first case the debugger should reset itself, in the second, the compiler should guarantee that the contest switch is never disrupted, not with that kind of code at least.

Actually i have another  idea. While  writing  at you , looking at those shots and reading the code again and again, i noticed that the variable "addr"  end its purpose at the line 1404 of the source code ( see any of those 3 pics), in fact after that line,  "addr" appears nowhere inside that function. That's mean there's no need to preserve its value after that line, thus the register can be reused for something else, at that time the "addr" entry in the variable panel should have been removed or at least frozen, but, alas, the debugger kept updating the entry accordingly to the registry entry.

If that's really the case I suppose I'm the only one being misled, since no one remarked such a thing.

At least the debugger isn't that untrustworthy.

Sincerely.

JD

Hi John,

are you satisfied with that explanation then?  Unfortunately there are only a couple other options here

- to move this to the team that built those examples

- find a simple test case showing an error in the view/register handling that is reproducable

Best Regards,
Lisa

Lisa TI said:

Hi John,

are you satisfied with that explanation then? 

I suppose so. Whatever the reason behind that strange behavior of the variable panel, I won't see the patch that solve it before the deadline of my project, and thus i don't see any reason to waste time, mine and yours. To really ascertain what the real cause behind this problem is, probably requires to open up the debugger source code and debug the debugger itself, which i suppose will be very time consuming. Since i can have a reasonable explanation in a tenth of the time or less, i think i can be happy enough.

I'm writing in C++ which means i'm stuck with CCSv5, thus  i'm content with the peace of mind. In the end what puzzled me was how much trustworthy that variable panel is. I never planned to bugfix the slaa325a ( if that's what you're thinking.)

Unfortunately there are only a couple other options here

- to move this to the team that built those examples

- find a simple test case showing an error in the view/register handling that is reproducable

Best Regards,
Lisa

At present I  feel I made you waste more time than necessary and i don't really think there is any need of wasting more.

If you think this problem need more attention and some serious bugchecking, i don't have any problem to send you the whole workspace i used shoot those pics. But that's depend on you. Feel free to ask then. I really am satisfied with the help you already gave me.   

Chester Gillon said:

One of the actions taken by optimization level zero is "Allocates variables to registers". Allocating variables to registers results in smaller / faster code, but has the side effect that the debugger may not show the expected value of variables.

To disable optimization level zero when debugging you have to select the "Disable all high level optimization (--no_high_level_opt)" option under Project Properties -> CCS Build -> MSP430 Compiler -> Advanced Options -> Advanced Optimizations.

With this small example, after disabling all high level optimization the debugger shows the expected value of the ptr variable after stepping over the delete call (and the Variables panel shows that ptr is now on the stack rather than in a register)

First of all many, many thanks for that hint.

That means that is clearly my fault to have not read the manual thorougly enough. Actually i thought it was way to early to even think of optimize anything, thus when i saw optimization level == 0 i read that as "no optimization".

I suppose i can't apologize enough for wasting your time...

Sorry.

Hi John,

glad it turned out to be the optimization ...

All the best with development.

Best Regards,
Lisa

Thank you again, and sorry for wasting your time!

JD

No problem at all. And no waste of time.  It is not obvious (and something we are changing) how to turn off optimization.

Best Regards,
Lisa