We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I'm using the Keil uVision V4.03q.
I wonder if there's any setting to be able to watch all variables during debugging? If I want to watch a function argument in a function it says: 'out of scope' so I have to define a static copy of that variable to be able to watch it
Optimization is set to minimum level.
Thanks
Henk
I wonder if there's any setting to be able to watch all variables during debugging? I guess you do not want to watch ALL variables, that would take a huge monitor. Assuming you mean watch local variables whether in scope or not, the answer is no. I could visualize the debugger itself retaining contents of local variables on function exit, but, alas, it does not.
Erik
Not sure if it's worth the effort but you can record the variable access. At the point where the var is used (changed) you can do a breakpoint execute to call a debugger function. Then write a simple debugger function to printf() the var. The printf()in a debugger function is not the printf() to a serial port. This printf() only writes to the command screen in the debugger. See the debugger manual for examples. When the breakpoint executes, the var will be printed to the command screen but the code will continue. In other words a breakpoint execute does not stop the code. You can go a little further and log the command screen to a file for some later perusing. Only you can define if it's worth the little effort.
Bradford
I wonder if there's any setting to be able to watch all variables during debugging?
You can already watch all existing variables. Which is the root of your problem, of course, since you're trying to watch things that don't exist when you try to see them.
Automatic variables and functions' actual arguments only exist while they're in scope. At all other time, they don't exist. The place where they existed (typically on the stack, or in overlaid memory regions) will be used to hold other data. That means those non-existing variables have no current value the debugger could possibly show you. If it tried, whatever those watches were to display would be utterly meaningless if you're lucky, totally misleading if you're not.
@Hans-Bernhard Broeker,
I think the OP is referring to an annoying situation that used to exist at all MDKs until and including 4.14 at which the program is stopped, and automatic variables that are clearly in scope sometimes fail to register, indicating an "out of scope" message or are displayed with the wrong value (verifiable by inspecting the registers/stack). I have not upgraded my working environment for a while so I don't know whether the issue was resolved (the OP is using an even older MDK).
The 'out of scope' problems are solved with MDK-4.23 using Cortex-M targets. For ARM7/9 targets, there is also a corrected version which will be part of the next MDK release by around mid of March.
If there are still 'out of scope' displays, then this shown by intention since the lifetime of a local variable may be restricted as specified by Elf/DWarf's location expressions - not necessarily 'what you mean is what you get'...