can't watch local variable

Whoa...what a difference. Looks like watch var's are working well once again (in V3.03a), at least for me and my app. If you're not using V3.03a, I'd sure upgrade to it.

Thanks KEIL !!

Dave.

Whoa...what a difference. Looks like watch var's are working well once again (in V3.03a), at least for me and my app. If you're not using V3.03a, I'd sure upgrade to it.

Thanks KEIL !!

Dave.

Thanks for this thread. I had been using the watch thing and it just didn't seem to work right. I have just upgraded and things appear to be improved. I have a question though. I can set values in Watch #1 and view variables etc fine, but when I go thru the edit - compile -debug loop I always loose the variables that I want to watch and have to re-enter them. Is there a way to make the Watch values "stick"?

After update I see SARM.DLL v3.03, not v3.03a is that right?

I am running GNU 4.1.1, and one thing that the new version fixed was the ability to display bitfields correctly. However I lost the ability to do a mouseover on local variables and see their values correctly. Entering &varname into the memory window indicated that the debugger was looking in the wrong location since I could see the stack pointer in the register window, and could see that the debugger thought the variable was somewhere else. Manually entering the stack pointer into the memory window showed that the correct data was there, I just couldn't see it by doing a mouseover of the variable. Keil responded quickly to my support request and sent me a patch that fixed the problem. If you are using GNU and having problems, contact Keil support and ask for the patch (new version of SARM.dll) that resolves call #335962.

Kathy

John, after installing V3.03a of the tools, the "help-about" dialog shows sarm.dll as v3.03, not v3.03a.

Kathy, what does "help-about" show for your version of the sarm.dll file?

Dave.

I am currently showing v3.03e. This is a separate SARM.dll file sent to me by Keil. It ends up in:

<base keil directory>\ARM\BIN

The info shown on the file itself in the actual directory is 3.3.0.1 for the one that came with the latest debugger update, and 3.3.5.1 for the new one they sent me.

Kathy

Hi I posted too soon. The Watch does appear to be improved, the locals seem to work now where as before they didn't. But now if put a breakpoint after a string activity such as

char cmdbuf [30];

bla bla
for (i = 0; cmdbuf[i] != 0; i++) { cmdbuf[i] = (char) toupper(cmdbuf[i]);
}

and I hover over string arrays I get a stange looking yy which has two dots above each y. I had been playing with some string manipulation software just before the upgrade. I could see the string contents fine.....

However if I change the declaration to

static char cmdbuf [30];

Things are fine again. I also wish that in the "locals and watch#x" windows that they had ascii as well as decimal and hex.

Static works, thanks..

But there are other problems.
I made this function:

void Main_make_sprintf_work(char * str)
{
  static char str_local[40];
  sprintf(str_local, "%f" ,2.45);
  memcpy(str, str_local, 10);
}

It works when I call it from main() but don't work if the call come from a function further inside the program.

In what way does it "not work"?

When I call Main_make_sprintf_work(char * str)
from a task, str_local don't contain the right string.

After adding 500 bytes to the stack (now 1500 bytes) it writes "2" in Str_local.

I think its strange it did not detect any stack overflow and why do it need so much stack?

The problem was that I had an RTX_Config file for V3.02 and my IRQ and USR stack size was too small.