Cant modify locals

Are the local in-scope when you try to modify them?

Are the local in-scope when you try to modify them?

Hi, yes they are in scope, they are displayed in the local window with values when stop executing, but if i change them, they dont accept the change, using F2 in watch window to change.
I dont know if they are register? how would you know and why would they be?

Cheers.

Why would they be? Because they are locals, and the compiler want to use registers for locals since most processors and processor instructions works best on registers.

Registers have much better bandwidth than memory cells.

Sorry, im really new to this, so if they are in registers you cant modify them in the watch window? what make them decide to be in registers? I noticed that i could modify some locals but not most at one point, so why when i stop execution in a function was some editable and some not? and can i change this behaviour?
Thanks,

"what make them decide to be in registers?"

It's the compiler that decides.

"can i change this behaviour?"

You might be able to change it via the compiler's Optimisation settings - see the Manual for details...

This is a very valid question!

The whole point of an IDE is that it's supposed to be Integrated - that's what the 'I' stands for, isn't it?

[rant]
How can this be called "Integrated" if the Keil debugger can't even understand such basic optimisations as this done by the Keil compiler?!

This is not some fancy new and revolutionary optimisation technique; compilers - including Keil compilers - have been doing it for years!
Is the state of debugger technology really this far behind?!
[/rant]

It depends a bit.

All real debuggers should support edit of variables even if stored in registers.

The problem comes when the variable is only used in some part of a function. The compiler may then reuse the register for a different variable in other parts of the function. The result is that the variable goes out of scope for the debugger, even if you still are within the block scope of the source code.

"result is that the variable goes out of scope for the debugger, even if you still are within the block scope of the source code."

That's true, although a truly integrated debugger worthy of the name should be able to cope with it.

The trouble really is that the debugger technology (certainly within uVision) really is a long way behind the compiler technology - especially when it comes to oprimisation.

:-(

If you are having a problem to debug your program because the locals (being in/out of scope) then go ahead and make them global (declare them with file scope and as volatile) until you are sure this is not your problem.

The debugger can modify local variables that are in registers.

Example:
MEASURE.C function main () int i;

This variable is register R13 and can be modified.

So it must be a special case.

... is trying to view/change them when they are not in scope.

It happens to me about once a year that I goof in this way.

A really smart debugger would grey out locals and remove the value in the watch window when they are not in scope. Have not seen that in any debugger, but it would be a nice feature.

Erik

I too have seen strange things happen sometimes, especially when remote target debugging on several targets at the same time. Food for thought:

- if the variable is a register, than for sure you can change it. You can even change the register itself in the registers window.

- how would you know if it is a register by the way? Don't be affraid to open the disassembly window and look at the assembly code. It won't hurt, and you will get a better idea if something was optimized away.

- try again with a clean build:

- close all IDEs (if you had several open at the same time)

- make a backup of your project

- delete all these files: *._ii, *.obj, *.i, *.lst, *.__i, *.ic

- open the project (only one instance of the IDE)

- in the compiler options, use the optimization up to 7 (common tail merging) but not above

- build

- try to debug again

Good luck...