Debug fragmented variables

[rolox]

HI,

Not sure if this a MPLAB (8.x or X) or CCS issue :
Often variables are fragmented in the PIC memory. This can be seen in the .sym file. That does usually not really care because the programs work anyway.
But debugging this variables is hard, becuase in the watch window the memory is shown NOT according to symbol table.

In the example, "myVar2" is fragmented by the compiler and locates as follows :
06C-06F,0A0-0A5 main.myVar2
BUT: in Watch window (anyway if MPLAB 8 or X) the memory is shown from 0x6C up to 0x75. So the content is wrong - more or less, depending on the position an probably changing while changing the program...

The question is : can i tell the compiler to NOT fragment certain variables ? There is in fact enough RAM left to fit the varaibles unfragmented....

[asmboy]

the data sheet shows the limits of what can be done
look at table 3-3 to see what i am talking about.
since memory is banked on 16F parts - there will never be more than 80 contiguous bytes of SRAM for a VAR.

what is the Harm in what you see?
are program results wrong?
does fragmentation offend your sense of order ??

for a moment forget about MPLAB - that could be a problem right there.
what happens to your compile result with NO ICD in the picture?
IN my world view the best debugger is NOT MPLAB!
It's above your neck and between your ears.

[Ttelmah]

As Asmboy says, there isn't space to have things un-fragmented on these small page chips. It's an MPLAB limitation, that it can't handle things split across multiple banks. Just create a manual watch at the address of the second part.

[rolox]

Hello guys,
i know that RAM in PIC is fragmented. And i wrote that programs seem to be ok.
What is the harm in wrong debug information ? thats a joking question, isn't it ? if the IDE/debugger shows the value of a variable wrong - its worthless.
I dont' care where the compiler puts its variables - als long as i can have an eye on it.

In fact, there is enough RAM for this variables to have them unfragmented. Have a look at the code. none of the three vars i >80byte - so why fragment the one which is just 10bytes long.

The point is : has anyone else the need to have a look at the programs vars during development ? everything works right from the start ?....

[temtronic]

one potential reason for the fragmentation is that you've said ICD=TRUE.
this means the compiler/PIC/MPLAB have to use PIC resources diferently than had you not used the ICD.
Don't ask me specifics as I never use the ICD, prefer to use 'release' mode and do real world testing. Others who use ICD can reply what happens.
I'm 'old school', never found a 'simulator' that worked right either and since the program has to work i the real world, that's where I test.

Jay

[rolox]

omitting "#device ICD=TRUE"
does not change the behaviour.
Anyway - i know the ICD uses some resources, depending on the PIC device. According to Microchip there were no resources used in the 16F1788.
But even if that were the case - there is enough RAM left.
ICD3 is working quite well for my needs - but i wonder why the watch window does not take care of the symbol table (or not correctly).
This may not be a CCS issue, but i was hoping for some hint on a hidden pragma like '#keep_vars_together' or whatever
I'll check Microchipforum for this issue too....no result yet

[PCM programmer]

In older compiler versions, arrays could not be larger than a ram page,
nor could they span a page. But now they can.

How to get around this ?
You can force the myVar2 array to start at the beginning of a page
with #locate. Add the line shown in bold below:

[rolox]

hello pcmprogrammer,

ok, then just "myVar2" is unfragmented - but then the next one may be ....
this solution may help for small programs - but i cannot keep track of all my vars after each compile just to see if the compiler does a fragmentation and then add a manual #locate to avoid that - a global compiler flag would be the solution - probably already existing .... but unknown

[Ttelmah]

No form of global flag could work, without wasting most of the memory.
Think about the implications if things can't cross boundaries.

What is needed is MPLAB to start supporting multiple page variables.

[rolox]

The wasted memory surely depends on the sort and amount of vars used/needed for a program. I posted a thread on Microchip forum about this issue...all i got till know was kinda "...forget the debugger, use your brain..." ..but all i'm asking for is a that offered features (watching a var through debugging...) are working as expected :-( ...or at least a workaround .....

[temtronic]

You could email Microchip's MPLAB software group and ask if they'll fix that 'bug'. I did that years ago when I got 'hit' with the 'debug' mode as the default config. Having to manually change that EVERY time was tedious( I always use 'release'). One of the IT guys called me, was intrigued how I was using MPLAB(seemed 'normal' to me), sent me a 'patch' to run, then a few months later MPLAB had the patch in it!
Never hurts to ask !

Jay

[asmboy]

going back to the original question

[rolox]

@asmboy : you right, sending the "needed" vars values via rs232 is just an option - the actual hardware has in fact the ftdi already attached ...coming from nec/renesas it was always the easy way just to have the look at all the vars if desired ...but you may absolutely be right that MPLAB is not the best solution, and i tried the 8.x and X - using ICD3 AND having several watches open slows down system.
Using PCMprogrammers hint at least while debugging a special part of the program and certain vars in fact seems to be the best way for me at the moment (i confess i did not have a look at the CCS IDE at all).

edit : did an import from MPLAB to CCS IDE - was less work than expected....having a look at the watch on the fragmented vars - same result as with MPLAB, watch window shows wrong values. Maybe thats an ICD problem rather than an IDE problem....at least i found the CCS IDE more comfortable than MPLAB 8.