Watch window "Variable out of scope"

[bennyboos]

Hi everyone, I need to dust of my CCS experience.
The last time I used it in anger was about 5 years ago so I'm afraid I have forgotten certain handy tips.
In particular I am now trying to debug some code on a dsPIC30F3013 using the ICD3 (all within MPLAB) and keep getting frustrated that so many of the variables are not viewable in the watch window owing to their being "Out of Scope".
I realise this is because they are automatic and so the compiler uses one of the WREG's but is there a way to force this off, just for the time being?
I've tried turning the optimisation to it's lowest setting but things still remain out of scope? So far, the best way I have come across is to force variables into fixed locations using #locate but it would be much more helpful if there was a simpler way using a command line switch or similar?

Any suggestions greatly welcomed.

[Ttelmah]

No.
The point is that the variables don't actually exist, when you are not inside the routine that uses them.
They don't necessarily use registers, but they use the same area of memory, that can be used for different variables when you are not inside the routine. You can have half a dozen or more variables all using the same memory location. They cease to exist, and the memory ceases to be used by that specific variable, when you leave the routine, so there is no actual point in looking at the location.
Global variables have full scope, and by #locating a variable, you make it occupy a fixed location, so use memory as if it was global. Otherwise, the variable doesn't exist.
The same happens on the PC using the Microsoft debugger.

[RF_Developer]

Its not a matter of how the compiler implements scope; its the scope rules of C itself.

Essentially any variables declared in a particular block, i.e. local variables, only have a defined meaning with in that block. Therefore local variables, and parameters to functions, are only watchable when the code execution point if within the block on which they are declared. Typically in many systems, including PCs but NOT most pics for hardware architecture reasons, local variables are allocated space on the stack, and cease to exist when the routine exits. On most PICs, which do not have a data stack, CCS C allocates such variables to what are effectively scratch memory locations, which can and are used by many routines, beign overwritten whenever a new routine or block is entered. Compilers could chose to implement such variables with fixed memory, as if they were global, but that's generally a waste of space.

Only global variable have fixed allocation in memory, and thus exist and are watchable at all times.

Conceptually, but not necessarily practically, dynamically allocated memory sort of exists outside of the normal scope rules and for which different scope rules could be said to apply - but the "access variables", i.e. pointers etc. to get to such dynamically allocated memory still follow the normal C scope rules. In other words, memory may still be allocated on the heap long after any pointer to it has gone out of scope - i.e. memory leaks. This is the problem garbage collection was developed to address. C doesn't have it, so the programmer must be extra careful to avoid memory leaks.

So, to make any variable watchable outside of its normal scope, the scope must be changed, and the simplest way of doing that is to make it global. That obviously creates problem in recursive code (and the key reason CCS C doesn't implement recursion is because it doesn't have a variable stack available to it). Static variables in routines do effectively have global lifetime, and so are allocated in fixed memory, and could practically be watchable, but they still only have local scope, and so have no meaning outside their routine.

Short answer: C scope rules don't.y allow it. To change it, change the scope - most likely to global.

[bennyboos]

Thanks Ttelmah and RFDeveloper.
I realise that any local variables are likely to be out of scope once outside of the subroutine (unless global or static or #located), but as I recall from MPLAB of old, I could still have local variable names in the watch window. As such I recollect that they would display as "out of scope" for the majority of time, however, once the debugger had stepped into the subroutine in question then they did become viewable until such time as execution left the subroutine?
Did this used to be the case or am I just imagining it

[temtronic]

Hmm.. though I don't use the ICD..everything you guys makes 100% sense.
I'm wondering if the 'new' version of the ICD has a 'bug' that only allows global variables to be seen, even though variables when used should be seen.

Doesn't sound like 'fun' to turn back the clock to figure this one out....

Jay

[bennyboos]

Hmm, wish I still had my old ICD2 and hadn't sold it in eBay
I tried recreating my project within CCS's own IDE but that also seems to have issues with my ICD3 and a dsPIC30F3013. Whilst it seems to read the device ID of the chip, it seems unable to do anything else - i.e. erase, blank check - never mind program/step-through.
Does anyone know if the CCS's IDE even supports 16bit devices via an ICD3 ?
I can't see anything one way or the other
Will post this as a separate query...

[Ttelmah]

I've not seen this problem, but I'm still using MPLAB 8.92, unless the chip is not supported in this.
For me, the 'new' MPLAB-X, is a pile of something smelly. It's less functional in almost every way and unbelievably inconvenient to use. Crashes frequently, and just seems determined to be worse.
You don't say what version of MPLAB you are using?....

[bennyboos]

Sorry Ttelmah - I thought it best to start that as a separate discussion. Anyway, like you, I had a quick play with MPLAB-X and decided to stick with what I (thought I) know best, which is version 8.90.

I also just noticed that I hadn't really defined my problem properly.
Having looked at the watch window again, I realise that it was reporting the local variables as "reserved" and not "out of scope" as I had previously explained (oops sorry guys).
Either way, I still can't see the value which rather makes having a watch window a bit pointless in this respect. Any ideas ?
I have downloaded and tried the very latest version of PCWD with the same problems.

[Ttelmah]

Are you compiling inside MPLAB, or directly in CCS?.
Are you specifying DEBUG, or letting MPLAB do this for you?.

I've seen this at some point (scratching memory). I think it was something like me specifying 'DEBUG' in the compile, and then letting MPLAB also specify the debug. It resulted in the wrong memory addresses being reserved. Was a while ago, and I can't remember the details, but I fiddled around, and got rid of all debug declarations in my code, then let MPLAB "do it's own thing", and it started working.

[bennyboos]

It was all done in MPLAB.
I had briefly tried CCS's own IDE in the past but didn't really see any advantages over MPLAB (but a lot more learning to do) so I stuck with what is most familiar (also I was using HiTech at the time as well so preferred to keep the same IDE for everything).
Thanks for your suggestions - I'm home now so will have to try this on Monday - I'll let you know what I find.

Cheers Ben